[Toybox] [SC22WG14.32335] Statement expressions

[Rob Landley]

On 7/15/25 12:44, enh wrote:
> 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 :-( )

Endian support is ugly, but not _that_ ugly? As terrible hacks go,

#define IS_LITTLE_ENDIAN (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__)
#define IS_BIG_ENDIAN (!IS_LITTLE_ENDIAN)

#ifdef __APPLE__

#include <libkern/OSByteOrder.h>
#define bswap_16(x) OSSwapInt16(x)
#define bswap_32(x) OSSwapInt32(x)
#define bswap_64(x) OSSwapInt64(x)
#elif defined(__FreeBSD__) || defined(__OpenBSD__)
#include <sys/endian.h>
#define bswap_16(x) bswap16(x)
#define bswap_32(x) bswap32(x)
#define bswap_64(x) bswap64(x)
#else
#include <byteswap.h>
#endif

Isn't really a big deal, and not a thing motivating me to move. The 
generic #define SWAP_BE16(x) bswap_16(x) staircase is as ugly as any of 
the platform specific stuff, and I'd just be using htons() and friends 
if they bothered to be symmetrical (I want to specify whether this value 
is big endian or little endian, not translate to/from only ONE of them 
please), and handled 16, 32, and 64 bits instead of saying long is 
uint32_t which was just strange.

No, actually being able to rely on "features.h" existing would be nice 
(not _everything_ is a compiler builtin macro), knowing what the default 
setvbuf() type is would be nice, not having to do horrible things to get 
c.utf8 would be nice. I believe it's currently performing surgery on 
locale types:

// Try user's locale, but if that isn't UTF-8 merge in a UTF-8 locale's
// character type data. (Fall back to en_US for MacOS.)
setlocale(LC_CTYPE, "");
if (strcmp("UTF-8", nl_langinfo(CODESET)))
   uselocale(newlocale(LC_CTYPE_MASK, "C.UTF-8", 0) ? :
     newlocale(LC_CTYPE_MASK, "en_US.UTF-8", 0));

I have no idea what's C and what's Posix here, I'd mostly just like it 
to stop and/or work. (And I have no idea what QNX is doing here, they 
maintain their own fork and don't send me most of their patches...)

But "look we fixed a thing you haven't thought about in years because it 
just works", not so much. (I _could_ write my own nuxi macros if I 
wanted to, I just assume there's optimized ones for the platform, if not 
a machine language instruction in the processor that does it which the 
right macro will resolve to.)

>>> (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*?"...

One of my two remaining compile time probes is checking whether or not 
fork() exists in libc (to detect nommu).

(The other is a check for __ANDROID__ being #defined, because there's a 
sequencing issue with the old kconfig plumbing forked from 2.6.12 that I 
can probably clean up in the kconfig rewrite, but haven't bothered yet 
because the fork() check won't go away.)

All the others turned into #ifdef of a compiler builtin or a 
__has_include() check.

Rob