Conversation

Notices

1. Embed this notice
   Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 10-Feb-2026 23:18:50 JST Rich Felker

   • Daniel J. Bernstein

   @djb This isn't "bureaucratic", it's gratuitously obfuscated with round trips through void * that make it hard to discern whether the behavior is defined without careful examination. If your functions took float * you might have a clear example.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Wednesday, 11-Feb-2026 00:30:22 JST Rich Felker

     in reply to

     • Daniel J. Bernstein

     @djb It's not a "helpful hint". It makes it look like this is UB-filled nonsense accessing objects with the wrong types, when, with the round-trip through void * removed, it's clear (and checked by the compiler) that the objects are only accessed as their declared types.

   • Embed this notice
     Daniel J. Bernstein (djb@mastodon.cr.yp.to)'s status on Wednesday, 11-Feb-2026 00:30:23 JST Daniel J. Bernstein

     in reply to

     @dalias Feel free to change void * to float * in this code and you'll see the same FLD-FST gcc bug appearing. However, the void * is a helpful hint for human readers.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Wednesday, 11-Feb-2026 01:12:16 JST Rich Felker

     in reply to

     • Daniel J. Bernstein

     @djb No, because in memcpy it actually reflects the semantics - that you're allowed to bypass effective type rules. The underlying accesses memcpy does are as-if (for aliasing purposes) via char type objects in the overlaid representation array.

   • Embed this notice
     Daniel J. Bernstein (djb@mastodon.cr.yp.to)'s status on Wednesday, 11-Feb-2026 01:12:17 JST Daniel J. Bernstein

     in reply to

     @dalias Does the void * in the standard interfaces for memcpy etc. look like nonsense? I expect typical C programmers to read it as a hint that the function is at least partially polymorphic (whereas the traditional char * is now more of a hint that the function wants byte arrays or byte strings).

     Anyway, this gcc bug looks like it comes from someone simply not understanding that FLD-FST isn't equivalent to a copy. This is compiler confusion about machine-language semantics, not about C types.