This is the most ironic typo I've ever made. Thanks for the catch. I've corrected it.

> This is commercial only.

You can use Unicorn for non-commercial use [1], but yes, for commercial use you need to buy a license.

> It's much faster to use precomputed tables per algorithm

You're absolutely right about using precomputed tables per algorithm. That is the secret to the library's speed.

> Free and small is my safeclib, which does about half of it.

I like safeclib! It's nice to hear from the author. It's worth distinguishing that safeclib is a safer string library whereas Unicorn is a Unicode algorithms library, not a string library.

[1] https://github.com/railgunlabs/unicorn/blob/master/LICENSE

> This is commercial only. Free and small is my safeclib

Is it me or does this feel a bit weird? It seems like you're using the comments section here to self-advertise for exposure.

I read it like — "businesses can't use this without paying the OP, however, if you're a business you can get 50% of the way there by using _my_ library, and you don't even have to pay me!". It comes off incredibly rude to try to undercut the OP like this.

    #  You may not reverse engineer, decompile, disassemble, or otherwise attempt
    #  to derive the source code or underlying structure of this script

You can download a prebuilt amalgamation from GitHub to see the amalgamated C code [1]. The GitHub repo contains the code that generates the amalgamation.

[1] https://github.com/railgunlabs/unicorn/releases/

> I would like to know how does it compare against ICU

ICU is a large library, typically around ~40 MB depending on the platform, whereas Unicorn, with all features enabled, is only about 600 KB.

ICU has a broader scope: it's not just a Unicode library, but also an internationalization library. Unicorn, on the other hand, is specifically focused on Unicode algorithms.

ICU wasn't designed to be customized. It's also non-MISRA compliant and written in C++11. In contrast, Unicorn is written in C99, fully customizable, MISRA compliant, and only requires a few features from libc [1]. It's far more portable.

[1] https://github.com/railgunlabs/unicorn/?tab=readme-ov-file#u...

I appreciate the kind words. When I was designing the website, I wanted to inject my personality into it. I wasn't sure how well the "playfulness" would go over, but I'm glad you enjoyed it.

That's one of many rules in MISRA that originate from antiquated "best practices" from the dark ages that don't actually improve safety. We have it today by way of IEC 61508, which gets it from a book on structured programming called Structured Design. That book didn't recommend banning multiple exit points, but it recommended minimizing them to simplify the control flow graph and said code should minimize the distance between black boxes (bits of code that do something without leaky abstractions and have only one return statement). The IEC authors and MISRA thought the logical extension of that was to make everything have one exit point.

This is an old rule from when structured programming was introduced. The prior state of affairs was that code would jump via gotos between functions to different labels within those functions (labels were global). The requirement that every function should have only a single entry point and a single exit point seemed like a good rule to establish sanity.

MISRA C states the following rationale:

“A single point of exit is required by IEC 61508 and ISO 26262 as part of the requirements for a modular approach.

Early returns may lead to the unintentional omission of function termination code.

If a function has exit points interspersed with statements that produce persistent side effects, it is not easy to determine which side effects will occur when the function is executed.”

Note that the MISRA C rule is merely advisory, meaning it is a recommendation and not a hard requirement (i.e. it’s a “should” and not a “shall”).

Having been only lightly exposed to MISRA, my impression is that in MISRA the "Required" label doesn't mean "You must always do this"; rather it means, "You must do this or document why it's necessary and safe not to do it".

It's a bit like an operating system write-protecting pages. Sometimes you write-protect pages that the process really shouldn't write to, like shared libraries or something like that. But sometimes you write-protect pages that you actually expect a program to write to, like memory-mapped pages, because then when the write happens it triggers something else (like copy-on-write or marking a page dirty or something).

Rules like "Don't use dynamically allocated memory" are one example of this -- not that they really expect you never to do it, but that marking it "Required" is a way to force you to document how you plan to make it safe.

Similarly, if it's easier to rearrange a function to have only a single exit point than to explain why you need multiple exit points, just rearrange it; you really need multiple exit points, just document why.

Lots of MISRA could is proprietary and receives no upstream patches from customers. Still, it's not unusual to deliver a source blob to your customer instead of a binary blob, often for debugging. (But sometimes only the binary blob has the blessing of the vendor, so you can only use the binary blob in your released product)

I would not be in the least surprised if someone has a compiler/transpiler from a higher level language to some C code which checks all MISRA boxes.

One reason to prefer it in C is to be able to easily add locally scoped functionality like profiling markers and temp allocators.

  profile_begin("func");
  a = temp_arena_begin();
  // ... code
  temp_arena_end();
  profile_end();

the abominations I've seen in code review from people trying to fullfil this rule still wake me up at night

FORTRAN II introduced the RETURN statement.

one reason I can think of from the top of my head (although I never had to deal with MISRA C at all) is that if you have to add some cleanup code before your function returns, then there is exactly one place and one place only to do that.

Otherwise this leads to duplication of cleanup code similar to

  allocate_something()
  ..
  if failed(foo) {
    deallocate_something()
    return FAILED;
  }
  ..
  deallocate_something()
  return SUCCESS;

But not interesting for me in any way since it’s not open source.

Thank you, let me know if you have any questions.