On 2021-05-10, Bart <bc@freeuk.com> wrote:
> On 09/05/2021 23:00, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> By CPP I mean the C preprocessor. For example:
>>>
>>> #if 1000000000*1000000000==1000000000000000000
>>>
>>> Arithmetic done with the widest integer type, usually i64.
>>
>> And again, you use your own invented terminology when the existing
>> terms defined in the C standard are unambiguous.
>>
>
> You flatter me. The term came from the first reasonable-looking google
> hit, which was:
>
> https://gcc.gnu.org/onlinedocs/cpp/If.html#If
>
> and it says:
>
> "The preprocessor calculates the value of expression. It carries out all
> calculations in the widest integer type known to the compiler; on most
> machines supported by GCC this is 64 bits. This is not the same rule as
> the compiler uses to calculate the value of a constant expression, and
> may give different results in some cases."
>
> This also makes the same point as my post. (You might want to file a bug
> report as to why these gcc docs don't use 'intmax_t' and 'uintmax_t'.)

It could be that the author didn't want to involve typedef names in
documentation about the preprocessor, which doesn't work with typedef.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 10/05/2021 17:35, Malcolm McLean wrote:
> On Monday, 10 May 2021 at 14:44:55 UTC+1, David Brown wrote:
>> On 10/05/2021 15:20, Bart wrote:
>>> On 10/05/2021 13:54, David Brown wrote:
>>>> On 10/05/2021 14:12, Bart wrote:
>>>
>>>>> Practically every other C application or library also defines its own
>>>>> 'pointless' names for such fixed-width types. You'd have to ask their
>>>>> authors why they do that; it's not always because the program started
>>>>> life before stdint.h was common, or because they are keen to have their
>>>>> program work on C90.
>>>>
>>>> So because other people have done something counter-productive,
>>>
>>> I'm suggesting that if C had, perhaps from well before C99, short,
>>> succinct and well-defined fixed-width type names, then an awful lot of
>>> code would not have bothered to define their own variations, and it
>>> would have been smaller and tidier.
>> I like history - it's a hobby of mine. But I have never found such "how
>> would the world have been if /this/ had happened" speculations to be
>> particularly useful or enlightening. (Muta's desire to /change/
>> history, or re-live it in some weird way, is even stranger.)
>>
>> If C had had size-specific types from its earlier conception (perhaps
>> since it was standardised), I expect there would be far fewer home-made
>> size-specific types. I think it is almost entirely irrelevant whether
>> those were named "int32_t", "i32", "signed word", "quadbyte", or
>> anything else.
>>
> It's important that names are felicitous.
> "int32_t" isn't too bad, bit it's rather clumsy to pronounce, and it has an underscore,
> making it difficult to read and to type.
> The term for a 16 bit type is "plyte" and a 32 bit type a "dyner", but they have never
> really caught on. Technically a "byte" doesn't mean "8 bits" either, as we all know
> on comp.lang.c.
>

Do you have a reference for plyte and dyner? The only hit on Google was
someone called Malcolm McLean suggesting them a few years ago.

A byte is universally understood to be 8 bits, except in the world of C
(that close-to-the-metal-language provided you're careful never to pin
down exactly what the metal is).

I have used 'half' for a half-word, but now that words are 64 bits, you
need colloquial terms for both 16- and 32-bit types.

There are a few suggesions here:

https://en.wikipedia.org/wiki/Integer_(computer_science)

which interestingly, use names like i32 and u16 that I've mentioned
(which David Brown doesn't understand) but not int32_t or uint16_t.

I'm happy for now to just use i8 i16 i32 i64 (or the longer forms int8
int16 int32 int64) when I need a specific width.

In the past I have used (not in C obviously) int:32 and int*4 (or byte*4
for unsigned), the *N was from Fortran.

Colloquial forms I currently use are:

bit u1
byte u8
int i64
word u64
char c8 (a form of u8 used in strings)
real r64 or f64

On Monday, 10 May 2021 at 18:26:56 UTC+1, Bart wrote:
> On 10/05/2021 17:35, Malcolm McLean wrote:
>
> > The term for a 16 bit type is "plyte" and a 32 bit type a "dyner", but they have never
> > really caught on. Technically a "byte" doesn't mean "8 bits" either, as we all know
> > on comp.lang.c.
> >
>
> Do you have a reference for plyte and dyner? The only hit on Google was
> someone called Malcolm McLean suggesting them a few years ago.
>
https://en.wikipedia.org/wiki/Units_of_information

(I didn't invent the terms, and haven't edited this page).

On 10/05/2021 17:18, Bart wrote:
> On 10/05/2021 14:44, David Brown wrote:
>> On 10/05/2021 15:20, Bart wrote:
>
>>> The reason was to reduce the already bloated size of the generated code
>>> (that had extra parentheses, casts etc), and make it somewhat more
>>> readable if I had to ever look at it.
>>
>> You sometimes make relevant points about the weaknesses in C.  Harping
>> on about such ridiculously small quibbles like this makes a mockery of
>> that.
>
> How complicated does a /basic/ type have to be before even you start
> complaining?

"int32_t" says exactly what it means. It says "integer 32-bit type". I
can't comprehend why this is such a problem for you.

(There are plenty of things that one /can/ reasonably complain about
with C's types - the implementation-dependency of the fundamental types,
types like "unsigned long long int", or the slightly odd rules for types
of constants, for instance. Getting your knickers in a twist about the
spelling of int32_t seems way out of proportion to me.)

>
> For this purpose, using stdint types exclusively pointlessly adds about
> 7.5% to the size of the generated code, but more importantly, makes it
> even more cluttered than it already if you need to debug it.

It will take me about a gazilion years before this extra size fills up
my hard disk, so I am not worried about it. My code is already
significantly more than 7.5% bigger than yours, because I know how to
use the space character to make code more readable.

>
>>> They also matched more directly the types in the original source which
>>> could simply be generated verbatim instead of having to convert to
>>> int64_t etc.
>>>
>>
>> Now, finally, you have a point that is meaningful.  If you are
>> transcompiling from another language to C, then it might make sense to
>> use typenames in C that match those of the original language - /if/ the
>> types convey the same meaning.
>
> Actually, this isn't so importent, just more convenient; the same
> function that generates a basic type name would work for both languages.
>
>>>
>>>> How about trying to be
>>>> /better/ than those you deride?
>>>
>>> You mean, like creating a whole, better language? That's an idea...
>>
>> No - I mean like writing standard C when you are writing C, and using C
>> terms when you are discussing C.
>
> When discussing C then it is pointlessly pedantic to write out
> "uint64_t" in full; neither of us are C compilers, and we're writing in
> English not code. "u64" or "uint64" (or "unsigned 64 bits") are all
> well-understood descriptions of that type.
>

In C, the type is "uint64_t". Use it when talking about C. It's that
simple. Give other C programmers that level of respect, and you'll save
plenty of keystrokes because you won't have to waste so many of them
trying to justify saving two or three characters.

>
> (What did the forum look like before 1999, were people actually writing
> out "unsigned long long int" in full to describe a 64-bit value?)
>

The "long long" types didn't exist before C99 - with C90, there was no
standard way to get a type that was at least 64-bit. (If you had been
whining about the verbosity of "unsigned long long int", you'd have got
a lot more sympathy.)

>
>>> Compare with the original; which one looks cleaner and clearer?
>>
>> The version with int32_t, uint32_t, etc., looks clearer - it's written
>> in C, not in some home-made mongrel language.
>
> So you kind of home-made mongrel language is this fragment of code
> written in:
>
>
> struct stat {
>     dev_t     st_dev;     /* ID of device containing file */
>     ino_t     st_ino;     /* inode number */
>     mode_t    st_mode;    /* protection */
>     nlink_t   st_nlink;   /* number of hard links */
>     uid_t     st_uid;     /* user ID of owner */
>     gid_t     st_gid;     /* group ID of owner */
>     dev_t     st_rdev;    /* device ID (if special file) */
>     off_t     st_size;    /* total size, in bytes */
>     blksize_t st_blksize; /* blocksize for file system I/O */
>     blkcnt_t  st_blocks;  /* number of 512B blocks allocated */
>     time_t    st_atime;   /* time of last access */
>     time_t    st_mtime;   /* time of last modification */
>     time_t    st_ctime;   /* time of last status change */
> };

(Note that the field names here are a hangover from pre-standard C,
where struct field names all shared a single space.)

>
> You know, I can't see a single standard integer type in there.

Of course not. And that's a great thing, too. A lot of programmers
don't do a good job about making and naming types or typedefs, but they
make it vastly easier to change things later (such as changing 16-bit
types to 32-bit, or 32-bit to 64-bit).

> And I
> can't guess those typedefs are.

For the great majority of users, they don't matter - you write your code
using these named types, not their sizes.

> If I wanted to duplicated this struct to
> use in an FFI, I would have my work cut out.

Definitions of types and functions in C are primarily for use in C. But
other people seem to manage to make interfaces to other languages when
they need to.

>
> Here's what it could look like using not allowing plain types, but the
> compact ones (version for Win64):
>
>  struct _stat {
>     u32 st_dev;
>     u16 st_ino;
>     u16 st_mode;
>     i16 st_nlink;
>     i16 st_uid;
>     i16 st_gid;
>     u32 st_rdev;
>     u32 st_size;
>     u64 st_atime;
>     u64 st_mtime;
>     u64 st_ctime;
>  };
>
> Take a wild guess at what those types might mean.

They would mean the person making that type doesn't understand how to
make future-proof structures, and doesn't care about how much trouble
that will cause in the future. So yes, it looks quite appropriate for a
Windows structure - but not for a *nix structure.

Bart <bc@freeuk.com> writes:
> On 09/05/2021 23:00, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> By CPP I mean the C preprocessor. For example:
>>>
>>> #if 1000000000*1000000000==1000000000000000000
>>>
>>> Arithmetic done with the widest integer type, usually i64.
>>
>> And again, you use your own invented terminology when the existing
>> terms defined in the C standard are unambiguous.
>>
>
> You flatter me. The term came from the first reasonable-looking google
> hit, which was:
>
> https://gcc.gnu.org/onlinedocs/cpp/If.html#If
>
> and it says:
>
> "The preprocessor calculates the value of expression. It carries out
> all calculations in the widest integer type known to the compiler; on
> most machines supported by GCC this is 64 bits. This is not the same
> rule as the compiler uses to calculate the value of a constant
> expression, and may give different results in some cases."
>
> This also makes the same point as my post. (You might want to file a
> bug report as to why these gcc docs don't use 'intmax_t' and
> 'uintmax_t'.)

Why would I want to do that? It's a document accurately describing a
specific implementation. When you wrote "By CPP I mean the C
preprocessor", were you referring to a specific implementation?

>> There's nothing in C called "i64" unless you define it yourself.
>> The standard says that preprocessor arithmetic is done using intmax_t
>> or uintmax_t, which are typically 64 bits. Why not just say that?
>
> Because i64 and u64 are universally understood, and exactly match my
> example. intmax_t and uintmax_t are not; they could be anything, and
> might not have matched the point I was making in my example.

No, intmax_t and uintmax_t are ...

Oh, never mind, you know what they are, you're just pretending not to
understand.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> The term for a 16 bit type is "plyte" and a 32 bit type a "dyner", but they have never
> really caught on.

No, it isn't. Is that supposed to be a joke?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

On Monday, 10 May 2021 at 19:33:55 UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> [...]
> > The term for a 16 bit type is "plyte" and a 32 bit type a "dyner", but they have never
> > really caught on.
> No, it isn't. Is that supposed to be a joke?
>
Yes, the terms are largely jocular, and they wouldn't be chosen as typenames in
a serious language.
However they do have advantages over "uint32_t" and the like.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Monday, 10 May 2021 at 18:26:56 UTC+1, Bart wrote:
>> On 10/05/2021 17:35, Malcolm McLean wrote:
>>
>> > The term for a 16 bit type is "plyte" and a 32 bit type a "dyner", but they have never
>> > really caught on. Technically a "byte" doesn't mean "8 bits" either, as we all know
>> > on comp.lang.c.
>> >
>>
>> Do you have a reference for plyte and dyner? The only hit on Google was
>> someone called Malcolm McLean suggesting them a few years ago.
>>
> https://en.wikipedia.org/wiki/Units_of_information
>
> (I didn't invent the terms, and haven't edited this page).

That page mentions neither "plyte" nor "dyner".

The Jargon File has entries for "playte" and "dynner":

playte:
16 bits, by analogy with nybble and byte. Usage: rare and extremely
silly. See also dynner and crumb. General discussion of such terms
is under nybble.

dynner:
32 bits, by analogy with nybble and byte. Usage: rare and extremely
silly. See also playte, tayste, crumb. General discussion of such terms
is under nybble.

The joke is that "byte", by analogy with "bite", denotes a quantity of
food, so other quantities of food with a vowel replaced by "y" could
denote other numbers of bits.

Note carefully the phrase "Usage: rare and extremely silly" in both
definitions.

They are not terms that "never really caught on", they're just jokes.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

On 2021-05-10, Bart <bc@freeuk.com> wrote:
> On 10/05/2021 14:44, David Brown wrote:
>> On 10/05/2021 15:20, Bart wrote:
>
>>> The reason was to reduce the already bloated size of the generated code
>>> (that had extra parentheses, casts etc), and make it somewhat more
>>> readable if I had to ever look at it.
>>
>> You sometimes make relevant points about the weaknesses in C. Harping
>> on about such ridiculously small quibbles like this makes a mockery of that.
>
> How complicated does a /basic/ type have to be before even you start
> complaining?
>
> For this purpose, using stdint types exclusively pointlessly adds about
> 7.5% to the size of the generated code, but more importantly, makes it
> even more cluttered than it already if you need to debug it.
>
>>> They also matched more directly the types in the original source which
>>> could simply be generated verbatim instead of having to convert to
>>> int64_t etc.
>>>
>>
>> Now, finally, you have a point that is meaningful. If you are
>> transcompiling from another language to C, then it might make sense to
>> use typenames in C that match those of the original language - /if/ the
>> types convey the same meaning.
>
> Actually, this isn't so importent, just more convenient; the same
> function that generates a basic type name would work for both languages.
>
>>>
>>>> How about trying to be
>>>> /better/ than those you deride?
>>>
>>> You mean, like creating a whole, better language? That's an idea...
>>
>> No - I mean like writing standard C when you are writing C, and using C
>> terms when you are discussing C.
>
> When discussing C then it is pointlessly pedantic to write out
> "uint64_t" in full; neither of us are C compilers, and we're writing in
> English not code. "u64" or "uint64" (or "unsigned 64 bits") are all
> well-understood descriptions of that type.
>
>
> (What did the forum look like before 1999, were people actually writing
> out "unsigned long long int" in full to describe a 64-bit value?)
>
>
>>> Compare with the original; which one looks cleaner and clearer?
>>
>> The version with int32_t, uint32_t, etc., looks clearer - it's written
>> in C, not in some home-made mongrel language.
>
> So you kind of home-made mongrel language is this fragment of code
> written in:
>
>
> struct stat {
> dev_t st_dev; /* ID of device containing file */
> ino_t st_ino; /* inode number */
> mode_t st_mode; /* protection */
> nlink_t st_nlink; /* number of hard links */
> uid_t st_uid; /* user ID of owner */
> gid_t st_gid; /* group ID of owner */
> dev_t st_rdev; /* device ID (if special file) */
> off_t st_size; /* total size, in bytes */
> blksize_t st_blksize; /* blocksize for file system I/O */
> blkcnt_t st_blocks; /* number of 512B blocks allocated */
> time_t st_atime; /* time of last access */
> time_t st_mtime; /* time of last modification */
> time_t st_ctime; /* time of last status change */
> };
>
> You know, I can't see a single standard integer type in there. And I
> can't guess those typedefs are. If I wanted to duplicated this struct to
> use in an FFI, I would have my work cut out.

Get better FFI?

On a POSIX system, your FFI should come loaded with all the baby _t's,
so as not to foist this problem onto the application developer.

his is the TXR Lisp interactive listener of TXR 257.
Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
Warning: may explode if heated, cooled or maintained at room temperature.
1> (typedef stat (struct stat
(dev dev-t)
(ino ino-t)
(mode mode-t)
(nlink nlink-t)
(git gid-t)
(uid uid-t)
(rdev dev-t)
(size off-t)
(blksize blksize-t)
(blocks blkcnt-t)
(atime time-t)
(mtime time-t)
(ctime time-t)))
#<ffi-type (struct stat (dev dev-t) (ino ino-t) (mode mode-t) (nlink nlink-t)
(git gid-t) (uid uid-t) (rdev dev-t) (size off-t) (blksize blksize-t)
(blocks blkcnt-t) (atime time-t) (mtime time-t) (ctime time-t))>
2> (sizeof stat)
60
3> (alignof stat)
4

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On Monday, 10 May 2021 at 19:44:37 UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> > On Monday, 10 May 2021 at 18:26:56 UTC+1, Bart wrote:
> >> On 10/05/2021 17:35, Malcolm McLean wrote:
> >>
> >> > The term for a 16 bit type is "plyte" and a 32 bit type a "dyner", but they have never
> >> > really caught on. Technically a "byte" doesn't mean "8 bits" either, as we all know
> >> > on comp.lang.c.
> >> >
> >>
> >> Do you have a reference for plyte and dyner? The only hit on Google was
> >> someone called Malcolm McLean suggesting them a few years ago.
> >>
> > https://en.wikipedia.org/wiki/Units_of_information
> >
> > (I didn't invent the terms, and haven't edited this page).
> That page mentions neither "plyte" nor "dyner".
>
So this conforms to the general pattern. Someone on Usenet demands "sources,
references". References are duly provided. Then inevitable some reason is
trotted out for claiming that the challenge has not been met.

On 10/05/2021 19:29, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 09/05/2021 23:00, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> By CPP I mean the C preprocessor. For example:
>>>>
>>>> #if 1000000000*1000000000==1000000000000000000
>>>>
>>>> Arithmetic done with the widest integer type, usually i64.
>>>
>>> And again, you use your own invented terminology when the existing
>>> terms defined in the C standard are unambiguous.
>>>
>>
>> You flatter me. The term came from the first reasonable-looking google
>> hit, which was:
>>
>> https://gcc.gnu.org/onlinedocs/cpp/If.html#If
>>
>> and it says:
>>
>> "The preprocessor calculates the value of expression. It carries out
>> all calculations in the widest integer type known to the compiler; on
>> most machines supported by GCC this is 64 bits. This is not the same
>> rule as the compiler uses to calculate the value of a constant
>> expression, and may give different results in some cases."
>>
>> This also makes the same point as my post. (You might want to file a
>> bug report as to why these gcc docs don't use 'intmax_t' and
>> 'uintmax_t'.)
>
> Why would I want to do that? It's a document accurately describing a
> specific implementation. When you wrote "By CPP I mean the C
> preprocessor", were you referring to a specific implementation?

Yes, I'm mainly talking about C implementations for current desktop
machines.

But I don't get why you think it's OK for this document to avoid using
intmax, and vaguely suggest the size is 64 bits, but I'm not allowed to
do that.

Well, I will give a suggestion why they do it that way: the C
preprocessor knows nothing about C types, so talking about intmax_t
would be meaningless in that context.

> Oh, never mind, you know what they are, you're just pretending not to
> understand.

You've got that back to front. People here (you and David Brown) are
pretending to have no idea what type "i64" might be.

And in doing so, avoiding acknowledging my point, which was that the C
preprocessor (of the targets above) defaults to 64-bit arithmetic (that
is, intmax_t, uintmax_t, int64_t, uint64_t, signed long int (Linux64),
signed long long int (everything else), unsigned....), while the C
compiler proper is still stuck at 32 bits (that is, int32_t,......).

See how it can get out of hand when you try to be overly pedantic.

In my dealings with C via a FFI, integer types are one of these eight
universally known types: i8 i16 i32 i64 u8 u16 u32 u64. Those myriad
types of C don't exist outside the language.

On 10/05/2021 19:46, Kaz Kylheku wrote:
> On 2021-05-10, Bart <bc@freeuk.com> wrote:
>> On 10/05/2021 14:44, David Brown wrote:
>>> On 10/05/2021 15:20, Bart wrote:
>>
>>>> The reason was to reduce the already bloated size of the generated code
>>>> (that had extra parentheses, casts etc), and make it somewhat more
>>>> readable if I had to ever look at it.
>>>
>>> You sometimes make relevant points about the weaknesses in C. Harping
>>> on about such ridiculously small quibbles like this makes a mockery of that.
>>
>> How complicated does a /basic/ type have to be before even you start
>> complaining?
>>
>> For this purpose, using stdint types exclusively pointlessly adds about
>> 7.5% to the size of the generated code, but more importantly, makes it
>> even more cluttered than it already if you need to debug it.
>>
>>>> They also matched more directly the types in the original source which
>>>> could simply be generated verbatim instead of having to convert to
>>>> int64_t etc.
>>>>
>>>
>>> Now, finally, you have a point that is meaningful. If you are
>>> transcompiling from another language to C, then it might make sense to
>>> use typenames in C that match those of the original language - /if/ the
>>> types convey the same meaning.
>>
>> Actually, this isn't so importent, just more convenient; the same
>> function that generates a basic type name would work for both languages.
>>
>>>>
>>>>> How about trying to be
>>>>> /better/ than those you deride?
>>>>
>>>> You mean, like creating a whole, better language? That's an idea...
>>>
>>> No - I mean like writing standard C when you are writing C, and using C
>>> terms when you are discussing C.
>>
>> When discussing C then it is pointlessly pedantic to write out
>> "uint64_t" in full; neither of us are C compilers, and we're writing in
>> English not code. "u64" or "uint64" (or "unsigned 64 bits") are all
>> well-understood descriptions of that type.
>>
>>
>> (What did the forum look like before 1999, were people actually writing
>> out "unsigned long long int" in full to describe a 64-bit value?)
>>
>>
>>>> Compare with the original; which one looks cleaner and clearer?
>>>
>>> The version with int32_t, uint32_t, etc., looks clearer - it's written
>>> in C, not in some home-made mongrel language.
>>
>> So you kind of home-made mongrel language is this fragment of code
>> written in:
>>
>>
>> struct stat {
>> dev_t st_dev; /* ID of device containing file */
>> ino_t st_ino; /* inode number */
>> mode_t st_mode; /* protection */
>> nlink_t st_nlink; /* number of hard links */
>> uid_t st_uid; /* user ID of owner */
>> gid_t st_gid; /* group ID of owner */
>> dev_t st_rdev; /* device ID (if special file) */
>> off_t st_size; /* total size, in bytes */
>> blksize_t st_blksize; /* blocksize for file system I/O */
>> blkcnt_t st_blocks; /* number of 512B blocks allocated */
>> time_t st_atime; /* time of last access */
>> time_t st_mtime; /* time of last modification */
>> time_t st_ctime; /* time of last status change */
>> };
>>
>> You know, I can't see a single standard integer type in there. And I
>> can't guess those typedefs are. If I wanted to duplicated this struct to
>> use in an FFI, I would have my work cut out.
>
> Get better FFI?

The only way to get a better FFI to make sense of badly written code
like this is to incorporate a C compiler. That is not trivial.

I believe that Zig can directly make sense of C headers, but it does so
by the simple expedient of packaging the Clang compiler, which itself
includes LLVM.

> On a POSIX system, your FFI should come loaded with all the baby _t's,
> so as not to foist this problem onto the application developer.

So POSIX makes available all the relevant C header information in a
universal format that doesn't need mucking about with C typedefs, C
#includes, C #defines, C's multitudinous standard types, C's algorithms
for padding struct members, conditional C #ifs and #ifdefs, and
expanding C macros?

I didn't know that. But how about all the 1000s of third party libraries?

> his is the TXR Lisp interactive listener of TXR 257.
> Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
> Warning: may explode if heated, cooled or maintained at room temperature.
> 1> (typedef stat (struct stat
> (dev dev-t)
> (ino ino-t)
> (mode mode-t)
> (nlink nlink-t)
> (git gid-t)
> (uid uid-t)
> (rdev dev-t)
> (size off-t)
> (blksize blksize-t)
> (blocks blkcnt-t)
> (atime time-t)
> (mtime time-t)
> (ctime time-t)))
> #<ffi-type (struct stat (dev dev-t) (ino ino-t) (mode mode-t) (nlink nlink-t)
> (git gid-t) (uid uid-t) (rdev dev-t) (size off-t) (blksize blksize-t)
> (blocks blkcnt-t) (atime time-t) (mtime time-t) (ctime time-t))>
> 2> (sizeof stat)
> 60
> 3> (alignof stat)
> 4

If I wanted to use this from my script language, say, this wouldn't be
much help. I need concrete types. For example:

type ws_msg64 = struct $caligned
ref void hwnd
int32 message
int64 wparam
int64 lparam
int32 time
int32 ptx
int32 pty
end

On Monday, May 10, 2021 at 2:50:46 PM UTC-4, Malcolm McLean wrote:
> On Monday, 10 May 2021 at 19:44:37 UTC+1, Keith Thompson wrote:
> > Malcolm McLean <malcolm.ar...@gmail.com> writes:
> > > On Monday, 10 May 2021 at 18:26:56 UTC+1, Bart wrote:
> > >> On 10/05/2021 17:35, Malcolm McLean wrote:
> > >>
> > >> > The term for a 16 bit type is "plyte" and a 32 bit type a "dyner", but they have never
> > >> > really caught on. Technically a "byte" doesn't mean "8 bits" either, as we all know
> > >> > on comp.lang.c.
> > >> >
> > >>
> > >> Do you have a reference for plyte and dyner? The only hit on Google was
> > >> someone called Malcolm McLean suggesting them a few years ago.
> > >>
> > > https://en.wikipedia.org/wiki/Units_of_information
> > >
> > > (I didn't invent the terms, and haven't edited this page).
> > That page mentions neither "plyte" nor "dyner".
> >
> So this conforms to the general pattern. Someone on Usenet demands "sources,
> references". References are duly provided. Then inevitable some reason is
> trotted out for claiming that the challenge has not been met.

Yes, that is a pattern, and a rather annoying one. However, you've left out some important details.
1. *Someone on usenet makes a claim for which they have no support.*
2. Someone on usenet demands "sources, references".
3. References are duly provided *which fail to support the claim*.
4. Some *valid* reason is trotted out for claiming that the challenge has not been met.

It's steps 1 and 3 that are the problematic ones, not step 2 or step 4.

Bart <bc@freeuk.com> writes:
>On 10/05/2021 19:29, Keith Thompson wrote:

>But I don't get why you think it's OK for this document to avoid using
>intmax, and vaguely suggest the size is 64 bits, but I'm not allowed to
>do that.
>
>Well, I will give a suggestion why they do it that way: the C
>preprocessor knows nothing about C types, so talking about intmax_t
>would be meaningless in that context.

Unless the C pre-processor _pass_ of the compiler is written
in fortran, it will likely be written in C, and will use standard
C types, such as intmax_t when processing constants in pre-processor
constructs such as #if.

>You've got that back to front. People here (you and David Brown) are
>pretending to have no idea what type "i64" might be.

Give you made it up, it can mean anything you want it to. That doesn't
imply that the meaning is in any way universal or conventional.

On 10/05/2021 19:29, David Brown wrote:
> On 10/05/2021 17:18, Bart wrote:
>> On 10/05/2021 14:44, David Brown wrote:
>>> On 10/05/2021 15:20, Bart wrote:
>>
>>>> The reason was to reduce the already bloated size of the generated code
>>>> (that had extra parentheses, casts etc), and make it somewhat more
>>>> readable if I had to ever look at it.
>>>
>>> You sometimes make relevant points about the weaknesses in C.  Harping
>>> on about such ridiculously small quibbles like this makes a mockery of
>>> that.
>>
>> How complicated does a /basic/ type have to be before even you start
>> complaining?
>
> "int32_t" says exactly what it means. It says "integer 32-bit type". I
> can't comprehend why this is such a problem for you.
>
> (There are plenty of things that one /can/ reasonably complain about
> with C's types - the implementation-dependency of the fundamental types,
> types like "unsigned long long int", or the slightly odd rules for types
> of constants, for instance. Getting your knickers in a twist about the
> spelling of int32_t seems way out of proportion to me.)
>
>>
>> For this purpose, using stdint types exclusively pointlessly adds about
>> 7.5% to the size of the generated code, but more importantly, makes it
>> even more cluttered than it already if you need to debug it.
>
> It will take me about a gazilion years before this extra size fills up
> my hard disk, so I am not worried about it. My code is already
> significantly more than 7.5% bigger than yours, because I know how to
> use the space character to make code more readable.

I like your attitude! People go to extraordinary lengths to make things
smaller or faster.

Some considerable effort might be needed to squeeze another 7.5% of
performance out of an optimiser, but then David Brown comes along with
an input file that is 7.5% bigger than needed, and all that effort now
only serves to maintain the status quo!

The 7.5% might be one out of many factors that apply.

> In C, the type is "uint64_t". Use it when talking about C. It's that
> simple.

No it isn't. As I said in the post to Keith, I was talking about the C
preprocessor that knows nothing about uint64_t.

(For that matter, C itself don't know it either until it sees its
definition in the user-code of stdint.h).

>> You know, I can't see a single standard integer type in there.
>
> Of course not. And that's a great thing, too.

Obviously! Creating myriad gratuitous types, practically a dedicated
type for each struct member, is a really good way to write code!

>> Take a wild guess at what those types might mean.
>
> They would mean the person making that type doesn't understand how to
> make future-proof structures, and doesn't care about how much trouble
> that will cause in the future.

Or maybe that person knows how to properly deal with platform-specific
configuration differences at the correct level.

You don't do it at the granularity of individual member definitions, you
do at the level of a whole struct at least.

(I would do at the header level or, in my language, at the module level.)

This makes for considerably better readability, than having, as I've
seen, a struct definition bristling with conditional members using #ifs
and #ifdefs. It ruins the structure of the code.

Have header A for one platform, and header B for another. NOW who's
trying to save bytes by trying to squeeze multiple configurations into
one unreadable, heavily patched Frankensteinian header?

Bart <bc@freeuk.com> writes:
>On 10/05/2021 19:46, Kaz Kylheku wrote:

>>>> The version with int32_t, uint32_t, etc., looks clearer - it's written
>>>> in C, not in some home-made mongrel language.
>>>
>>> So you kind of home-made mongrel language is this fragment of code
>>> written in:
>>>
>>>
>>> struct stat {
>>> dev_t st_dev; /* ID of device containing file */
>>> ino_t st_ino; /* inode number */
>>> mode_t st_mode; /* protection */
>>> nlink_t st_nlink; /* number of hard links */
>>> uid_t st_uid; /* user ID of owner */
>>> gid_t st_gid; /* group ID of owner */
>>> dev_t st_rdev; /* device ID (if special file) */
>>> off_t st_size; /* total size, in bytes */
>>> blksize_t st_blksize; /* blocksize for file system I/O */
>>> blkcnt_t st_blocks; /* number of 512B blocks allocated */
>>> time_t st_atime; /* time of last access */
>>> time_t st_mtime; /* time of last modification */
>>> time_t st_ctime; /* time of last status change */
>>> };
>>>
>>> You know, I can't see a single standard integer type in there. And I
>>> can't guess those typedefs are. If I wanted to duplicated this struct to
>>> use in an FFI, I would have my work cut out.
>>
>> Get better FFI?

Bart should learn the art of abstraction first. There are very good
reasons that the members of struct stat are abstract - noting particularly
the idea of portable software that doesn't run on Bart's 8086 machines and
where the size of an hardware integral typeBart <bc@freeuk.com> writes:
>On 10/05/2021 19:46, Kaz Kylheku wrote:
>> On 2021-05-10, Bart <bc@freeuk.com> wrote:
>>> On 10/05/2021 14:44, David Brown wrote:
>>>> On 10/05/2021 15:20, Bart wrote:
>>>
>>>>> The reason was to reduce the already bloated size of the generated code
>>>>> (that had extra parentheses, casts etc), and make it somewhat more
>>>>> readable if I had to ever look at it.
>>>>
>>>> You sometimes make relevant points about the weaknesses in C. Harping
>>>> on about such ridiculously small quibbles like this makes a mockery of that.
>>>
>>> How complicated does a /basic/ type have to be before even you start
>>> complaining?
>>>
>>> For this purpose, using stdint types exclusively pointlessly adds about
>>> 7.5% to the size of the generated code, but more importantly, makes it
>>> even more cluttered than it already if you need to debug it.
>>>
>>>>> They also matched more directly the types in the original source which
>>>>> could simply be generated verbatim instead of having to convert to
>>>>> int64_t etc.
>>>>>
>>>>
>>>> Now, finally, you have a point that is meaningful. If you are
>>>> transcompiling from another language to C, then it might make sense to
>>>> use typenames in C that match those of the original language - /if/ the
>>>> types convey the same meaning.
>>>
>>> Actually, this isn't so importent, just more convenient; the same
>>> function that generates a basic type name would work for both languages.
>>>
>>>>>
>>>>>> How about trying to be
>>>>>> /better/ than those you deride?
>>>>>
>>>>> You mean, like creating a whole, better language? That's an idea...
>>>>
>>>> No - I mean like writing standard C when you are writing C, and using C
>>>> terms when you are discussing C.
>>>
>>> When discussing C then it is pointlessly pedantic to write out
>>> "uint64_t" in full; neither of us are C compilers, and we're writing in
>>> English not code. "u64" or "uint64" (or "unsigned 64 bits") are all
>>> well-understood descriptions of that type.
>>>
>>>
>>> (What did the forum look like before 1999, were people actually writing
>>> out "unsigned long long int" in full to describe a 64-bit value?)
>>>
>>>
>>>>> Compare with the original; which one looks cleaner and clearer?
>>>>
>>>> The version with int32_t, uint32_t, etc., looks clearer - it's written
>>>> in C, not in some home-made mongrel language.
>>>
>>> So you kind of home-made mongrel language is this fragment of code
>>> written in:
>>>
>>>
>>> struct stat {
>>> dev_t st_dev; /* ID of device containing file */
>>> ino_t st_ino; /* inode number */
>>> mode_t st_mode; /* protection */
>>> nlink_t st_nlink; /* number of hard links */
>>> uid_t st_uid; /* user ID of owner */
>>> gid_t st_gid; /* group ID of owner */
>>> dev_t st_rdev; /* device ID (if special file) */
>>> off_t st_size; /* total size, in bytes */
>>> blksize_t st_blksize; /* blocksize for file system I/O */
>>> blkcnt_t st_blocks; /* number of 512B blocks allocated */
>>> time_t st_atime; /* time of last access */
>>> time_t st_mtime; /* time of last modification */
>>> time_t st_ctime; /* time of last status change */
>>> };
>>>
>>> You know, I can't see a single standard integer type in there. And I
>>> can't guess those typedefs are. If I wanted to duplicated this struct to
>>> use in an FFI, I would have my work cut out.
>>
>> Get better FFI?
>
>The only way to get a better FFI to make sense of badly written code
>like this is to incorporate a C compiler. That is not trivial.
>
>I believe that Zig can directly make sense of C headers, but it does so
>by the simple expedient of packaging the Clang compiler, which itself
>includes LLVM.
>
>> On a POSIX system, your FFI should come loaded with all the baby _t's,
>> so as not to foist this problem onto the application developer.
>
>So POSIX makes available all the relevant C header information in a
>universal format that doesn't need mucking about with C typedefs, C
>#includes, C #defines, C's multitudinous standard types, C's algorithms
>for padding struct members, conditional C #ifs and #ifdefs, and
>expanding C macros?
>
>I didn't know that. But how about all the 1000s of third party libraries?
>
>> his is the TXR Lisp interactive listener of TXR 257.
>> Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
>> Warning: may explode if heated, cooled or maintained at room temperature.
>> 1> (typedef stat (struct stat
>> (dev dev-t)
>> (ino ino-t)
>> (mode mode-t)
>> (nlink nlink-t)
>> (git gid-t)
>> (uid uid-t)
>> (rdev dev-t)
>> (size off-t)
>> (blksize blksize-t)
>> (blocks blkcnt-t)
>> (atime time-t)
>> (mtime time-t)
>> (ctime time-t)))
>> #<ffi-type (struct stat (dev dev-t) (ino ino-t) (mode mode-t) (nlink nlink-t)
>> (git gid-t) (uid uid-t) (rdev dev-t) (size off-t) (blksize blksize-t)
>> (blocks blkcnt-t) (atime time-t) (mtime time-t) (ctime time-t))>
>> 2> (sizeof stat)
>> 60
>> 3> (alignof stat)
>> 4
>
>If I wanted to use this from my script language, say, this wouldn't be
>much help. I need concrete types. For example:
>
> type ws_msg64 = struct $caligned
> ref void hwnd
> int32 message
> int64 wparam
> int64 lparam
> int32 time
> int32 ptx
> int32 pty
> end
>
>
varies from the x86 world.

The migration effort from 16-bit to 32-bit for uids, gids and device identifiers back
around 1990 is another reason to use abstract types.

On 10/05/2021 20:35, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 10/05/2021 19:29, Keith Thompson wrote:
>
>> But I don't get why you think it's OK for this document to avoid using
>> intmax, and vaguely suggest the size is 64 bits, but I'm not allowed to
>> do that.
>>
>> Well, I will give a suggestion why they do it that way: the C
>> preprocessor knows nothing about C types, so talking about intmax_t
>> would be meaningless in that context.
>
> Unless the C pre-processor _pass_ of the compiler is written
> in fortran, it will likely be written in C, and will use standard
> C types, such as intmax_t when processing constants in pre-processor
> constructs such as #if.

(My C preprocessor was written in my systems language which uses 'i64'.)

>
>> You've got that back to front. People here (you and David Brown) are
>> pretending to have no idea what type "i64" might be.
>
> Give you made it up, it can mean anything you want it to. That doesn't
> imply that the meaning is in any way universal or conventional.

Languages are notorious for not using the intuitive, common-sense terms
that you might see in informal discussions or in pseudo-code. Yet, i32
et al do feature here:

https://en.wikipedia.org/wiki/Integer_(computer_science)

Under the Name column, and are far less ambiguous or overloaded than the
other suggestions.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Monday, 10 May 2021 at 19:44:37 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> > On Monday, 10 May 2021 at 18:26:56 UTC+1, Bart wrote:
>> >> On 10/05/2021 17:35, Malcolm McLean wrote:
>> >>
>> >> > The term for a 16 bit type is "plyte" and a 32 bit type a "dyner", but they have never
>> >> > really caught on. Technically a "byte" doesn't mean "8 bits" either, as we all know
>> >> > on comp.lang.c.
>> >> >
>> >>
>> >> Do you have a reference for plyte and dyner? The only hit on Google was
>> >> someone called Malcolm McLean suggesting them a few years ago.
>> >>
>> > https://en.wikipedia.org/wiki/Units_of_information
>> >
>> > (I didn't invent the terms, and haven't edited this page).
>> That page mentions neither "plyte" nor "dyner".
>>
> So this conforms to the general pattern. Someone on Usenet demands "sources,
> references". References are duly provided. Then inevitable some reason is
> trotted out for claiming that the challenge has not been met.

Malcolm, it can be difficult to tell when you're joking.

You provided a link to a Wikipedia page. I pointed out that the page
does not mention the terms you claim it does.

I mentioned another source that mentions similar terms, but also does
not mention either "plyte" or "dyner". It does mention "playte" and
"dynner", but makes it clear that they not, as you claimed, "*The* term
for a 16 bit type .. and a 32 bit type", but are in fact "rare and
extremely silly".

You made a false claim. You provided references that do not support
your false claim. This was pointed out, perhaps in more detail than was
strictly necessary. You claim victimhood. Is that the general pattern
you're saying this conforms to?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Bart <bc@freeuk.com> writes:
> On 10/05/2021 19:29, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 09/05/2021 23:00, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>> [...]
>>>>> By CPP I mean the C preprocessor. For example:
>>>>>
>>>>> #if 1000000000*1000000000==1000000000000000000
>>>>>
>>>>> Arithmetic done with the widest integer type, usually i64.
>>>>
>>>> And again, you use your own invented terminology when the existing
>>>> terms defined in the C standard are unambiguous.
>>>>
>>>
>>> You flatter me. The term came from the first reasonable-looking google
>>> hit, which was:
>>>
>>> https://gcc.gnu.org/onlinedocs/cpp/If.html#If
>>>
>>> and it says:
>>>
>>> "The preprocessor calculates the value of expression. It carries out
>>> all calculations in the widest integer type known to the compiler; on
>>> most machines supported by GCC this is 64 bits. This is not the same
>>> rule as the compiler uses to calculate the value of a constant
>>> expression, and may give different results in some cases."
>>>
>>> This also makes the same point as my post. (You might want to file a
>>> bug report as to why these gcc docs don't use 'intmax_t' and
>>> 'uintmax_t'.)
>>
>> Why would I want to do that? It's a document accurately describing a
>> specific implementation. When you wrote "By CPP I mean the C
>> preprocessor", were you referring to a specific implementation?
>
> Yes, I'm mainly talking about C implementations for current desktop
> machines.
>
> But I don't get why you think it's OK for this document to avoid using
> intmax, and vaguely suggest the size is 64 bits, but I'm not allowed
> to do that.

Because that document is about a specific implementation, and your post
in comp.lang.c should be about C unless you say otherwise.

> Well, I will give a suggestion why they do it that way: the C
> preprocessor knows nothing about C types, so talking about intmax_t
> would be meaningless in that context.

"For the purposes of this token conversion and evaluation, all signed
integer types and all unsigned integer types act as if they have the
same representation as, respectively, the types intmax_t and uintmax_t
defined in the header <stdint.h>."

The preprocessor doesn't have to know about intmax_t and uintmax_t to
conform to that requirement.

>> Oh, never mind, you know what they are, you're just pretending not to
>> understand.
>
> You've got that back to front. People here (you and David Brown) are
> pretending to have no idea what type "i64" might be.

Sure "i64" is obviously meant to be a signed 64-bit integer type. I was
just wondering why you use that invented term for it.

> And in doing so, avoiding acknowledging my point, which was that the C
> preprocessor (of the targets above) defaults to 64-bit arithmetic
> (that is, intmax_t, uintmax_t, int64_t, uint64_t, signed long int
> (Linux64), signed long long int (everything else), unsigned....),
> while the C compiler proper is still stuck at 32 bits (that is,
> int32_t,......).

What do you mean by "of the targets above"? And what do you mean when
you say that "the C compiler proper is still stuck at 32 bits"?

> See how it can get out of hand when you try to be overly pedantic.
>
> In my dealings with C via a FFI, integer types are one of these eight
> universally known types: i8 i16 i32 i64 u8 u16 u32 u64. Those myriad
> types of C don't exist outside the language.

Of course intmax_t et al don't exist outside the language. (Well, they
exist in C++, and probably some other C-derived languages). Would it do
any good to remind you that this is comp.lang.c?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

On 10/05/2021 20:58, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:

> Sure "i64" is obviously meant to be a signed 64-bit integer type. I was
> just wondering why you use that invented term for it.

It's an informal short-hand when talking about such types.

>> And in doing so, avoiding acknowledging my point, which was that the C
>> preprocessor (of the targets above) defaults to 64-bit arithmetic
>> (that is, intmax_t, uintmax_t, int64_t, uint64_t, signed long int
>> (Linux64), signed long long int (everything else), unsigned....),
>> while the C compiler proper is still stuck at 32 bits (that is,
>> int32_t,......).
>
> What do you mean by "of the targets above"?

'Current desktop machines'.

> And what do you mean when
> you say that "the C compiler proper is still stuck at 32 bits"?
All the C compilers I've tried for the last decade use 32 bits for
'int', and signed 32 bits for literals such as '1234'.

By contrast, my language (and the C preprocessor) have long moved on to
64 bits.

>> See how it can get out of hand when you try to be overly pedantic.
>>
>> In my dealings with C via a FFI, integer types are one of these eight
>> universally known types: i8 i16 i32 i64 u8 u16 u32 u64. Those myriad
>> types of C don't exist outside the language.
>
> Of course intmax_t et al don't exist outside the language. (Well, they
> exist in C++, and probably some other C-derived languages). Would it do
> any good to remind you that this is comp.lang.c?

Would it do much good to suggest using more informal, more universal
terms for such types? Knowing about 'intmax_t' might be important if
someone had to write some actual C code rather than having a tangential
discussion, but even writing some processor code, what you really want
to know are actual limits.

On 2021-05-10, Bart <bc@freeuk.com> wrote:
> On 10/05/2021 19:46, Kaz Kylheku wrote:
>> On 2021-05-10, Bart <bc@freeuk.com> wrote:
>>> On 10/05/2021 14:44, David Brown wrote:
>>>> On 10/05/2021 15:20, Bart wrote:
>>>
>>>>> The reason was to reduce the already bloated size of the generated code
>>>>> (that had extra parentheses, casts etc), and make it somewhat more
>>>>> readable if I had to ever look at it.
>>>>
>>>> You sometimes make relevant points about the weaknesses in C. Harping
>>>> on about such ridiculously small quibbles like this makes a mockery of that.
>>>
>>> How complicated does a /basic/ type have to be before even you start
>>> complaining?
>>>
>>> For this purpose, using stdint types exclusively pointlessly adds about
>>> 7.5% to the size of the generated code, but more importantly, makes it
>>> even more cluttered than it already if you need to debug it.
>>>
>>>>> They also matched more directly the types in the original source which
>>>>> could simply be generated verbatim instead of having to convert to
>>>>> int64_t etc.
>>>>>
>>>>
>>>> Now, finally, you have a point that is meaningful. If you are
>>>> transcompiling from another language to C, then it might make sense to
>>>> use typenames in C that match those of the original language - /if/ the
>>>> types convey the same meaning.
>>>
>>> Actually, this isn't so importent, just more convenient; the same
>>> function that generates a basic type name would work for both languages.
>>>
>>>>>
>>>>>> How about trying to be
>>>>>> /better/ than those you deride?
>>>>>
>>>>> You mean, like creating a whole, better language? That's an idea...
>>>>
>>>> No - I mean like writing standard C when you are writing C, and using C
>>>> terms when you are discussing C.
>>>
>>> When discussing C then it is pointlessly pedantic to write out
>>> "uint64_t" in full; neither of us are C compilers, and we're writing in
>>> English not code. "u64" or "uint64" (or "unsigned 64 bits") are all
>>> well-understood descriptions of that type.
>>>
>>>
>>> (What did the forum look like before 1999, were people actually writing
>>> out "unsigned long long int" in full to describe a 64-bit value?)
>>>
>>>
>>>>> Compare with the original; which one looks cleaner and clearer?
>>>>
>>>> The version with int32_t, uint32_t, etc., looks clearer - it's written
>>>> in C, not in some home-made mongrel language.
>>>
>>> So you kind of home-made mongrel language is this fragment of code
>>> written in:
>>>
>>>
>>> struct stat {
>>> dev_t st_dev; /* ID of device containing file */
>>> ino_t st_ino; /* inode number */
>>> mode_t st_mode; /* protection */
>>> nlink_t st_nlink; /* number of hard links */
>>> uid_t st_uid; /* user ID of owner */
>>> gid_t st_gid; /* group ID of owner */
>>> dev_t st_rdev; /* device ID (if special file) */
>>> off_t st_size; /* total size, in bytes */
>>> blksize_t st_blksize; /* blocksize for file system I/O */
>>> blkcnt_t st_blocks; /* number of 512B blocks allocated */
>>> time_t st_atime; /* time of last access */
>>> time_t st_mtime; /* time of last modification */
>>> time_t st_ctime; /* time of last status change */
>>> };
>>>
>>> You know, I can't see a single standard integer type in there. And I
>>> can't guess those typedefs are. If I wanted to duplicated this struct to
>>> use in an FFI, I would have my work cut out.
>>
>> Get better FFI?
>
> The only way to get a better FFI to make sense of badly written code
> like this is to incorporate a C compiler. That is not trivial.

Or you can write it in C like I did. At initialization time, all it does
is measure the sizes and signedness of types like uid_t, which come
directly from a POSIX header, and maps them accordingly to an
existing FFI type.

> I believe that Zig can directly make sense of C headers, but it does so
> by the simple expedient of packaging the Clang compiler, which itself
> includes LLVM.

That's just their stupidity.

If I weren't working in C, I could still get the information from the
headers at build time. I'd just need the build to have access to the
cross-compiler which targets the same machine. I'd use that to compile a
small test program (which is never executed) and pull the information
from its body. Then pull that information into my program's build.
>
>> On a POSIX system, your FFI should come loaded with all the baby _t's,
>> so as not to foist this problem onto the application developer.
>
> So POSIX makes available all the relevant C header information in a
> universal format that doesn't need mucking about with C typedefs, C
> #includes, C #defines, C's multitudinous standard types, C's algorithms
> for padding struct members, conditional C #ifs and #ifdefs, and
> expanding C macros?

Nope; why would it? That's the interface. The stuff is written in C,
defined using C, so you can't avoid interacting with C in order to
wheedle the information out of it.

You can certainly avoid integrating a C compiler into your program,
and you can avoid hacks like processing header files yourself.

>> his is the TXR Lisp interactive listener of TXR 257.
>> Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
>> Warning: may explode if heated, cooled or maintained at room temperature.
>> 1> (typedef stat (struct stat
>> (dev dev-t)
>> (ino ino-t)
>> (mode mode-t)
>> (nlink nlink-t)
>> (git gid-t)
>> (uid uid-t)
>> (rdev dev-t)
>> (size off-t)
>> (blksize blksize-t)
>> (blocks blkcnt-t)
>> (atime time-t)
>> (mtime time-t)
>> (ctime time-t)))
>> #<ffi-type (struct stat (dev dev-t) (ino ino-t) (mode mode-t) (nlink nlink-t)
>> (git gid-t) (uid uid-t) (rdev dev-t) (size off-t) (blksize blksize-t)
>> (blocks blkcnt-t) (atime time-t) (mtime time-t) (ctime time-t))>
>> 2> (sizeof stat)
>> 60
>> 3> (alignof stat)
>> 4
>
> If I wanted to use this from my script language, say, this wouldn't be
> much help.

Well, no; you'd have to get the same thing working in your own
script language.

> I need concrete types. For example:
>
> type ws_msg64 = struct $caligned
> ref void hwnd
> int32 message
> int64 wparam
> int64 lparam
> int32 time
> int32 ptx
> int32 pty
> end

That is a foolish way to proceed that will not work between 32 and 64
bit Windows. Also, note that wparam is an unsigned type; it should be
be uint64.

You really want to define the typedefs that Windows uses, in a similar
way.

Here is how it is handled in a TXR Lisp Win32 programming sample:

(typedef LPARAM int-ptr-t)
(typedef WPARAM uint-ptr-t)

(typedef UINT uint32)
(typedef LONG int32)
(typedef WORD uint16)
(typedef DWORD uint32)

(typedef HWND (cptr HWND))

(typedef POINT (struct POINT
(x LONG)
(y LONG)))

(typedef MSG (struct MSG
(hwnd HWND)
(message UINT)
(wParam WPARAM)
(lParam LPARAM)
(time DWORD)
(pt POINT)))

LPARAM is defined as int-ptr-t, which is a FFI type denoting the
pointer-sized integer. That is correcty 64 bits on Win64, and 32 on
Win32.

The sample program in which is this is found works fine under a 32 bit
build of the language as well as under a 64 bit build.

The point isn't just portability between two ABI's, but readability.

Someone reading the structure definition looking for a problem
wants to compare it to the original C one, and easily convince
themselves that the members are the right types in the right order,
since the same names are used.

On 10/05/2021 20:41, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:

>>> Get better FFI?
>
> Bart should learn the art of abstraction first. There are very good
> reasons that the members of struct stat are abstract - noting particularly
> the idea of portable software that doesn't run on Bart's 8086 machines and
> where the size of an hardware integral typeBart <bc@freeuk.com> writes:

<snip>

>> type ws_msg64 = struct $caligned
>> ref void hwnd
>> int32 message
>> int64 wparam
>> int64 lparam
>> int32 time
>> int32 ptx
>> int32 pty
>> end
>>
>>
> varies from the x86 world.
>
> The migration effort from 16-bit to 32-bit for uids, gids and device identifiers back
> around 1990 is another reason to use abstract types.

My example came from a system header. Those are necessarily platform
specific.

Wouldn't it be better (for readability, maintenance, reducing bugs) to
have a dedicated header for each platform, rather than to have one
monster header that tries (badly) to accommodate every possible target
past, present and future?

In any case, the 16- to 32-bit migration would have effected 'int' and
also to some extent 'long' types. long itself already has different
meanings between between Linux64 and everything else.

scott@slp53.sl.home (Scott Lurndal) writes:
> Bart <bc@freeuk.com> writes:
>>On 10/05/2021 19:29, Keith Thompson wrote:
>
>>But I don't get why you think it's OK for this document to avoid using
>>intmax, and vaguely suggest the size is 64 bits, but I'm not allowed to
>>do that.
>>
>>Well, I will give a suggestion why they do it that way: the C
>>preprocessor knows nothing about C types, so talking about intmax_t
>>would be meaningless in that context.
>
> Unless the C pre-processor _pass_ of the compiler is written
> in fortran, it will likely be written in C, and will use standard
> C types, such as intmax_t when processing constants in pre-processor
> constructs such as #if.

Or it can use long long and unsigned long long, resulting in a
preprocessor that works correctly as part of any implementation where
intmax_t and uintmax_t are 64 bits. Code that's part of the
implementation doesn't have to be portable.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

On 10/05/2021 21:09, Kaz Kylheku wrote:
> On 2021-05-10, Bart <bc@freeuk.com> wrote:

>> If I wanted to use this from my script language, say, this wouldn't be
>> much help.
>
> Well, no; you'd have to get the same thing working in your own
> script language.
>
>> I need concrete types. For example:
>>
>> type ws_msg64 = struct $caligned
>> ref void hwnd
>> int32 message
>> int64 wparam
>> int64 lparam
>> int32 time
>> int32 ptx
>> int32 pty
>> end
>
> That is a foolish way to proceed that will not work between 32 and 64
> bit Windows.

Setting aside that my stuff now only works with 64 bits, trying to have
one struct for both Win32 and Win64 just wouldn't work. Apart from being
messy, this script language produced a single bytecode binary to work on
either.

So I used two definitions, fixed up at runtime.

Also, note that wparam is an unsigned type; it should be
> be uint64.

Wparam is UINT_PTR or some such thing.

> You really want to define the typedefs that Windows uses, in a similar
> way.

Actually that's what I do use for most of them; I specifically chose
that example because it had plain member types. Otherwise there's a
bunch of types like this:

global type wt_wparam64 = word64 # u64 and word64 are synonyms

> Here is how it is handled in a TXR Lisp Win32 programming sample:
>
> (typedef LPARAM int-ptr-t)
> (typedef WPARAM uint-ptr-t)
>
> (typedef UINT uint32)
> (typedef LONG int32)
> (typedef WORD uint16)
> (typedef DWORD uint32)
>
> (typedef HWND (cptr HWND))
>
>
> (typedef POINT (struct POINT
> (x LONG)
> (y LONG)))
>
> (typedef MSG (struct MSG
> (hwnd HWND)
> (message UINT)
> (wParam WPARAM)
> (lParam LPARAM)
> (time DWORD)
> (pt POINT)))

> LPARAM is defined as int-ptr-t, which is a FFI type denoting the
> pointer-sized integer. That is correcty 64 bits on Win64, and 32 on
> Win32.

So largely similar to mine. At one time I had intm, wordm
(machine-word-sized, signed/unsigned) and intp, wordp (pointer-sized
ints). But since settling on 64 bits only, I could simplify things quite
a bit.

Basically, most parameter and return types from WinAPI are one of i32
u32 i64 u64, even pointers. I go into more detail only when necessary.
Otherwise, there are HUNDREDs of special WinAPI types.

> The sample program in which is this is found works fine under a 32 bit
> build of the language as well as under a 64 bit build.

As I mentioned, I used to have AOT-compiled bytecode that needed to be
portable (actually, for certain programs, the same binary would work on
Win32, Win64, Linux32, Linux64, x86 or ARM). But now I'm moving to
run-from-source for more flexibility, so I don't need to put as much
effort into achieving that.

> Someone reading the structure definition looking for a problem
> wants to compare it to the original C one, and easily convince
> themselves that the members are the right types in the right order,
> since the same names are used.

I can't be dealing with the original names, otherwise I'd just be
recreating the same bloat of WinAPI.

Here's one of my redefined structs (here from compiled code):

record input_record = $caligned
wt_word eventtype
wt_bool keydown
wt_word repeatcount
wt_word virtualkeycode
wt_word virtualscancode
union
wt_word unicodechar
wt_char asciichar
end
wt_dword controlkeystate
end

(Before I introduced the $caligned flag, this needed explicit padding
fields to match the C layout.) This is the original MS version:

typedef struct _INPUT_RECORD {
WORD EventType;
union {
KEY_EVENT_RECORD KeyEvent;
MOUSE_EVENT_RECORD MouseEvent;
WINDOW_BUFFER_SIZE_RECORD WindowBufferSizeEvent;
MENU_EVENT_RECORD MenuEvent;
FOCUS_EVENT_RECORD FocusEvent;
} Event;
} INPUT_RECORD;

Notice this consists of 5 further nested records. It's been simplified
and somewhat flattened because MS just makes things too damn complicated.

>
> (The only remaining suspicion, then, is that the types themselves
> are wrongly defined, or that the FFI isn't laying out structure members
> correctly.)
>
> By renaming the types to the machine-oriented equivalents, you're adding
> a layer of obfuscation in the face of someone trying to convince
> themselves that the definition is correct.

You'll find out it's wrong when it doesn't work.

On 5/10/2021 5:12 AM, Bart wrote:
> On 10/05/2021 12:14, David Brown wrote:
>> On 10/05/2021 11:48, Bart wrote:
>
>> The C preprocessor applies to all C standards - C90 does not have
>> intmax_t, as that was introduced in C99.
>>
>>>
>>>> There's nothing in C called "i64" unless you define it yourself.
>>>> The standard says that preprocessor arithmetic is done using intmax_t
>>>> or uintmax_t, which are typically 64 bits.  Why not just say that?
>>>
>>> Because i64 and u64 are universally understood, and exactly match my
>>> example.
>>
>> i64 and u64 are your personal non-standard pointless renames for
>> standard, established and known C types int64_t and uin64_t.
>
> Practically every other C application or library also defines its own
> 'pointless' names for such fixed-width types. You'd have to ask their
> authors why they do that; it's not always because the program started
> life before stdint.h was common, or because they are keen to have their
> program work on C90.
>
> My guess is that the stdint.h names are considered too unwieldy, too
> ugly or too cluttery by some, with the important discriminating '32' or
> '64' buried a little too deeply:
>
>   void fn(uint32_t s, uint64_t t, int32_t u);
>
> versus:
>
>   void fn(u32 s, u64 t, i32 u);
[...]
Just jesting here: Well at least they are not:

unsigned_integer_thirty_two_bits_in_size

unsigned_integer_sixty_four_bits_in_size

lol. ;^)