[Toybox] [SC22WG14.32335] Statement expressions

[enh]

On Tue, Jul 15, 2025 at 1:09 PM JeanHeyd Meneide
<phdofthehouse at gmail.com> wrote:
>
> On Tue, Jul 15, 2025 Rob Landley <rob at landley.net> wrote:
> >
> > ...
> >
> > My last engagement with the C committee was probably back around 2023
> > (I'm guessing circa https://landley.net/notes-2023.html#05-02-2023) when
> > I wanted to implement "read" in toybox's shell but line reads using
> > readline() and friends used a FILE * that did automatic readahead into
> > the FILE * buffer, and there was no way to ask that FILE * ...
> >
> > ...
> >
> > When I asked the posix committee they said that FILE * was opaque to
> > them and to go ask the C standards committee, and the C standards person
> > who replied to my query through the web form thingy said that
> > filehandles weren't in ISO C at all. (At least posix had fdopen() and
> > fileno() to translate between the two. The posix side was willing to
> > reach out, but not to standardize or provide an accessor function to the
> > contents of the other committee's struct. And the C committee wouldn't
> > do it because doing I/O through anything OTHER than a FILE * was
> > "nonstandard". Apparenntly child processes inheriting
> > stdin/stdout/stderr from a parent are not their problem.)
> >
> > So even though FILE * always had a variable storing the amount of
> > remaining input data (it HAS to) the member had a different name on
> > glibc and on musl and on bsd/mac, with no standard accessor functions,
> > and neither side wanted to standardize this because each felt it was the
> > other's responsibility.
>
>      I'm sorry to hear that; that's got to be incredibly annoying and
> frustrating. Unfortunately, my (personal) appetite for doing things
> with the C standard library is limited and I frequently write off
> using the C standard library and roll my own stuff. Occasionally, when
> I feel like it's impossible to get around it (.e.g, because it's
> something owned thoroughly by the C standard library or its
> implementations and not something I can just work around), I try to
> help (e.g., Thread Interfaces, Encoding Interfaces, etc.).
>
>      I recognize there's a huge gap in how stream stuff can and should
> behave, and how much information should be provided, but I personally
> have limited myself from working on the <stdio.h> header because it's
> very, VERY convoluted (as you're discovering with the POSIX/C Standard
> split). For example, I've received frequent requests to do something
> about `int` being the return type for most writing and reading
> functions and how that makes it untenable for large file I/O. I
> recognize it's a problem, but I'm not expert enough to come up with a
> solution as I just ignore stuff or use platform-specific I/O
> interfaces.
>
>      Given how deeply you've reached into this, maybe the best way to
> approach the problem on your end is to actually write a paper for WG14
> to look at, and then also show it to POSIX (the Austin Group) as a
> "hey, I'm serious about fixing this, now's the time to get a word in
> so you can be part of the solution". That way rather than just talking
> about it, they have something to work with (which might lead to a
> better solution). Figuring out the specification for that would
> probably be annoying and difficult as a first-timer, but. Well. I
> never intended to work on typeof or anything; I was supposed to just
> do Unicode functions and leave.
>
>      But here we are. :)
>
> > ...
> >
> > Mostly I just test which compilers have what and make do with the
> > reality at hand. It's a lot easier when you write off Windows as "never
> > to be supported", then you can rely on things like LP64. :)
> >
> > If there was a standard that let me remove giant horrible things like:
> >
> > https://github.com/landley/toybox/blob/master/lib/portability.h
> > https://github.com/landley/toybox/blob/master/lib/portability.c
> >
> > I'd be more interested, but this seems unlikely.
>
>      At least one thing I can point to being better, for
> https://github.com/landley/toybox/blob/master/lib/portability.h#L136-L168
>
> - Endian stuff (and a lot of bit utilities) are in a new header called
> <stdbit.h> in C23.
> - The byteswap stuff took a longer time to fix (mea culpa: it took me
> too long to fix), and so is only in C2y
> https://thephd.dev/c2y-hitting-the-ground-running#more-bit-utilities

POSIX 2024 finally has a standard <endian.h>
(https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/basedefs/endian.h.html)
so that's likely to be available everywhere toybox needs it sooner
than <stdbit.h>.

(i'm still annoyed that the standard says <stdbit.h> should also have
_functions_ rather than leaving it to the implementation to decide
whether macros or functions make more sense, and don't plan on adding
the functions to Android. even more annoyingly, without this
requirement we could probably have just got <stdbit.h> into _llvm_
[and gcc] so every libc wouldn't need to roll their own :-( )

>      The vast majority of the rest of this stuff looks like timers
> (POSIX stuff)/timespec failures (some of that addressed in C23, but
> it's also on vendors to not mess around with people's code and provide
> a conforming standard) and I/O work. I'd love to say I've got a good
> grasp of the File I/O issues but in my head a lot of this stuff is
> "wow this could really use some fundamental tweaks and a fresh coat of
> paint", so I resist the urge to bother. A lot of this stuff looks like
> POSIX could be a lot more intentional about it; though, for the Apple
> fails, they source some of their libc from BSDs, so it might make
> sense to go improving things there and maybe it'll flow upstream?
>
> > (Honestly I'm probably mostly just writing C89 with compiler extensions.
> > With LP64 I don't really need uint32_t and friends... I guess %p wasn't
> > in c89? I claimed C99 because I had online copies of the C99 spec and
> > _didn't_ have online copies of C89...)
>
>      That's how it always is, really. It's usually "C89, but I need a
> few things". My hope (with __has_include, better bit utilities, better
> atomics, better timespec, better threads, and more) is that we end up
> making a C2y/C3a enticing enough for people to say "yeah, actually, I
> have better things to do than maintain portability hacks: upgrade your
> compiler and demand better from your vendors". Delivering core
> usability improvements is the only real way I see people enjoying
> working on low-level stuff with C for a long time to come.

__has_include() has been great, but __has_function_declaration() --
which afaik isn't even an extension anywhere -- is the one i'm missing
for portability hacks. so much autoconf[-type] nonsense caused by the
need to know "do i have foo()?" and "do i have the foo() that returns
a char* or the one that takes a char*?"...

>      Hopefully, eventually, the small things you want make it into C
> before you get tired of it or -- perhaps worse -- give up on it
> getting any better.
>
> Thanks for sharing,
> JeanHeyd