home.social

#standardc — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #standardc, aggregated by home.social.

  1. I might have to release #djbwares 12 hot on the heels of 11.

    Bloody C.

    #StandardC

  2. I might have to release #djbwares 12 hot on the heels of 11.

    Bloody C.

    #StandardC

  3. I might have to release #djbwares 12 hot on the heels of 11.

    Bloody C.

    #StandardC

  4. @ermo

    Excellent news! Thank you.

    The warnings are mainly Bernstein's buffer library relying upon being able to use one function pointer to point to multiple different functions with different signatures (which is a shenanighan that one could play with old C, but soon no longer) and Bernstein's byte library using char pointers.

    I've fixed a load of places where the Bernstein code was blasé about function signatures. Those are two of the remaining unfixed areas.

    #djbwares #StandardC

  5. A bonus top tip for today:

    '\376' will not compare equal to a character in memory with the value 254.

    This is not assembly language, where one can compare an 8-bit byte with an 8-bit constant and have it just work, willy-nilly.

    That would be crazy.

    #djbwares #dnscache #octal #StandardC

  6. A bonus top tip for today:

    '\376' will not compare equal to a character in memory with the value 254.

    This is not assembly language, where one can compare an 8-bit byte with an 8-bit constant and have it just work, willy-nilly.

    That would be crazy.

    #djbwares #dnscache #octal #StandardC

  7. A bonus top tip for today:

    '\376' will not compare equal to a character in memory with the value 254.

    This is not assembly language, where one can compare an 8-bit byte with an 8-bit constant and have it just work, willy-nilly.

    That would be crazy.

    #djbwares #dnscache #octal #StandardC

  8. @blinry @b0rk

    You really should tell the #BusyBox people about that C bug in the feature autodetection.

    I recently had to update a whole lot of K&R code (written a decade after C89) for similar reasons. I even had a similar autodetection break.

    C99 has and C23 is even more going to hit a lot of old codebases where people wrote things K&R style, sadly in the cases of many of them well after #StandardC came into existence.

  9. @dalias @ska

    Well they *are* making their own versions of those two macros. I'd already read the ostensible rationale for it, and it seemed poor.

    They have a problem with their own code's headers having lots of cross-dependencies. (Strong coupling and low cohesion: a long-standing #systemd problem.) That's not a reason for fiddling with the #StandardC library, let alone making one's own FILE and DIR macros.

    #musl

  10. @ska @dalias

    I understood Daniel J. Bernstein's avoidance of the Standard C library, especially strings and standard I/O which had been rife with pointer mis-uses for decades.

    But this is not that.

    Why on Earth would one continue to use stdio but roll one's own version of the GNU C library's FILE and DIR macros?

    github.com/systemd/systemd/iss

    #StandardC #systemd #musl