nobu (Nobuyoshi Nakada) wrote in #note-5: > Do we need to force the function to be inlined? You can, but it's not the best solution. I suggest the following patches (if you like them, I'll send them to the mailing list): ```diff com...alx (Alejandro Colomar)
Also, your `ruby_nonempty_memcpy()` could be simplified to call `memcpy(3)` directly, without any `if`s, since `memcpy(dest, NULL, 0)` is implemented as a no-op, so you could simplify the code a little bit (remove one run-time check for ...alx (Alejandro Colomar)
Actually, ISO C specifies (indirectly) that `memcpy(dest, NULL, 0)` is Undefined Behavior. See: <https://stackoverflow.com/questions/5243012/is-it-guaranteed-to-be-safe-to-perform-memcpy0-0-0> ISO C doesn't specify the `[[gnu::nonnull]]...alx (Alejandro Colomar)
It is Undefined Behavior, by any standard ever issued. See what I have in my system right now: ``` alx@asus5775:/usr/include$ grepc memcpy ./string.h:43: extern void *memcpy (void *__restrict __dest, const void *__restrict _...alx (Alejandro Colomar)
shyouhei (Shyouhei Urabe) wrote in #note-2: > Thank you for reporting! Are you using the compiler that nginx detects here? If you use one that the ruby's build system finds, then it should have added `-fdeclspec` into `CFLAGS` for you...alx (Alejandro Colomar)
Issue originally reported in Nginx Unit <https://github.com/nginx/unit/issues/653>. Apple version of `clang`(1) behaves different than what we have in Debian (and presumably other Linux systems). It reports `1` for `__has_declspec_a...alx (Alejandro Colomar)
alx (Alejandro Colomar)10:32 PM Ruby Bug #18893: Don't redefine memcpy(3)