Re: Suggested method for returning a string from a C program?

bart <bc@freeuk.com> writes:

On 20/03/2025 23:18, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

On 20/03/2025 19:10, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

[...]

stdint.h et al are just ungainly bolt-ons, not fully supported by the
language.

No, they're fully supported by the language.  They've been in the ISO
standard since 1999.

>
I don't think so. They are add-ons that could have been created in
user-code even prior to C99 (user-defined typedefs for 64 bits would
'need long long').

Sure, they could; see Doug Gwyn's q8, for example.
 

All that's happened is that 'stdint.h' has been blessed.

I.e., it was made part of the language, specifically the standard
library that's part of the language standard.  Which is what I said,
but for some reason you disagreed.
Yes, the format specifiers are a bit awkward.  Boo hoo.

>
There's a further problem here:
>
-------------------------------------
#include <stdio.h>
#include <stdint.h>
>
#define strtype(x) _Generic((x),\
    default:            "other",\
    char:               "char",\
    signed char:        "signed char",\
    short:              "short",\
    int:                "int",\
    long:               "long",\
    long long:          "long long",\
    unsigned char:      "unsigned char",\
    unsigned short:     "unsigned short",\
    unsigned int:       "unsigned int",\
    unsigned long:      "unsigned long",\
    unsigned long long: "unsigned long long",\
    int8_t:             "int8",\
    int16_t:            "int16",\
    int32_t:            "int32",\
    int64_t:            "int64",\
    uint8_t:            "uint8",\
    uint16_t:           "uint16",\
    uint32_t:           "uint32",\
    uint64_t:           "uint64"\
)
>
int main(void) {
    uint64_t x;
>
    puts(strtype(x));
}
-------------------------------------
>
Many of the types are aliases of each other. Which ones will be
aliases, can vary by platform.

Yes, that's a known problem.

Has it actually inconvenienced you?

[...]

This is the opposite of how it works in stdint.h, where specific-width
types are defined on top of non-specific-width ones! It's just
backwards.

The non-specific-width types have been in the language nearly since
the beginning (K&R1, 1978 had most of them).  The C99 committee
decided to add fixed-width types, and <stdint.h> was how they did
it, defining them on top of the existing types (which absolutely
weren't going away).  Any solution that you would not consider to be
"backwards" would have been impractical.

I'll note that an implementation *could* define all the typedefs
in <stdint.h> in terms of new extended integer types, which might
solve the _Generic problem above *for that implementation*.  For that
matter, C99 could have required it.  The committee and implementers
likely didn't think of it at the time, or didn't think it was
worth the added complication to the language.  (As far as I know,
no implementations have implemented any extended integer types;
gcc's __int128 doesn't qualify.)

Or, rather than typedefs, they could have defined new language syntax
that would allow things like uint8_t to be specified -- but any such
syntax would be either excessively verbose or excessively terse,
and programmers would inevitably define their own typedefs.

With the solution they chose, the new types could be defined just
in the library, with no changes to the compiler.

In any case, I suggest that fixed-width types are not as fundamental
as you seem to think they are.  They're useful when you need to
conform to an externally defined interface, but if I'm writing
FizzBuzz, for example, I don't care what the upper bound of an
integer type is a long as it's at least 101.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */