/Cinny
i love how even when moving past autofools we are still doing superfluous checks
Checking for size of "char" : 1
@charlotte I think there are systems where the size of char is weird #lang_en
/Cinny
@ellenor2000 yes but its size would still be one (byte). just not 8 bits
/Cinny
@ellenor2000 also i don’t think that a linux-aligned build system that is about 10 years old and is written in python would support bespoke 60s minicomputers
@charlotte I know why this check is in there
It is in fact necessary for a legacy architecture that is still alive despite our best efforts
You probably don't know want to know
/Cinny
@jhwgh1968 no i do. why does gst-plugins-bad check for if char is 1 byte wide
@charlotte because on a Cray 3 machine, a char is 8 bytes wide
In order to implement efficient math and indexing, they expand all chars into register-length entities and store them in ram as char[] with 7 bytes of padding per character
When you use (char *) pointer arithmetic papers it over bc the compiler knows how big the char is, so you have to access arrays differently depending on whether they are "packed" (sane) or "padded"
GNU Autotools IIRC calls this check "Checking for Cray Strings"
@charlotte "but no one made a Cray 3 in decades!"
1. I have done dumber stuff at an office for money with GNU Autotools
2. Cray Programming Environment (CPE) is still a thing (tho IDK if it's supported)
3. It's open source
4. Probably the script is copied verbatim from another check, so it may actually be useless, but good luck removing it
5. Someone somewhere might take advantage of this C standard nonsense in future, embedded platforms hate devs
So that's my theory why
EDIT: wrong big corp
/Cinny
@jhwgh1968 reading the source code of meson, it generates a test program that is basically just printf("%d", sizeof(char)); which is by definition 1
@charlotte except on a Cray 3 with OpenVMS and their proprietary compiler, in which case it will be 8
/Cinny
@jhwgh1968 then then it’s not a standard c compiler and i doubt media en/decoding runs particularly well on it either
@charlotte I have forgotten the details, but it was standards compliant at the time. Now IDK
/Cinny
@jhwgh1968 the definition exists since c89, the first version of C standard
@charlotte it's simply been too long, and my memory is fuzzy, so I withdraw
@charlotte okay you nerd sniped me, so I went digging
I *still* could not find the reference, but at least I found a DSP that does the same thing the Cray 3 did
And it appears you were right: sizeof(char) = 1
However, CHAR_BIT is not 8 -- it'd be 64
Which means if you use malloc(sizeof(char)*10) to create a length 10 string, it'd fail on a Cray 3. But allocating char[10] will be "padded" so work correctly
As I remember, and GCC would need to guard in ABI
So I think, maybe, we're both right
/Cinny
@jhwgh1968 standard C was designed with CHAR_BIT ≥ 8 in mind. if a well formed program doesn’t work on CHAR_BIT 9 or, indeed, CHAR_BIT 64 that would be a spec bug
the size argument to malloc (same with any other size argument) is in multiples of char size. so it would allocate 80 octets of memory as expected
@charlotte hmm, interesting
Either way, CHAR_BIT=8 appears to be built into a whole lot of C code that is actually out there unwittingly, so it was a "fun" conversion effort by friends at my former office (in their past ofc)
And that's why I know about the Autotools check
I'm well and truly winding down on this now, satisfied
/Cinny
@jhwgh1968 yeah POSIX requires CHAR_BIT=8 and so is every non-posix programming environment you’d write code for nowadays
/Cinny
@jhwgh1968 my guess is that the 3 groups that would care are legacy codebase maintainers running some ancient vendor c from 20-30 years ago, c standards authors trying to support, who exactly?, and the designer of the deathstation 9k