Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Wed, 9 Apr 2025 11:20:43 +0300
Organization: A noiseless patient Spider
Lines: 106
Message-ID: <20250409112043.00006728@yahoo.com>
References: <87y0wjaysg.fsf@gmail.com>
	<vsj1m8$1f8h2$1@dont-email.me>
	<vsrqsh$qhuu$2@solani.org>
	<vt38i9$29prg$1@dont-email.me>
	<vt3dgd$2djqe$3@dont-email.me>
	<vt3gdq$2i87c$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Wed, 09 Apr 2025 10:20:43 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="644d447233835e2adaf6a2a915809f6d";
	logging-data="197353"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+7zvj1CEE8V0Ja+RuWgWup9iXyzjZnYI8="
Cancel-Lock: sha1:eaCGnggR1jVrOH+rX5Ht3psgBak=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 4345

On Tue, 8 Apr 2025 16:47:07 +0100
bart <bc@freeuk.com> wrote:

> On 08/04/2025 15:57, David Brown wrote:
> > On 08/04/2025 15:32, bart wrote: =20
> >> On 05/04/2025 18:56, Philipp Klaus Krause wrote: =20
> >>> Am 02.04.25 um 11:57 schrieb bart: =20
> >>>> * Where are the fixed-width types from stdint.h? =20
> >>>
> >>> Same as for size_t, etc: They don't exist. Those are not separate=20
> >>> types, just typedefs to some other types. E.g. uint16_t could be=20
> >>> typedef'ed to unsigned int.
> >>> =20
> >>
> >> This is the point I made a few weeks back, but others insisted
> >> they were part of C:
> >>
> >>
> >> Me: =20
> >> =C2=A0>> stdint.h et al are just ungainly bolt-ons, not fully supported
> >> by the >> language. =20
> >>
> >> Keith Thompson:
> >> =20
> >> =C2=A0> No, they're fully supported by the language.=C2=A0 They've bee=
n in
> >> the ISO > standard since 1999.
> >> =C2=A0> =20
> >>
> >> This is an exchange posted on 20-Mar-2025 at 19:10 GMT (header
> >> shows 'Thu, 20 Mar 2025 12:10:22 -0700')
> >>
> >> Clearly, they're not quite as fully supported as short, int etc;
> >> they are usually just aliases. But that needn't stop them being
> >> shown on such a chart. =20
> >=20
> > Standard aliases are part of the language standard, and therefore=20
> > standard and fully supported parts of the language.
> >  =20
>=20
> So, should they have been on that chart?
>=20
>  > and fully supported parts of the language. =20
>=20
> Differences between 'unsigned long long int' and 'uint64_t' up to C23:
>=20
>                           uint64_t   unsigned long long int
>=20
> Works without header     No         Yes
>=20
> Literal suffix           No         Yes (ULL etc)
>=20
> Dedicated printf format  No         Yes (%llu)
>=20
> Dedicated scanf format   No         Yes (whatever that might be)
>=20
> sizeof() might not be 8  No         Maybe

I don't think that 'No' above is correct.
Take, for example, ADI SHARC DSPs. Traditionally, sizeof(uint64_t) was
2.=20
I looked into the latest manual and see that now their compiler have
an option -char-size-8 and with this option sizeof(uint64_t)=3D8. But
this option is available only for those members of SHARC family that
have HW support for byte addressing. Even for those, -char-size-8 is
not a default.

>=20
> Reserved word[1]         No         Yes
>=20
> Outside lexical scope[2] No         Yes
>=20
> Incompatible with
>   unsigned long int       No         Yes
>

I don't understand why you say 'No'. AFAIK, on all existing systems
except 64-bit Unixen the answer is 'Yes'.

>=20
> [1] Maybe _t names are reserved, but this:
>=20
>    typedef struct {int x,y;} uint64_t;
>=20
> compiles cleanly with:
>=20
>    gcc -std=3Dc23 -Wall -Wextra -pedantic
>=20
> This means that they could legally be used for any user-defined types.
>=20
> [2] This is possible with uint64_t:
>=20
>    #include <stdint.h>
>=20
>    int main() {
>        typedef struct {int x,y;} uint64_t;
>    }
>=20
> You can shadow the names from stdint.h.
>=20
> So I'd dispute they are as fully supported and 'special' as built-in
> types.
>=20
>=20