On 8/4/23 10:25 AM, Bart wrote:
> On 04/08/2023 14:56, Scott Lurndal wrote:
> > David Brown <david.brown@hesbynett.no> writes:
> >> On 04/08/2023 00:44, Keith Thompson wrote:
> >>> David Brown <david.brown@hesbynett.no> writes:
> >>>> On 03/08/2023 03:07, Bart wrote:
> >>> [...]
> >>>>> BTW in your link, a few languages have aliases for the same
> >>>>> type. That includes 'int = int32_t' for Objective C.
> >>>>
> >>>> I don't know if that is accurate or not - I am not familiar with
> >>>> Objective C.  (In C, it certainly is not accurate.)
> >>>
> >>> The link is
> >>>
> https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(basic_instructions)#Integers
> >>>
> >>> The row for Objective C is actually labeled "Objective-C (Cocoa)",
> which
> >>> may refer to a particular implementation of Objective-C.  The
> >>> information is likely correct for that implementation.
> >>>
> >>> There apparently is no standard document for Objective-C, but it's
> >>> intended to be a strict superset of C (which C++ is not).  That would
> >>> imply that it must define int and int32_t the same way C does.  There
> >>> may or may not be any Objective-C implementations where int32_t is not
> >>> defined as int, but there certainly could be.  (But with Swift
> intended
> >>> to replace Objective-C, I wouldn't expect any new Objective-C
> >>> implementations.)
> >>>
> >>> [...]
> >>>
> >>
> >> Sounds reasonable.
> >>
> >> I do know that on 32-bit ARM, "int32_t" is a typedef for "long int",
> not
> >> "int".  (I don't know why, and I am curious if anyone else does -
> 32-bit
> >> ARM is far and away the most popular architecture for embedded devices,
> >> in terms of the number of developers and projects, so it is an
> important
> >> target system.)
> >
> > It depends on how the platform ABI defines long.
> >
> >
> arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/arm-none-eabi/include/machine/_default_types.h:
> >
> > #ifdef __INT32_TYPE__
> > typedef __INT32_TYPE__ __int32_t;
> > #ifdef __UINT32_TYPE__
> > typedef __UINT32_TYPE__ __uint32_t;
> > #else
> > typedef unsigned __INT32_TYPE__ __uint32_t;
> > #endif
> > #define ___int32_t_defined 1
> > #elif __EXP(INT_MAX) == 0x7fffffffL
> > typedef signed int __int32_t;
> > typedef unsigned int __uint32_t;
> > #define ___int32_t_defined 1
> > #elif __EXP(LONG_MAX) == 0x7fffffffL
> > typedef signed long __int32_t;
> > typedef unsigned long __uint32_t;
> > #define ___int32_t_defined 1
> > #elif __EXP(SHRT_MAX) == 0x7fffffffL
> > typedef signed short __int32_t;
> > typedef unsigned short __uint32_t;
> > #define ___int32_t_defined 1
> > #elif __EXP(SCHAR_MAX) == 0x7fffffffL
> > typedef signed char __int32_t;
> > typedef unsigned char __uint32_t;
> > #define ___int32_t_defined 1
> > #endif
>
> This is part of an implementation for, what, a compiler? You'd think a
> compiler would know the sizes of its types!
>
> Otherwise why is this code defining __int32_t? This is not even int32_t,
> what will that __int32_t be used for, surely not int32_t at some later
> point, and within what program?
>
> It seems that this piece of code wants to define "__int32_t", but
> doesn't know which standard type the underlying C compiler uses that
> happens to be 32 bits. (It also looks like it will fail if there is no
> such type.)
>
> What's that __INT32_TYPE__ all about? Decades on since C99 and still
> there are myriad aliases for such types lurking everywhere.
>
> I've never seen so palaver defining a simple type.
>
>

Remmber, the compiler is only allowed to use int32_t if <stdint.h> has
been included. If it hasn't, then then name is still in user name space.

__int32_t is always in the implementation namespace, so can be freely
defined for library code that might be written to work for multiple
targers (as most code is).

Such a file is a natural for a part of the library that might not want
to fix what processor it is being written for.

Maybe your problem is you dont understand that there are more than one
type of processors, and code (even implementation code) may want to be
written to work on many different processors (or modes on a given processor)

On 04/08/2023 22:05, Richard Damon wrote:
> On 8/4/23 10:25 AM, Bart wrote:
>> On 04/08/2023 14:56, Scott Lurndal wrote:
>> > David Brown <david.brown@hesbynett.no> writes:
>> >> On 04/08/2023 00:44, Keith Thompson wrote:
>> >>> David Brown <david.brown@hesbynett.no> writes:
>> >>>> On 03/08/2023 03:07, Bart wrote:
>> >>> [...]
>> >>>>> BTW in your link, a few languages have aliases for the same
>> >>>>> type. That includes 'int = int32_t' for Objective C.
>> >>>>
>> >>>> I don't know if that is accurate or not - I am not familiar with
>> >>>> Objective C. (In C, it certainly is not accurate.)
>> >>>
>> >>> The link is
>> >>>
>>
https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(basic_instructions)#Integers
>> >>>
>> >>> The row for Objective C is actually labeled "Objective-C
>> (Cocoa)", which
>> >>> may refer to a particular implementation of Objective-C. The
>> >>> information is likely correct for that implementation.
>> >>>
>> >>> There apparently is no standard document for Objective-C, but it's
>> >>> intended to be a strict superset of C (which C++ is not). That
>> would
>> >>> imply that it must define int and int32_t the same way C does.
>> There
>> >>> may or may not be any Objective-C implementations where int32_t
>> is not
>> >>> defined as int, but there certainly could be. (But with Swift
>> intended
>> >>> to replace Objective-C, I wouldn't expect any new Objective-C
>> >>> implementations.)
>> >>>
>> >>> [...]
>> >>>
>> >>
>> >> Sounds reasonable.
>> >>
>> >> I do know that on 32-bit ARM, "int32_t" is a typedef for "long
>> int", not
>> >> "int". (I don't know why, and I am curious if anyone else does -
>> 32-bit
>> >> ARM is far and away the most popular architecture for embedded
>> devices,
>> >> in terms of the number of developers and projects, so it is an
>> important
>> >> target system.)
>> >
>> > It depends on how the platform ABI defines long.
>> >
>> >
>>
arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/arm-none-eabi/include/machine/_default_types.h:
>> >
>> > #ifdef __INT32_TYPE__
>> > typedef __INT32_TYPE__ __int32_t;
>> > #ifdef __UINT32_TYPE__
>> > typedef __UINT32_TYPE__ __uint32_t;
>> > #else
>> > typedef unsigned __INT32_TYPE__ __uint32_t;
>> > #endif
>> > #define ___int32_t_defined 1
>> > #elif __EXP(INT_MAX) == 0x7fffffffL
>> > typedef signed int __int32_t;
>> > typedef unsigned int __uint32_t;
>> > #define ___int32_t_defined 1
>> > #elif __EXP(LONG_MAX) == 0x7fffffffL
>> > typedef signed long __int32_t;
>> > typedef unsigned long __uint32_t;
>> > #define ___int32_t_defined 1
>> > #elif __EXP(SHRT_MAX) == 0x7fffffffL
>> > typedef signed short __int32_t;
>> > typedef unsigned short __uint32_t;
>> > #define ___int32_t_defined 1
>> > #elif __EXP(SCHAR_MAX) == 0x7fffffffL
>> > typedef signed char __int32_t;
>> > typedef unsigned char __uint32_t;
>> > #define ___int32_t_defined 1
>> > #endif
>>
>> This is part of an implementation for, what, a compiler? You'd think a
>> compiler would know the sizes of its types!
>>
>> Otherwise why is this code defining __int32_t? This is not even
>> int32_t, what will that __int32_t be used for, surely not int32_t at
>> some later point, and within what program?
>>
>> It seems that this piece of code wants to define "__int32_t", but
>> doesn't know which standard type the underlying C compiler uses that
>> happens to be 32 bits. (It also looks like it will fail if there is no
>> such type.)
>>
>> What's that __INT32_TYPE__ all about? Decades on since C99 and still
>> there are myriad aliases for such types lurking everywhere.
>>
>> I've never seen so palaver defining a simple type.
>>
>>
>
> Remmber, the compiler is only allowed to use int32_t if <stdint.h> has
> been included. If it hasn't, then then name is still in user name space.
>
> __int32_t is always in the implementation namespace, so can be freely
> defined for library code that might be written to work for multiple
> targers (as most code is).
>
> Such a file is a natural for a part of the library that might not want
> to fix what processor it is being written for.
>
> Maybe your problem is you dont understand that there are more than one
> type of processors, and code (even implementation code) may want to be
> written to work on many different processors (or modes on a given
> processor)

Presumably `__int32_t` is being defined on top of whatever 32-bit type
the C compiler has.

So why doesn't it just define it on top of `int32_t`? Or better, forget
`__int32_t` and just use `int32_t`?

Don't tell me, there is some really, really complicated reason why it
has to be done like this (maybe these are some of those programmers paid
by the line!).

That example is just ridiculous. And I've seen plenty just like it. It
seems C is still a breeding ground for pointless typedefs a quarter of a
century after C99 was supposed to put paid to it.

On 8/4/23 5:32 PM, Bart wrote:
>
> On 04/08/2023 22:05, Richard Damon wrote:
> > On 8/4/23 10:25 AM, Bart wrote:
> >> On 04/08/2023 14:56, Scott Lurndal wrote:
> >>  > David Brown <david.brown@hesbynett.no> writes:
> >>  >> On 04/08/2023 00:44, Keith Thompson wrote:
> >>  >>> David Brown <david.brown@hesbynett.no> writes:
> >>  >>>> On 03/08/2023 03:07, Bart wrote:
> >>  >>> [...]
> >>  >>>>> BTW in your link, a few languages have aliases for the same
> >>  >>>>> type. That includes 'int = int32_t' for Objective C.
> >>  >>>>
> >>  >>>> I don't know if that is accurate or not - I am not familiar with
> >>  >>>> Objective C.  (In C, it certainly is not accurate.)
> >>  >>>
> >>  >>> The link is
> >>  >>>
> >>
> https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(basic_instructions)#Integers
> >>  >>>
> >>  >>> The row for Objective C is actually labeled "Objective-C
> >> (Cocoa)", which
> >>  >>> may refer to a particular implementation of Objective-C.  The
> >>  >>> information is likely correct for that implementation.
> >>  >>>
> >>  >>> There apparently is no standard document for Objective-C, but it's
> >>  >>> intended to be a strict superset of C (which C++ is not).  That
> >> would
> >>  >>> imply that it must define int and int32_t the same way C does.
> >> There
> >>  >>> may or may not be any Objective-C implementations where int32_t
> >> is not
> >>  >>> defined as int, but there certainly could be.  (But with Swift
> >> intended
> >>  >>> to replace Objective-C, I wouldn't expect any new Objective-C
> >>  >>> implementations.)
> >>  >>>
> >>  >>> [...]
> >>  >>>
> >>  >>
> >>  >> Sounds reasonable.
> >>  >>
> >>  >> I do know that on 32-bit ARM, "int32_t" is a typedef for "long
> >> int", not
> >>  >> "int".  (I don't know why, and I am curious if anyone else does -
> >> 32-bit
> >>  >> ARM is far and away the most popular architecture for embedded
> >> devices,
> >>  >> in terms of the number of developers and projects, so it is an
> >> important
> >>  >> target system.)
> >>  >
> >>  > It depends on how the platform ABI defines long.
> >>  >
> >>  >
> >>
> arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/arm-none-eabi/include/machine/_default_types.h:
> >>  >
> >>  > #ifdef __INT32_TYPE__
> >>  > typedef __INT32_TYPE__ __int32_t;
> >>  > #ifdef __UINT32_TYPE__
> >>  > typedef __UINT32_TYPE__ __uint32_t;
> >>  > #else
> >>  > typedef unsigned __INT32_TYPE__ __uint32_t;
> >>  > #endif
> >>  > #define ___int32_t_defined 1
> >>  > #elif __EXP(INT_MAX) == 0x7fffffffL
> >>  > typedef signed int __int32_t;
> >>  > typedef unsigned int __uint32_t;
> >>  > #define ___int32_t_defined 1
> >>  > #elif __EXP(LONG_MAX) == 0x7fffffffL
> >>  > typedef signed long __int32_t;
> >>  > typedef unsigned long __uint32_t;
> >>  > #define ___int32_t_defined 1
> >>  > #elif __EXP(SHRT_MAX) == 0x7fffffffL
> >>  > typedef signed short __int32_t;
> >>  > typedef unsigned short __uint32_t;
> >>  > #define ___int32_t_defined 1
> >>  > #elif __EXP(SCHAR_MAX) == 0x7fffffffL
> >>  > typedef signed char __int32_t;
> >>  > typedef unsigned char __uint32_t;
> >>  > #define ___int32_t_defined 1
> >>  > #endif
> >>
> >> This is part of an implementation for, what, a compiler? You'd think a
> >> compiler would know the sizes of its types!
> >>
> >> Otherwise why is this code defining __int32_t? This is not even
> >> int32_t, what will that __int32_t be used for, surely not int32_t at
> >> some later point, and within what program?
> >>
> >> It seems that this piece of code wants to define "__int32_t", but
> >> doesn't know which standard type the underlying C compiler uses that
> >> happens to be 32 bits. (It also looks like it will fail if there is no
> >> such type.)
> >>
> >> What's that __INT32_TYPE__ all about? Decades on since C99 and still
> >> there are myriad aliases for such types lurking everywhere.
> >>
> >> I've never seen so palaver defining a simple type.
> >>
> >>
> >
> > Remmber, the compiler is only allowed to use int32_t if <stdint.h> has
> > been included. If it hasn't, then then name is still in user name space.
> >
> > __int32_t is always in the implementation namespace, so can be freely
> > defined for library code that might be written to work for multiple
> > targers (as most code is).
> >
> > Such a file is a natural for a part of the library that might not want
> > to fix what processor it is being written for.
> >
> > Maybe your problem is you dont understand that there are more than one
> > type of processors, and code (even implementation code) may want to be
> > written to work on many different processors (or modes on a given
> > processor)
>
> Presumably `__int32_t` is being defined on top of whatever 32-bit type
> the C compiler has.
>
> So why doesn't it just define it on top of `int32_t`? Or better, forget
> `__int32_t` and just use `int32_t`?
>
> Don't tell me, there is some really, really complicated reason why it
> has to be done like this (maybe these are some of those programmers paid
> by the line!).
>
> That example is just ridiculous. And I've seen plenty just like it. It
> seems C is still a breeding ground for pointless typedefs a quarter of a
> century after C99 was supposed to put paid to it.
>

Because int32_t isn't a fundamental tyoe in C. It is only a name that
comes into existance if your included <stdint.h>

The only standardly defined integral types are char, short, int, long,
long long, and the unsigned version of those (plus signed character).

The implementaiton may define names for additional built in types, but
they MUST be defined using names that are unconditionally reserved for
the implementation, which doesn't include int32_t, which is only
reserved if <stdint.h> is included.

Yes, the way the C language is specified, implementation really do need
to use a lot of typedef "magic" behind the scenes using implementation
reserved names, but you aren't expected to be normally looking into
that, but working with the public published API.

Thus, ANY header, except one DEFINED to effectively include <stdint.h>
(like <inttypes.h>) can't use the names like int32_t, because they don't
belong to the implementation there, but must use "private" version of them.

On 2023-08-04, Bart <bc@freeuk.com> wrote:
> Presumably `__int32_t` is being defined on top of whatever 32-bit type
> the C compiler has.
>
> So why doesn't it just define it on top of `int32_t`? Or better, forget
> `__int32_t` and just use `int32_t`?
>
> Don't tell me, there is some really, really complicated reason why it
> has to be done like this (maybe these are some of those programmers paid
> by the line!).

Mostly, the reasons can be summarized by that it's not some solo
developer's recently started greenfield project, but something with a
long history on various kinds of machines, and numerous implementations.
C first had 18 bit int; most machines don't have that now.

Good thing we are not stuck with int18, right?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 04/08/2023 22:47, Kaz Kylheku wrote:
> On 2023-08-04, Bart <bc@freeuk.com> wrote:
>> Presumably `__int32_t` is being defined on top of whatever 32-bit type
>> the C compiler has.
>>
>> So why doesn't it just define it on top of `int32_t`? Or better, forget
>> `__int32_t` and just use `int32_t`?
>>
>> Don't tell me, there is some really, really complicated reason why it
>> has to be done like this (maybe these are some of those programmers paid
>> by the line!).
>
> Mostly, the reasons can be summarized by that it's not some solo
> developer's recently started greenfield project, but something with a
> long history on various kinds of machines, and numerous implementations.
> C first had 18 bit int; most machines don't have that now.
>
> Good thing we are not stuck with int18, right?
>

And the exact reason why that code can't just do:

#include <stdint.h>

typedef int32_t __int32_t;

is? I can't imagine that it still needs to run on the PDP7, and with the
code shown, it wouldn't work anyway.

There have dozens of posts extolling the benefits of using stdint.h, and
not rolling your own types, and now we have a piece of code that
completely ignores that advice.

On 2023-08-04, Bart <bc@freeuk.com> wrote:
> On 04/08/2023 22:47, Kaz Kylheku wrote:
> > On 2023-08-04, Bart <bc@freeuk.com> wrote:
> >> Presumably `__int32_t` is being defined on top of whatever 32-bit type
> >> the C compiler has.
> >>
> >> So why doesn't it just define it on top of `int32_t`? Or better, forget
> >> `__int32_t` and just use `int32_t`?
> >>
> >> Don't tell me, there is some really, really complicated reason why it
> >> has to be done like this (maybe these are some of those programmers paid
> >> by the line!).
> >
> > Mostly, the reasons can be summarized by that it's not some solo
> > developer's recently started greenfield project, but something with a
> > long history on various kinds of machines, and numerous implementations.
> > C first had 18 bit int; most machines don't have that now.
> >
> > Good thing we are not stuck with int18, right?
> >
>
> And the exact reason why that code can't just do:
>
> #include <stdint.h>
>
> typedef int32_t __int32_t;

It appears that this thread is about something found in a
library header _default_types.h.

I don't have a _default_types.h anywhere except a bunch
of Cygwin trees. It looks like a Newlib thing (a library from the
BSD world on which Cygwin is based).

The reason the header cannot just do #include <stdint.h>
is that it is the basis for that header!

$ grep default_types /mnt/c/Cygwin/cygwin64/usr/include/stdint.h
#include <machine/_default_types.h>
$ ls /mnt/c/Cygwin/cygwin64/usr/include/machine/_default_types.h
/mnt/c/Cygwin/cygwin64/usr/include/machine/_default_types.h

The library is designed such that it provides its own <stdint.h>
header, not relying on the compiler providing one. It defines
some underscored types in machine/_default_types.h and then it
uses those to declare the public, standard ones in <stdint.h>.

I would do it similarly, if I had to.

Any more trick questions?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 05/08/2023 01:15, Kaz Kylheku wrote:
> On 2023-08-04, Bart <bc@freeuk.com> wrote:
>> On 04/08/2023 22:47, Kaz Kylheku wrote:
>>> On 2023-08-04, Bart <bc@freeuk.com> wrote:
>>>> Presumably `__int32_t` is being defined on top of whatever 32-bit type
>>>> the C compiler has.
>>>>
>>>> So why doesn't it just define it on top of `int32_t`? Or better,
forget
>>>> `__int32_t` and just use `int32_t`?
>>>>
>>>> Don't tell me, there is some really, really complicated reason why it
>>>> has to be done like this (maybe these are some of those
programmers paid
>>>> by the line!).
>>>
>>> Mostly, the reasons can be summarized by that it's not some solo
>>> developer's recently started greenfield project, but something with a
>>> long history on various kinds of machines, and numerous
implementations.
>>> C first had 18 bit int; most machines don't have that now.
>>>
>>> Good thing we are not stuck with int18, right?
>>>
>>
>> And the exact reason why that code can't just do:
>>
>> #include <stdint.h>
>>
>> typedef int32_t __int32_t;
>
> It appears that this thread is about something found in a
> library header _default_types.h.
>
> I don't have a _default_types.h anywhere except a bunch
> of Cygwin trees. It looks like a Newlib thing (a library from the
> BSD world on which Cygwin is based).
>
> The reason the header cannot just do #include <stdint.h>
> is that it is the basis for that header!
>
> $ grep default_types /mnt/c/Cygwin/cygwin64/usr/include/stdint.h
> #include <machine/_default_types.h>
> $ ls /mnt/c/Cygwin/cygwin64/usr/include/machine/_default_types.h
> /mnt/c/Cygwin/cygwin64/usr/include/machine/_default_types.h
>
> The library is designed such that it provides its own <stdint.h>
> header, not relying on the compiler providing one. It defines
> some underscored types in machine/_default_types.h and then it
> uses those to declare the public, standard ones in <stdint.h>.

Which is going around the houses.

stdint.h should be provided by the C implementation, which knows the
exact sizes of its char, short, int, long, long long types. So int32_t
is typically defined of top of int when it knows int is exactly 32 bits.

Even it if prefers to go through all the basic types looking for the one
with a suitable upper limit, why define the intermediate __int32_t at
all, why not just define int32_t.

> I would do it similarly, if I had to.
I have done it, and mine looks like this inside my stdint.h:

typedef int int32_t;

A bit simpler, isn't it? This is for an x64 target. If I wanted to have
a different target where 'int' was 16 bits or 64 bits, say, then that
would have its own dedicated stdint.h file.

>
> Any more trick questions?

It depends; have you get any more convincing answers, other than this is
the mess that one implementation ended up with and it's like that
because it's nobody's job to clean it up.

On 2023-08-05, Bart <bc@freeuk.com> wrote:
> On 05/08/2023 01:15, Kaz Kylheku wrote:
> > On 2023-08-04, Bart <bc@freeuk.com> wrote:
> >> On 04/08/2023 22:47, Kaz Kylheku wrote:
> >>> On 2023-08-04, Bart <bc@freeuk.com> wrote:
> >>>> Presumably `__int32_t` is being defined on top of whatever 32-bit type
> >>>> the C compiler has.
> >>>>
> >>>> So why doesn't it just define it on top of `int32_t`? Or better,
> forget
> >>>> `__int32_t` and just use `int32_t`?
> >>>>
> >>>> Don't tell me, there is some really, really complicated reason why it
> >>>> has to be done like this (maybe these are some of those
> programmers paid
> >>>> by the line!).
> >>>
> >>> Mostly, the reasons can be summarized by that it's not some solo
> >>> developer's recently started greenfield project, but something with a
> >>> long history on various kinds of machines, and numerous
> implementations.
> >>> C first had 18 bit int; most machines don't have that now.
> >>>
> >>> Good thing we are not stuck with int18, right?
> >>>
> >>
> >> And the exact reason why that code can't just do:
> >>
> >> #include <stdint.h>
> >>
> >> typedef int32_t __int32_t;
> >
> > It appears that this thread is about something found in a
> > library header _default_types.h.
> >
> > I don't have a _default_types.h anywhere except a bunch
> > of Cygwin trees. It looks like a Newlib thing (a library from the
> > BSD world on which Cygwin is based).
> >
> > The reason the header cannot just do #include <stdint.h>
> > is that it is the basis for that header!
> >
> > $ grep default_types /mnt/c/Cygwin/cygwin64/usr/include/stdint.h
> > #include <machine/_default_types.h>
> > $ ls /mnt/c/Cygwin/cygwin64/usr/include/machine/_default_types.h
> > /mnt/c/Cygwin/cygwin64/usr/include/machine/_default_types.h
> >
> > The library is designed such that it provides its own <stdint.h>
> > header, not relying on the compiler providing one. It defines
> > some underscored types in machine/_default_types.h and then it
> > uses those to declare the public, standard ones in <stdint.h>.
>
> Which is going around the houses.
>
> stdint.h should be provided by the C implementation, which knows the
> exact sizes of its char, short, int, long, long long types.

<stdint.h> is described in the Library section of the standard.

Cygwin's Newlib is a library.

This is not rocket science.

Some compilers are not complete C implementations. GCC isn't
a complete, hosted implementation.

It becomes one when combined with a library.

The GNU project, from the start, provided piecemeal replacement
for Unix tools. People used GNU C on Unix boxes, with the library
(including headers) from those Unix boxes.

GNU has a C library, which is a separate project.

GCC + { glibc, uCLibc, musl, Newlib, Bionic, ...} becomes a C
implementation.

I /think/ GCC now does provide a stdint.h? But it wasn't historically
the case. A library that doesn't depend on the compiler providing
a header like stdint.h will just do it itself.

> So int32_t is typically defined of top of int when it knows int is
> exactly 32 bits.

Fair game for a library.
>
> Even it if prefers to go through all the basic types looking for the one
> with a suitable upper limit, why define the intermediate __int32_t at
> all, why not just define int32_t.

This can only be explained by people familiar with the history
of Newlib and its ongoing maintenance.

The code may date back to a time when you could not rely on
compilers providing <stdint.h>. Newlib wanted its users to
have that and so it "polyfilled" it.

Maybe it would be easy to remove that, but nobody has
noticed and bothered.
p > > I would do it similarly, if I had to.
> I have done it, and mine looks like this inside my stdint.h:
>
> typedef int int32_t;
>
> A bit simpler, isn't it?

Look at the machines Newlib supports:

https://sourceware.org/git/?p=newlib-cygwin.git;a=tree;f=newlib/libc/machine

It may be that at least one of them doesn't have a 32 bit int.

You can't compare your green field solo project to something like that.

Newlib is not just the basis for Cygwin.

https://sourceware.org/newlib/

Newlib is a C library intended for use on embedded systems. It is a
conglomeration of several library parts, all under free software
licenses that make them easily usable on embedded products.

Newlib is only available in source form. It can be compiled for a wide
array of processors, and will usually work on any architecture with the
addition of a few low-level routines.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 8/4/23 7:43 PM, Bart wrote:
> On 04/08/2023 22:47, Kaz Kylheku wrote:
> > On 2023-08-04, Bart <bc@freeuk.com> wrote:
> >> Presumably `__int32_t` is being defined on top of whatever 32-bit type
> >> the C compiler has.
> >>
> >> So why doesn't it just define it on top of `int32_t`? Or better, forget
> >> `__int32_t` and just use `int32_t`?
> >>
> >> Don't tell me, there is some really, really complicated reason why it
> >> has to be done like this (maybe these are some of those programmers
> paid
> >> by the line!).
> >
> > Mostly, the reasons can be summarized by that it's not some solo
> > developer's recently started greenfield project, but something with a
> > long history on various kinds of machines, and numerous implementations.
> > C first had 18 bit int; most machines don't have that now.
> >
> > Good thing we are not stuck with int18, right?
> >
>
> And the exact reason why that code can't just do:
>
>     #include <stdint.h>
>
>     typedef int32_t __int32_t;
>
> is? I can't imagine that it still needs to run on the PDP7, and with the
> code shown, it wouldn't work anyway.
>
> There have dozens of posts extolling the benefits of using stdint.h, and
> not rolling your own types, and now we have a piece of code that
> completely ignores that advice.

System headers are not allowed to bring in identifiers from another
system header without explicit indication that it should do so in the
Standard.

As int32_t is an identifier in the user namespace UNLESS <stdint.h> has
been included by USER code, or it is defined to be included by some
header that it includes.

The header you are talking about, is an INTERNAL header, used by system
headers other than <stdint.h>, so it isn't allowed to define symbols
like int32_t

Do you not understand the rules of namespace?

Richard Damon <Richard@Damon-Family.org> writes:

> On 8/4/23 10:25 AM, Bart wrote:
>
>> [...]
>
> Maybe your problem is you dont understand [...]

Bart's problem isn't that he doesn't understand. Bart's
problem is that he doesn't _want_ to understand.

On 2023-08-05, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 8/4/23 10:25 AM, Bart wrote:
>>
>>> [...]
>>
>> Maybe your problem is you dont understand [...]
>
> Bart's problem isn't that he doesn't understand. Bart's
> problem is that he doesn't _want_ to understand.

BartC act a lot like someone whose salary depends on not understanding.

All that is missing is the actual money.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 05/08/2023 03:44, Richard Damon wrote:
> On 8/4/23 7:43 PM, Bart wrote:
>> On 04/08/2023 22:47, Kaz Kylheku wrote:
>> > On 2023-08-04, Bart <bc@freeuk.com> wrote:
>> >> Presumably `__int32_t` is being defined on top of whatever 32-bit
>> type
>> >> the C compiler has.
>> >>
>> >> So why doesn't it just define it on top of `int32_t`? Or better,
>> forget
>> >> `__int32_t` and just use `int32_t`?
>> >>
>> >> Don't tell me, there is some really, really complicated reason
why it
>> >> has to be done like this (maybe these are some of those
>> programmers paid
>> >> by the line!).
>> >
>> > Mostly, the reasons can be summarized by that it's not some solo
>> > developer's recently started greenfield project, but something with a
>> > long history on various kinds of machines, and numerous
>> implementations.
>> > C first had 18 bit int; most machines don't have that now.
>> >
>> > Good thing we are not stuck with int18, right?
>> >
>>
>> And the exact reason why that code can't just do:
>>
>> #include <stdint.h>
>>
>> typedef int32_t __int32_t;
>>
>> is? I can't imagine that it still needs to run on the PDP7, and with
>> the code shown, it wouldn't work anyway.
>>
>> There have dozens of posts extolling the benefits of using stdint.h,
>> and not rolling your own types, and now we have a piece of code that
>> completely ignores that advice.
>
> System headers are not allowed to bring in identifiers from another
> system header without explicit indication that it should do so in the
> Standard.
>
> As int32_t is an identifier in the user namespace UNLESS <stdint.h> has
> been included by USER code, or it is defined to be included by some
> header that it includes.
>
> The header you are talking about, is an INTERNAL header, used by system
> headers other than <stdint.h>, so it isn't allowed to define symbols
> like int32_t
>
> Do you not understand the rules of namespace?

So, despite C99 introducing those types in stdint.h, system headers are
not allowed to use stdint.h because it int32_t cannot be exposed to user
programs unless they explicitly include stdint.h?

And those system headers cannot have stdint.h being included in any
internal headerss that they call, for the same reason?

Does that mean that none of the functions of the C runtime declared in
the system headers will ever be allowed to use C99 types?

It gets better and better!

This explanation is anyway at odds with that provided by Kaz, where the
code apparently is in an external library, not a component of the system
library.

If what you say is the case, then NO library should be allowed to use
int32_t in their APIs, unless a prior '#include <stdint.h>' has been
seen in any user code that wants to use that library.

Because the user might be defining int32_t for their own purposes?
(Isn't a _t suffix reserved?

I find that abolutely extraordinary.

I thought C's type system was already a complete mess. This is verging
on unbelievable.

So, basically, C doesn't really have int32_t as a type, not one you can
just use anywhere; it is a privileged type.

On 05/08/2023 03:11, Kaz Kylheku wrote:
> On 2023-08-05, Bart <bc@freeuk.com> wrote:
>> On 05/08/2023 01:15, Kaz Kylheku wrote:
>>> On 2023-08-04, Bart <bc@freeuk.com> wrote:
>>>> On 04/08/2023 22:47, Kaz Kylheku wrote:
>>>>> On 2023-08-04, Bart <bc@freeuk.com> wrote:
>>>>>> Presumably `__int32_t` is being defined on top of whatever
32-bit type
>>>>>> the C compiler has.
>>>>>>
>>>>>> So why doesn't it just define it on top of `int32_t`? Or better,
>> forget
>>>>>> `__int32_t` and just use `int32_t`?
>>>>>>
>>>>>> Don't tell me, there is some really, really complicated reason
why it
>>>>>> has to be done like this (maybe these are some of those
>> programmers paid
>>>>>> by the line!).
>>>>>
>>>>> Mostly, the reasons can be summarized by that it's not some solo
>>>>> developer's recently started greenfield project, but something with a
>>>>> long history on various kinds of machines, and numerous
>> implementations.
>>>>> C first had 18 bit int; most machines don't have that now.
>>>>>
>>>>> Good thing we are not stuck with int18, right?
>>>>>
>>>>
>>>> And the exact reason why that code can't just do:
>>>>
>>>> #include <stdint.h>
>>>>
>>>> typedef int32_t __int32_t;
>>>
>>> It appears that this thread is about something found in a
>>> library header _default_types.h.
>>>
>>> I don't have a _default_types.h anywhere except a bunch
>>> of Cygwin trees. It looks like a Newlib thing (a library from the
>>> BSD world on which Cygwin is based).
>>>
>>> The reason the header cannot just do #include <stdint.h>
>>> is that it is the basis for that header!
>>>
>>> $ grep default_types /mnt/c/Cygwin/cygwin64/usr/include/stdint.h
>>> #include <machine/_default_types.h>
>>> $ ls /mnt/c/Cygwin/cygwin64/usr/include/machine/_default_types.h
>>> /mnt/c/Cygwin/cygwin64/usr/include/machine/_default_types.h
>>>
>>> The library is designed such that it provides its own <stdint.h>
>>> header, not relying on the compiler providing one. It defines
>>> some underscored types in machine/_default_types.h and then it
>>> uses those to declare the public, standard ones in <stdint.h>.
>>
>> Which is going around the houses.
>>
>> stdint.h should be provided by the C implementation, which knows the
>> exact sizes of its char, short, int, long, long long types.
>
> <stdint.h> is described in the Library section of the standard.
>
> Cygwin's Newlib is a library.
>
> This is not rocket science.
>
> Some compilers are not complete C implementations. GCC isn't
> a complete, hosted implementation.
>
> It becomes one when combined with a library.
>
> The GNU project, from the start, provided piecemeal replacement
> for Unix tools. People used GNU C on Unix boxes, with the library
> (including headers) from those Unix boxes.
>
> GNU has a C library, which is a separate project.
>
> GCC + { glibc, uCLibc, musl, Newlib, Bionic, ...} becomes a C
> implementation.
>
> I /think/ GCC now does provide a stdint.h? But it wasn't historically
> the case. A library that doesn't depend on the compiler providing
> a header like stdint.h will just do it itself.
>
>> So int32_t is typically defined of top of int when it knows int is
>> exactly 32 bits.
>
> Fair game for a library.
>>
>> Even it if prefers to go through all the basic types looking for the one
>> with a suitable upper limit, why define the intermediate __int32_t at
>> all, why not just define int32_t.
>
> This can only be explained by people familiar with the history
> of Newlib and its ongoing maintenance.
>
> The code may date back to a time when you could not rely on
> compilers providing <stdint.h>. Newlib wanted its users to
> have that and so it "polyfilled" it.
>
> Maybe it would be easy to remove that, but nobody has
> noticed and bothered.
> p
>>> I would do it similarly, if I had to.
>> I have done it, and mine looks like this inside my stdint.h:
>>
>> typedef int int32_t;
>>
>> A bit simpler, isn't it?
>
> Look at the machines Newlib supports:
>
>
https://sourceware.org/git/?p=newlib-cygwin.git;a=tree;f=newlib/libc/machine

So each of those dozens of targets (which mostly seem to use
8-16-32-64-bit word sizes) has its own set of headers?

Even better! Use a dedicated header for each one that defines __int32_t
using one typedef.
> It may be that at least one of them doesn't have a 32 bit int.
>
> You can't compare your green field solo project to something like that.

I've written compilers for five architectures, starting in 1979.

I take a different approach: I don't try and support myriad different
targets spanning decades using only a single file that is a mess of
conditional code blocks.

> Newlib is not just the basis for Cygwin.
>
> https://sourceware.org/newlib/
>
> Newlib is a C library intended for use on embedded systems.

And? I gave a link yesterday to a header designed for use on Arduino, it
had:

typedef uint8_t byte;

So breaking two rules at once: using stdint.h (imagine if a user program
included arduino.h, but is inadvertently exposed to uint8_t which must
be kept under wraps unless they explicitly use stdint.h), and defining a
much better alias for a C99 type,.

On 04/08/2023 18:17, Malcolm McLean wrote:
> On Friday, 4 August 2023 at 17:05:05 UTC+1, David Brown wrote:
>> On 04/08/2023 17:20, Malcolm McLean wrote:
>>> On Friday, 4 August 2023 at 16:12:39 UTC+1, David Brown wrote:
>>>> On 04/08/2023 16:20, Spiros Bousbouras wrote:
>>>>> On Thu, 3 Aug 2023 11:42:36 +0200
>>>>> David Brown <david...@hesbynett.no> wrote:
>>>>>> When I
>>>>>> am looking for software, if I find a possible option and see it is
>>>>>> written in ANSI C90, I assume it is some ancient and outdated tool. It
>>>>>> /might/ still be useful, but I start with a big negative bias.
>>>>>
>>>>> That's a strange attitude. If it is written in "old" C then likely it
>>>>> was written a long time ago but it certainly doesn't follow that it is
>>>>> outdated.
>>>> True, of course. For some things, old software is just as good as new
>>>> software - if the task hasn't changed, the software does not need to
>>>> change. But for other kinds of software you want to be sure that it is
>>>> relatively modern, or at least well maintained. That might be for
>>>> supporting newer formats (in the case of a "resource compiler"), or
>>>> perhaps it is software for which security is a concern. The software
>>>> might also be written for older and weaker compilers - using "tricks"
>>>> that were popular before, but are undefined behaviour in C and can fail
>>>> with modern compilers. Being in an ancient C dialect does not guarantee
>>>> that it is outdated, but it is a pointer in that direction.
>>>>
>>>> I would also have no interest in a "resource compiler" that generated C
>>>> files that did not use <stdint.h> or <stdbool.h> types when appropriate,
>>>> but perpetuated the inconvenience of home-made types.
>>>>
>>> It doesn't output homemade types like "u8" for a char. But it doesn't use
>>> <stdint.h> or <stdbool.h> types either. It outputs the basic C types.
>> That would be useless. Few people doing embedded work have any interest
>> in something that turns resources (such as files to be embedded) into
>> arrays of "short" or "unsigned long". Use "int16_t", "uint32_t", or
>> whatever matches the resource type.
>>
>> This can be done in a dozen lines of Python scripting, and I get exactly
>> what I need. I do so regularly for embedded bitmaps, or static files
>> for an embedded webserver, and that kind of thing.
>>
> Yes, pretty much every C programmer has written a scratch program
> to read in a binary and output C source. I can't find a tool that allows you
> to get away from that, except the Baby X resource compiler. Whether that
> is bad thing, meaning there's no demand for such a tool, or a good thing,
> meaning it has a niche no-one else has thought of, I don't know.

I think most cases need nothing more than converting a single file into
a const array of uint8_t (or unsigned char if you prefer). Anything
other than that, and I would not expect a pre-written tool to support
what you want because you are likely to have particular needs at the
time. When I have embedded fonts, image sequences, directory
structures, etc., they have always been targeting a particular format
for the application - general purpose or third-party conversion tools
would be of no use at all.

Some graphics libraries come with "resource compilers" generating
results in the format needed for the library. So if your "Baby X" has
its own graphics format (or audio format), then a "resource compiler"
turning standard formats into this internal format would make sense.
But I fail to see how useful it would be for those not using "Baby X".

I also can't imagine why anyone would want to put strings in an xml file
instead of just putting them in the source code directly - it gives you
no advantages. (If it organised strings and formats for
internationalisation and translation, that would be a different matter.)

So as I see it, "resource compiling" is either trivial, library-specific
(in which case a resource compiler could be a useful program), or too
specialised to be supportable by a general program.

And C23 will cover the trivial case with "#embed". Of course, it will
take some time for people to move to C23.

>>>
>>> That's because it was orignally designed for use with Baby X, which
>>> doesn't use <stdint.h" or <stdbool.h> types in its API interface.
>>> But I could add a flag to the resource compiler to output <stdint.h>
>>> known width types if people think that that's important.
>>>
>> I think it is. But I doubt if it will be a big hit with embedded
>> programmers anyway.
>>
> There's no reason for any of the data to be fixed size that I can think of.
> But what do I know.
>

Embedded programmers like fixed sizes, even when they are not strictly
necessary. I think it is critical to be very clear that the types you
use are big enough to support the data and ranges you want. And in
embedded systems, you never want to waste space without reason - so you
want to be sure things are not bigger than they have to be. The ideal
type choices are therefore "uint_least16_t" and similar "least" types
from <stdint.h>. However, since the "least" types match the fixed size
types in almost every case (and programming for targets that don't
support 8-bit and 16-bit types directly is niche and dedicated work),
the norm is to use "uint16_t" and similar fixed-size types.

On Saturday, 5 August 2023 at 12:40:10 UTC+1, David Brown wrote:
> On 04/08/2023 18:17, Malcolm McLean wrote:
> > On Friday, 4 August 2023 at 17:05:05 UTC+1, David Brown wrote:
> >> On 04/08/2023 17:20, Malcolm McLean wrote:
> >>> On Friday, 4 August 2023 at 16:12:39 UTC+1, David Brown wrote:
> >>>> On 04/08/2023 16:20, Spiros Bousbouras wrote:
> >>>>> On Thu, 3 Aug 2023 11:42:36 +0200
> >>>>> David Brown <david...@hesbynett.no> wrote:
> >>>>>> When I
> >>>>>> am looking for software, if I find a possible option and see it is
> >>>>>> written in ANSI C90, I assume it is some ancient and outdated tool. It
> >>>>>> /might/ still be useful, but I start with a big negative bias.
> >>>>>
> >>>>> That's a strange attitude. If it is written in "old" C then likely it
> >>>>> was written a long time ago but it certainly doesn't follow that it is
> >>>>> outdated.
> >>>> True, of course. For some things, old software is just as good as new
> >>>> software - if the task hasn't changed, the software does not need to
> >>>> change. But for other kinds of software you want to be sure that it is
> >>>> relatively modern, or at least well maintained. That might be for
> >>>> supporting newer formats (in the case of a "resource compiler"), or
> >>>> perhaps it is software for which security is a concern. The software
> >>>> might also be written for older and weaker compilers - using "tricks"
> >>>> that were popular before, but are undefined behaviour in C and can fail
> >>>> with modern compilers. Being in an ancient C dialect does not guarantee
> >>>> that it is outdated, but it is a pointer in that direction.
> >>>>
> >>>> I would also have no interest in a "resource compiler" that generated C
> >>>> files that did not use <stdint.h> or <stdbool.h> types when appropriate,
> >>>> but perpetuated the inconvenience of home-made types.
> >>>>
> >>> It doesn't output homemade types like "u8" for a char. But it doesn't use
> >>> <stdint.h> or <stdbool.h> types either. It outputs the basic C types.
> >> That would be useless. Few people doing embedded work have any interest
> >> in something that turns resources (such as files to be embedded) into
> >> arrays of "short" or "unsigned long". Use "int16_t", "uint32_t", or
> >> whatever matches the resource type.
> >>
> >> This can be done in a dozen lines of Python scripting, and I get exactly
> >> what I need. I do so regularly for embedded bitmaps, or static files
> >> for an embedded webserver, and that kind of thing.
> >>
> > Yes, pretty much every C programmer has written a scratch program
> > to read in a binary and output C source. I can't find a tool that allows you
> > to get away from that, except the Baby X resource compiler. Whether that
> > is bad thing, meaning there's no demand for such a tool, or a good thing,
> > meaning it has a niche no-one else has thought of, I don't know.
> I think most cases need nothing more than converting a single file into
> a const array of uint8_t (or unsigned char if you prefer). Anything
> other than that, and I would not expect a pre-written tool to support
> what you want because you are likely to have particular needs at the
> time. When I have embedded fonts, image sequences, directory
> structures, etc., they have always been targeting a particular format
> for the application - general purpose or third-party conversion tools
> would be of no use at all.
>
This is the problem of course. The Baby X API expects data in a certain format.
So all the API functions which operate on images take a 32 bit RGBA buffer
as an "unsigned char *", and the dimensions as two ints. But another API might
use an opaque "IMAGE" structure. Or another system might have 16 bit r5g5b5a1
images.
Of course I could put in a flexible format specifier. But it would rapidly turn into
a scripting laugage in its onw right. In which case you might as well use Python.
>
> Some graphics libraries come with "resource compilers" generating
> results in the format needed for the library. So if your "Baby X" has
> its own graphics format (or audio format), then a "resource compiler"
> turning standard formats into this internal format would make sense.
> But I fail to see how useful it would be for those not using "Baby X".
>
Reality is that the resouce compiler is more popular than Baby X. But
exactly how people are using it, I don't know
>
> I also can't imagine why anyone would want to put strings in an xml file
> instead of just putting them in the source code directly - it gives you
> no advantages. (If it organised strings and formats for
> internationalisation and translation, that would be a different matter.)
>
There is an "international" tag so you can do this
<international name = "hello">
<string language = "english">Hello</string>
<string language = "french">Bonjour</string>
<utf8 language = "chinese"> [utf8 here] </utf8>
</international>

Then it creates a C-callable function which is passed the languafe and returns
thr right string.
>
> So as I see it, "resource compiling" is either trivial, library-specific
> (in which case a resource compiler could be a useful program), or too
> specialised to be supportable by a general program.
>
> And C23 will cover the trivial case with "#embed". Of course, it will
> take some time for people to move to C23.
>
Yes. Whilst of course there is a <binary> tag to allow for the trivial case,
that isn't the strength of the Baby X resource compiler. The strength is the ability
to transform data from complex input formats to simple output formats.
>
> >>>
> >>> That's because it was orignally designed for use with Baby X, which
> >>> doesn't use <stdint.h" or <stdbool.h> types in its API interface.
> >>> But I could add a flag to the resource compiler to output <stdint.h>
> >>> known width types if people think that that's important.
> >>>
> >> I think it is. But I doubt if it will be a big hit with embedded
> >> programmers anyway.
> >>
> > There's no reason for any of the data to be fixed size that I can think of.
> > But what do I know.
> >
> Embedded programmers like fixed sizes, even when they are not strictly
> necessary. I think it is critical to be very clear that the types you
> use are big enough to support the data and ranges you want. And in
> embedded systems, you never want to waste space without reason - so you
> want to be sure things are not bigger than they have to be. The ideal
> type choices are therefore "uint_least16_t" and similar "least" types
> from <stdint.h>. However, since the "least" types match the fixed size
> types in almost every case (and programming for targets that don't
> support 8-bit and 16-bit types directly is niche and dedicated work),
> the norm is to use "uint16_t" and similar fixed-size types.
>
I might add a flag for stdint.h types. Whilst it's fairly trivial in algorithmic terms,
it complicates the output code quite a bit, and will make it harder for somone
coming new to the program to modify.

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2023-08-04, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> typedef unsigned long Index;
>>
>> void
>> convolve(
>> float *out, const float *in, Index N, const float *filter, Index Nf
>> ){
>> Index i, j;
>>
>> for( i = 0; i < N; i++ ){
>> float t = 0;
>> for( j = 0; j < Nf; j++ ){
>> Index k = i + j - Nf/2;
>> if( k >= N ) continue;
>> t += in[k] * filter[j];
>> }
>> out[i] = t;
>> }
>> }
>
> This looks like a (cross-)correlation, [...]

The key property is that it performs the same computation
as what seemed to be the intent of the original code.

On 05/08/2023 03:50, Tim Rentsch wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 8/4/23 10:25 AM, Bart wrote:
>>
>>> [...]
>>
>> Maybe your problem is you dont understand [...]
>
> Bart's problem isn't that he doesn't understand. Bart's
> problem is that he doesn't _want_ to understand.

Bart is the kid who questions the Emperor's new clothes.

You have a software system that has accumulated a mountain of now
unnecessary cruft. It's fair to ask why that mountain still exists.

All I'm hearing is excuses.

And after all this discussion about how great 'int32_t' is that we
shouldn't need to create aliases, now apparently we're not allowed to
use it unless we're an end-user?

Because the use of 'int32_t' in my library will expose it to a user who
has not sanctioned the use of stdint.h.

So much for C now having 'built-in' fixed-width types!

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2023-07-24, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> Bart <bc@freeuk.com> writes:
>>
>>> On 24/07/2023 08:50, David Brown wrote:
>>>
>>>> Integer constants (since that is the correct term - "literal"
>>>> is only used for "string literal" in C)
>>>
>>> You're right, the C standard only uses that for string literals
>>> and compound literals. But in the wider world, 'integer
>>> literal' is commonly used to mean 'integer constant', including
>>> in this C++ reference:
>>>
>>> https://en.cppreference.com/w/cpp/language/integer_literal
>>
>> Yes, C++ calls them literals. But that site does use the same
>> terminology as the C standard when talking about C:
>>
>> https://en.cppreference.com/w/c/language/integer_constant
>>
>> I prefer C++'s usage, since "integer constant" can be so easily
>> confused for "integer constant expression".
>
> The term "literal constant" has a well-entrenched meaning in computer
> science.
>
> "literal" is a contraction of this, just like "deliverable" is short for
> "deliverable goods" and what not.
>
> "constant" is another contraction of "literal constant".
>
> [...]

I see Kaz has been taking lessons from Kellyanne Conway, offering
up "alternative facts".

No doubt the phrase "literal constant" is used in many places
that discuss programming, but it is not a term with any special
meaning, simply an ordinary phrase put together under the usual
rules of normal English usage, with "literal" being an adjective
modifying "constant". The point of the phrase is to distinguish
it from "symbolic constant", which many programming languages
have going back at least as far as the early 1970s. Furthermore
none of that has any bearing on the use of "literal" as a noun
by itself, which is a distinct and unrelated construction.

On 2023-08-05, Bart <bc@freeuk.com> wrote:
> On 05/08/2023 03:50, Tim Rentsch wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 8/4/23 10:25 AM, Bart wrote:
>>>
>>>> [...]
>>>
>>> Maybe your problem is you dont understand [...]
>>
>> Bart's problem isn't that he doesn't understand. Bart's
>> problem is that he doesn't _want_ to understand.
>
> Bart is the kid who questions the Emperor's new clothes.
>
> You have a software system that has accumulated a mountain of now
> unnecessary cruft. It's fair to ask why that mountain still exists.

Without the maintainers of Newlib being in the loop, the debate
isn't well informed.

> All I'm hearing is excuses.
>
> And after all this discussion about how great 'int32_t' is that we
> shouldn't need to create aliases, now apparently we're not allowed to
> use it unless we're an end-user?

The main takeway message is that standard headers cannot introduce
identifiers willy-nilly. For instance if we include <stdlib.h>
we don't expect int32_t to be defined.

Standard headers introduce nonstandard identifiers as extensions; e.g.
<stdio.h> on POSIX declares fileno, and <string.h> declares strdup.
That sort of thing is done with care; there is way to hide those
declarations.

You wanted to know why newlib's _default_types.h cannot just include
<stdint.h>. The reason was that that header is the basis for
Newlib's definition of <stdint.h>.

In the open source C compiler and library landscapes, C implementations
are formed by combining separate compilers and libraries. GNU C
comes with a few headers, the others are supplied by a choice of
library, which is up to the system integrator to choose.

The <stdint.h> header didn't always exist. I'm guessing that at
some point, libraries started introducing it in parallel with
compilers.

E.g. on an Ubuntu system here, there is a GCC version of stdint.h
which has this:

#fndef _GCC_WRAP_STDINT_H
#if __STDC_HOSTED__
# if defined __cplusplus && __cplusplus >= 201103L
# undef __STDC_LIMIT_MACROS
# define __STDC_LIMIT_MACROS
# undef __STDC_CONSTANT_MACROS
# define __STDC_CONSTANT_MACROS
# endif
# include_next <stdint.h>
#else
# include "stdint-gcc.h"
#endif
#define _GCC_WRAP_STDINT_H
#endif

You see what it's doing? If __SDCT_HOSTED__ is enabled, which
looks like it means "we are a hosted C implementation (i.e. with a
library)".

If the implementation is hosted, then use the library's <stdint.h>.

Otherwise, fall back on "stdint-gcc.h".

Yes, yes, in your solo, greefield project, this doesn't make sense.

You can provide the compiler and library all from a single vendor;
none of this nonsense of different pieces coming from different
sources. And you're the only customer too, so any time you make a
breaking change, you just fix all your code and move on.

So anyway, the contract between GCC and a library is that if the
library chooses to provide <stdint.h>, that library is on its
own; it must calculate the contents by itself, without being
able to crib anything from GCC's "stdint-gcc.h".

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-08-05, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
>> On 2023-07-24, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 24/07/2023 08:50, David Brown wrote:
>>>>
>>>>> Integer constants (since that is the correct term - "literal"
>>>>> is only used for "string literal" in C)
>>>>
>>>> You're right, the C standard only uses that for string literals
>>>> and compound literals. But in the wider world, 'integer
>>>> literal' is commonly used to mean 'integer constant', including
>>>> in this C++ reference:
>>>>
>>>> https://en.cppreference.com/w/cpp/language/integer_literal
>>>
>>> Yes, C++ calls them literals. But that site does use the same
>>> terminology as the C standard when talking about C:
>>>
>>> https://en.cppreference.com/w/c/language/integer_constant
>>>
>>> I prefer C++'s usage, since "integer constant" can be so easily
>>> confused for "integer constant expression".
>>
>> The term "literal constant" has a well-entrenched meaning in computer
>> science.
>>
>> "literal" is a contraction of this, just like "deliverable" is short for
>> "deliverable goods" and what not.
>>
>> "constant" is another contraction of "literal constant".
>>
>> [...]
>
> I see Kaz has been taking lessons from Kellyanne Conway, offering
> up "alternative facts".

What?

> No doubt the phrase "literal constant" is used in many places
> that discuss programming, but it is not a term with any special
> meaning, simply an ordinary phrase put together under the usual
> rules of normal English usage, with "literal" being an adjective
> modifying "constant".

Indeed, the phrase isn't a noncompositional compound, like
"blackboard" or "blueberry".

So what? And, nobody claimed that it is.

> The point of the phrase is to distinguish
> it from "symbolic constant", which many programming languages
> have going back at least as far as the early 1970s.

I believe I said almost exactly the same thing in another article,
weeks ago.

No, wait! It's actually in the same article you're replying to!

KK> Another kinds [sic] of constant that is not a literal is a "symbolic
KK> constant" a.k.a. "manifest constant". This is a symbolic name
KK> arbitrarily given to a literal constant value.

> none of that has any bearing on the use of "literal" as a noun
> by itself, which is a distinct and unrelated construction.

Sayss you. I believe it's just derived from "literal constant"
or similar.

Adjectives used as nouns tend to be derived from a longer phrase
as a contraction, where it is obvious in the context.

E.g. "perishables" could mean "perishable food items" in the
right context; "submersible" to "submersible vessel" and so on.

Constant itself is an adjective. A "literal constant" is actually a
"literal constant term". Expressions have terms. A term can be a
constant term like "pi" and "3.14159", the former being a symbolic
constant term, and the latter a literal constant term. The latter
shortens to "literal constant" or just "literal".

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-08-05, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> On 2023-08-05, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>>> On 2023-07-24, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>
>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>> On 24/07/2023 08:50, David Brown wrote:
>>>>>
>>>>>> Integer constants (since that is the correct term - "literal"
>>>>>> is only used for "string literal" in C)
>>>>>
>>>>> You're right, the C standard only uses that for string literals
>>>>> and compound literals. But in the wider world, 'integer
>>>>> literal' is commonly used to mean 'integer constant', including
>>>>> in this C++ reference:
>>>>>
>>>>> https://en.cppreference.com/w/cpp/language/integer_literal
>>>>
>>>> Yes, C++ calls them literals. But that site does use the same
>>>> terminology as the C standard when talking about C:
>>>>
>>>> https://en.cppreference.com/w/c/language/integer_constant
>>>>
>>>> I prefer C++'s usage, since "integer constant" can be so easily
>>>> confused for "integer constant expression".
>>>
>>> The term "literal constant" has a well-entrenched meaning in computer
>>> science.
>>>
>>> "literal" is a contraction of this, just like "deliverable" is short for
>>> "deliverable goods" and what not.
>>>
>>> "constant" is another contraction of "literal constant".
>>>
>>> [...]
>>
>> I see Kaz has been taking lessons from Kellyanne Conway, offering
>> up "alternative facts".
>
> What?
>
>> No doubt the phrase "literal constant" is used in many places
>> that discuss programming, but it is not a term with any special
>> meaning, simply an ordinary phrase put together under the usual
>> rules of normal English usage, with "literal" being an adjective
>> modifying "constant".
>
> Indeed, the phrase isn't a noncompositional compound, like
> "blackboard" or "blueberry".
>
> So what? And, nobody claimed that it is.
>
>> The point of the phrase is to distinguish
>> it from "symbolic constant", which many programming languages
>> have going back at least as far as the early 1970s.
>
> I believe I said almost exactly the same thing in another article,
> weeks ago.
>
> No, wait! It's actually in the same article you're replying to!
>
> KK> Another kinds [sic] of constant that is not a literal is a "symbolic
> KK> constant" a.k.a. "manifest constant". This is a symbolic name
> KK> arbitrarily given to a literal constant value.
>
>> none of that has any bearing on the use of "literal" as a noun
>> by itself, which is a distinct and unrelated construction.
>
> Sayss you. I believe it's just derived from "literal constant"
> or similar.

Well, yes; I have to acknowledge misuses of "literal" here.

For instance, Python calls [1, 2, 3] a literal, even though each time
that is evaluated, it must construct a new object (or else countless
applications will break). That's just Python people being stupid. (I'm
taking the prescriptivist stance, which is fair game in the scope of a
technical field.)

There are also languages that give meaning to self-modifying programs.
It's posssible to have a dialect of C with writable string literals.
Writable literals aren't true constants, obviously. To ensure
predictable behavior, the dialect has to implement certain requirements,
like that identical strings cannot be merged.

So there are are certain examples in which we cannot say with a straight
face that what is being called a "literal" is a literal constant.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 05/08/2023 19:32, Kaz Kylheku wrote:
> On 2023-08-05, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>> On 2023-08-05, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>
>>>> On 2023-07-24, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>>
>>>>> Bart <bc@freeuk.com> writes:
>>>>>
>>>>>> On 24/07/2023 08:50, David Brown wrote:
>>>>>>
>>>>>>> Integer constants (since that is the correct term - "literal"
>>>>>>> is only used for "string literal" in C)
>>>>>>
>>>>>> You're right, the C standard only uses that for string literals
>>>>>> and compound literals. But in the wider world, 'integer
>>>>>> literal' is commonly used to mean 'integer constant', including
>>>>>> in this C++ reference:
>>>>>>
>>>>>> https://en.cppreference.com/w/cpp/language/integer_literal
>>>>>
>>>>> Yes, C++ calls them literals. But that site does use the same
>>>>> terminology as the C standard when talking about C:
>>>>>
>>>>> https://en.cppreference.com/w/c/language/integer_constant
>>>>>
>>>>> I prefer C++'s usage, since "integer constant" can be so easily
>>>>> confused for "integer constant expression".
>>>>
>>>> The term "literal constant" has a well-entrenched meaning in computer
>>>> science.
>>>>
>>>> "literal" is a contraction of this, just like "deliverable" is
short for
>>>> "deliverable goods" and what not.
>>>>
>>>> "constant" is another contraction of "literal constant".
>>>>
>>>> [...]
>>>
>>> I see Kaz has been taking lessons from Kellyanne Conway, offering
>>> up "alternative facts".
>>
>> What?
>>
>>> No doubt the phrase "literal constant" is used in many places
>>> that discuss programming, but it is not a term with any special
>>> meaning, simply an ordinary phrase put together under the usual
>>> rules of normal English usage, with "literal" being an adjective
>>> modifying "constant".
>>
>> Indeed, the phrase isn't a noncompositional compound, like
>> "blackboard" or "blueberry".
>>
>> So what? And, nobody claimed that it is.
>>
>>> The point of the phrase is to distinguish
>>> it from "symbolic constant", which many programming languages
>>> have going back at least as far as the early 1970s.
>>
>> I believe I said almost exactly the same thing in another article,
>> weeks ago.
>>
>> No, wait! It's actually in the same article you're replying to!
>>
>> KK> Another kinds [sic] of constant that is not a literal is a "symbolic
>> KK> constant" a.k.a. "manifest constant". This is a symbolic name
>> KK> arbitrarily given to a literal constant value.
>>
>>> none of that has any bearing on the use of "literal" as a noun
>>> by itself, which is a distinct and unrelated construction.
>>
>> Sayss you. I believe it's just derived from "literal constant"
>> or similar.
>
> Well, yes; I have to acknowledge misuses of "literal" here.
>
> For instance, Python calls [1, 2, 3] a literal, even though each time
> that is evaluated, it must construct a new object (or else countless
> applications will break). That's just Python people being stupid. (I'm
> taking the prescriptivist stance, which is fair game in the scope of a
> technical field.)

In my dynamic language, I also call (1, 2, 3), as I write it, a literal,
as I do several other like constructors. The reason in this case is so
the language can say that it is immutable, although lists in general are
mutable.

This is exactly for the purpose of being able to construct such an
object once during load-time, and not every time it is encountered in
source code.

To create a mutable version requires using copy() or a special
assignment operator.

(Previously, I used a form of 'copy-on-write', but that sometimes gave
unexpected behaviours.)

Actually, even (x, y, random()) is a literal, even though the values are
not compile-time constants. This is so the language can have a
consistent rule that says that:

(a, b, c)

is always immutable, without it depending on whether each of a, b, c was
a constant, named constant, an expression yielding a compile-time
constant, or runtime value.

> There are also languages that give meaning to self-modifying programs.
> It's posssible to have a dialect of C with writable string literals.

I think most Cs let you modify string literals. The only thing that
stops you doing so is the compiler storing the string data in read-only
memory. For example:

"ABC"[0] = 'Z';

gcc only warns about this, it does not stop you trying to do it. Clang
doesn't say anything.

> So there are are certain examples in which we cannot say with a straight
> face that what is being called a "literal" is a literal constant.
>

I use 'literal' to mean constucts where you enumerate the values of an
object.

Bart <bc@freeuk.com> writes:

> On 03/08/2023 17:37, Ben Bacarisse wrote:
....
>> That's an odd expectation, but then you do hope that C is as bad as you
>> can imagine!
>
> Unfortunately, it is.

I find I'd typed a reply to this and then not sent it. (I often delay
posting because I find that sometimes just writing a reply is enough and
I lose the urge to have anyone else see it.)

But this has not been addressed and I think it should be:

> Here's one other quirky thing:
>
> double x = 0x123p10;
> printf("x=%f\n",x);
>
> This a floating point constant using hexadecimal, supposedly.

As far as I can tell, the only quirk is that it does not mean what you
think (or supposed) it should. Floating-point constants mean what the
language definition says they mean:

"The significand part is interpreted as a (decimal or hexadecimal)
rational number; the digit sequence in the exponent part is
interpreted as a decimal integer."

I have used this format fair amount (though more often as seen in the
output generated by %a and %A) and found it very convenient.
Consistency should not trump usability.

--
Ben.

On 05/08/2023 23:11, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> But this has not been addressed and I think it should be:
>
>> Here's one other quirky thing:
>>
>> double x = 0x123p10;
>> printf("x=%f\n",x);
>>
>> This a floating point constant using hexadecimal, supposedly.
>
> As far as I can tell, the only quirk is that it does not mean what you
> think (or supposed) it should. Floating-point constants mean what the
> language definition says they mean:
>
> "The significand part is interpreted as a (decimal or hexadecimal)
> rational number; the digit sequence in the exponent part is
> interpreted as a decimal integer."
>
> I have used this format fair amount (though more often as seen in the
> output generated by %a and %A) and found it very convenient.
> Consistency should not trump usability.
>

Someone would reasonably expect that a hex floating point constant is
actually written exclusively in hex, not involving 3 different bases.
Your quote also doesn't mention that the exponent represents a power of
2, not a power of 16 nor a power of 10.

In a regular decimal constant, the exponent represents a power of 10.

(In my own stuff I've dropped support for hex float constants, after
previously dropping it for arbitrary bases. It was never used!

But when I did support it, then 0x123p10 meant 0x123 * 0x10**0x10, or
0x123 * 16**16; everything is base-16.)

Bart <bc@freeuk.com> writes:

> On 05/08/2023 23:11, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>> But this has not been addressed and I think it should be:
>>
>>> Here's one other quirky thing:
>>>
>>> double x = 0x123p10;
>>> printf("x=%f\n",x);
>>>
>>> This a floating point constant using hexadecimal, supposedly.
>>
>> As far as I can tell, the only quirk is that it does not mean what you
>> think (or supposed) it should. Floating-point constants mean what the
>> language definition says they mean:
>>
>> "The significand part is interpreted as a (decimal or hexadecimal)
>> rational number; the digit sequence in the exponent part is
>> interpreted as a decimal integer."
>>
>> I have used this format fair amount (though more often as seen in the
>> output generated by %a and %A) and found it very convenient.
>> Consistency should not trump usability.
>
> Someone would reasonably expect that a hex floating point constant is
> actually written exclusively in hex, not involving 3 different bases.

And any reasonable programmer would then check their expectations.
There may be (as there are in this case) good reasons to avoid
consistency just for the sake if it.

> Your quote also doesn't mention that the exponent represents a power
> of 2, not a power of 16 nor a power of 10.

The next two sentences cover it. Maybe I should have quoted the whole
paragraph but you had already given the key details in your complaint.

> In a regular decimal constant, the exponent represents a power of 10.
>
> (In my own stuff I've dropped support for hex float constants, after
> previously dropping it for arbitrary bases. It was never used!
>
> But when I did support it, then 0x123p10 meant 0x123 * 0x10**0x10, or 0x123
> * 16**16; everything is base-16.)

Your position is that a notation that has actually been found to be
useful should instead have been designed in a way that you found to have
no uses.

--
Ben.