John Bode <jfbode1029@gmail.com> writes:

> On 6/24/21 12:33 PM, Tim Rentsch wrote:
>
>> John Bode <jfbode1029@gmail.com> writes:
>>
>> [...]
>>
>>> To reiterate a point I make a lot - typedef on its own creates leaky
>>> abstractions. If I need to know that I have to use the `.` or `->`
>>> operator on something, I'd rather have it declared as `struct A foo;` or
>>> `struct B *ptr;` instead of a type name that doesn't convey struct-ness
>>> at all. Same reason I don't like it when people hide pointers behind
>>> typedefs - I once spent half a day chasing my tail because somebody
>>> created a typedef name for a pointer type and used that as a template
>>> parameter for a vector in C++, such that when I was using an iterator
>>> I needed to write
>>>
>>> (*it)->do_something();
>>>
>>> However, since the typedef name didn't indicate pointer-ness *at all*, I
>>> wound up writing
>>>
>>> it->do_something();
>>>
>>> and g++ vomited up hundreds of incomprehensible error messages that
>>> basically boiled down to "you need to use a * here, dummy".
>>
>> Sounds to me like the culprit is C++, not typedefs.
>
> g++ doesn't handle errors in template parameters very well and generates
> a *lot* of hard-to-follow error messages for relatively simple mistakes.
> And at the time I was still relatively inexperienced with C++, which
> didn't help.
>
> But the typedef name (or, more properly, the incomplete and leaky
> abstraction introduced by that typedef name) was the actual culprit.
> [...]

I stand by my earlier claim that the culprit here is C++
rather than typedefs.

On 7/11/21 2:26 AM, Tim Rentsch wrote:
> John Bode <jfbode1029@gmail.com> writes:
>
>> On 6/24/21 12:33 PM, Tim Rentsch wrote:
>>
>>> John Bode <jfbode1029@gmail.com> writes:
>>>
>>> [...]
>>>
>>>> To reiterate a point I make a lot - typedef on its own creates leaky
>>>> abstractions. If I need to know that I have to use the `.` or `->`
>>>> operator on something, I'd rather have it declared as `struct A foo;` or
>>>> `struct B *ptr;` instead of a type name that doesn't convey struct-ness
>>>> at all. Same reason I don't like it when people hide pointers behind
>>>> typedefs - I once spent half a day chasing my tail because somebody
>>>> created a typedef name for a pointer type and used that as a template
>>>> parameter for a vector in C++, such that when I was using an iterator
>>>> I needed to write
>>>>
>>>> (*it)->do_something();
>>>>
>>>> However, since the typedef name didn't indicate pointer-ness *at all*, I
>>>> wound up writing
>>>>
>>>> it->do_something();
>>>>
>>>> and g++ vomited up hundreds of incomprehensible error messages that
>>>> basically boiled down to "you need to use a * here, dummy".
>>>
>>> Sounds to me like the culprit is C++, not typedefs.
>>
>> g++ doesn't handle errors in template parameters very well and generates
>> a *lot* of hard-to-follow error messages for relatively simple mistakes.
>> And at the time I was still relatively inexperienced with C++, which
>> didn't help.
>>
>> But the typedef name (or, more properly, the incomplete and leaky
>> abstraction introduced by that typedef name) was the actual culprit.
>> [...]
>
> I stand by my earlier claim that the culprit here is C++
> rather than typedefs.
>

I honestly don't know how to make it any clearer. I lost time due to
using the wrong syntax. I was using the wrong syntax because the
information I needed in order to use the right syntax was hidden from
me. That's not a function of it being C++, that's a function of the
abstraction not being complete.

I'm not saying don't use typedef. I'm saying that you shouldn't hide
pointer-ness or struct-ness behind a typedef name *unless* you are
willing to provide an API that hides corresponding operations on those
types as well.

The C standard library doesn't hide pointer-ness behind typedef names
(e.g. the FILE type). You shouldn't either.

If you're going to hide a floating point type behind a typedef name,
don't make me have to hunt for the typedef to know which conversion
specifier I have to use to print it out - provide an API to format it
for me.

If you're going to hide a struct or union type behind a typedef name,
don't make me hunt down the typedef to know how to access the members -
provide an API to do that for me.

If you're going to hide an array type behind a typedef name, don't
make me hunt down the typedef to know I have to use the [] operator
or the size - provide an API to handle that for me.

If you're going to create an abstraction for a type, CREATE A FULL
ABSTRACTION FOR THAT TYPE or don't bother doing it at all.

On 2021-07-26, John Bode <jfbode1029@gmail.com> wrote:
> If you're going to hide a struct or union type behind a typedef name,
> don't make me hunt down the typedef to know how to access the members -
> provide an API to do that for me.

I don't find that reasonable; it's pretty common to make typedef names
for structures just to have a shorthand for declaring them, without
intending to create a fully opaque type with abstracted operations.

typedef struct version {
int major;
int minor;
} version_t;

The typedef is co-located with the struct declaration; your ediutor
should be able to jump to the definition of version_t which is
the above line.

Your remark makes sense for a typedef name for a pointer to such
a structure. That's often intended to be an abstract handle.

> If you're going to hide an array type behind a typedef name, don't

Array typedefs should only ever be used for breaking up declarations.
simplifying declarations, not as an abstract type in an API.

Hiding arrays behind typedef names is a poor idea because the result
"abstraction" still cannot be passed to functions, returned or assigned.

The type still decays into a pointer when used as as parameter type.

typedef int foo_t[42];

void fun(foo_t x) {
// programmer trap:
// sizeof x isn't sizeof (foo_t) here!
foo_t y;
// sizeof y *is* sizeof (foo_t).
}

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

Kaz Kylheku <563-365-8930@kylheku.com> writes:
> On 2021-07-26, John Bode <jfbode1029@gmail.com> wrote:
>> If you're going to hide a struct or union type behind a typedef name,
>> don't make me hunt down the typedef to know how to access the members -
>> provide an API to do that for me.
>
> I don't find that reasonable; it's pretty common to make typedef names
> for structures just to have a shorthand for declaring them, without
> intending to create a fully opaque type with abstracted operations.
>
> typedef struct version {
> int major;
> int minor;
> } version_t;
>
> The typedef is co-located with the struct declaration; your ediutor
> should be able to jump to the definition of version_t which is
> the above line.

I disagree. I prefer to refer to the type as "struct version" and not
bother with the typedef.

I'm not arguing I'm right and you're wrong. It's just my preference
(for which I've given reasons before).

The point is that there are two major styles for defining struct types,
and every C programmer who works with code written by other people will
need to deal with both of them.

If I did use typedefs, I'd probably use the same identifier for the tag
and the typedef name.

[...]

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

On 7/27/2021 8:47 AM, Kaz Kylheku wrote:
> On 2021-07-26, John Bode <jfbode1029@gmail.com> wrote:
>> If you're going to hide a struct or union type behind a typedef name,
>> don't make me hunt down the typedef to know how to access the members -
>> provide an API to do that for me.
>
> I don't find that reasonable; it's pretty common to make typedef names
> for structures just to have a shorthand for declaring them, without
> intending to create a fully opaque type with abstracted operations.
>
> typedef struct version {
> int major;
> int minor;
> } version_t;
>
> The typedef is co-located with the struct declaration; your ediutor
> should be able to jump to the definition of version_t which is
> the above line.
[...]

100% pure nitpick... I got a bit scolded one time for using the *_t
suffix in a POSIX environment. Its reserved!

On 7/27/2021 8:47 AM, Kaz Kylheku wrote:
> On 2021-07-26, John Bode <jfbode1029@gmail.com> wrote:
>> If you're going to hide a struct or union type behind a typedef name,
>> don't make me hunt down the typedef to know how to access the members -
>> provide an API to do that for me.
>
> I don't find that reasonable; it's pretty common to make typedef names
> for structures just to have a shorthand for declaring them, without
> intending to create a fully opaque type with abstracted operations.
>
> typedef struct version {
> int major;
> int minor;
> } version_t;
>
> The typedef is co-located with the struct declaration; your ediutor
> should be able to jump to the definition of version_t which is
> the above line.

[...]

I still like to avoid typedefs from, time to time:
__________________________________
#include <stdio.h>

struct version
{ int major;
int minor;
};

void
version_output(
struct version const* const self
) {
printf("FooProg Version: (%d.%d)\n", self->major, self->minor);
}

static struct version g_version = { 0, 1 };

int main()
{ version_output(&g_version);

struct version version = { 0, 2 };
version_output(&version);

return 0;
} __________________________________

Le 27/07/2021 à 19:55, Keith Thompson a écrit :
> Kaz Kylheku <563-365-8930@kylheku.com> writes:
>> On 2021-07-26, John Bode <jfbode1029@gmail.com> wrote:
>>> If you're going to hide a struct or union type behind a typedef name,
>>> don't make me hunt down the typedef to know how to access the members -
>>> provide an API to do that for me.
>>
>> I don't find that reasonable; it's pretty common to make typedef names
>> for structures just to have a shorthand for declaring them, without
>> intending to create a fully opaque type with abstracted operations.
>>
>> typedef struct version {
>> int major;
>> int minor;
>> } version_t;
>>
>> The typedef is co-located with the struct declaration; your ediutor
>> should be able to jump to the definition of version_t which is
>> the above line.
>
> I disagree. I prefer to refer to the type as "struct version" and not
> bother with the typedef.

Okay,then certainly it's a matter of taste, and that can't be discussed.

All I'm seeing though is that your argument could be used for just any
type really. Any typedef "hides" the type. It's made for that. It's an
abstraction. It's the whole point. Are you for typeless languages?

Or, what is it that you specifically have with structs that you wouldn't
mind with other types? Like, why does it bother you not to directly see
that a type is a struct, while the fact it's an int, a double, or an
array would matter to you? In any case, you must know what a given type
is for properly using it.

I don't get it. And others seem not to as well. I guess we will never
get it, and that's fine.

Guillaume <message@bottle.org> writes:
>Le 27/07/2021 à 19:55, Keith Thompson a écrit :
>> Kaz Kylheku <563-365-8930@kylheku.com> writes:
>>> On 2021-07-26, John Bode <jfbode1029@gmail.com> wrote:
>>>> If you're going to hide a struct or union type behind a typedef name,
>>>> don't make me hunt down the typedef to know how to access the members -
>>>> provide an API to do that for me.
>>>
>>> I don't find that reasonable; it's pretty common to make typedef names
>>> for structures just to have a shorthand for declaring them, without
>>> intending to create a fully opaque type with abstracted operations.
>>>
>>> typedef struct version {
>>> int major;
>>> int minor;
>>> } version_t;
>>>
>>> The typedef is co-located with the struct declaration; your ediutor
>>> should be able to jump to the definition of version_t which is
>>> the above line.
>>
>> I disagree. I prefer to refer to the type as "struct version" and not
>> bother with the typedef.
>
>Okay,then certainly it's a matter of taste, and that can't be discussed.
>
>All I'm seeing though is that your argument could be used for just any
>type really. Any typedef "hides" the type. It's made for that. It's an
>abstraction. It's the whole point. Are you for typeless languages?
>
>Or, what is it that you specifically have with structs that you wouldn't
>mind with other types? Like, why does it bother you not to directly see
>that a type is a struct, while the fact it's an int, a double, or an
>array would matter to you? In any case, you must know what a given type
>is for properly using it.

Consider abstract types such as pid_t or off_t. These allow
the underlying field to change in size (e.g. from unsigned
short to unsigned int) without changing the semantics of
the use of the type. A simple recompile/relink is all that is
necessary to switch to the new definition on a new machine with
different fundamental types.

When you hide a struct behind a typedef, it's not opaque,
as the field names are not generic (there was a time when any
field name could be used with any pointer, but that's long in
the past now).

I generally fall into Keith's camp on this in C, and in C++
I never use typedef to hide a struct (the struct tag is,
in a sense, a typedef in C++).

On 27/07/2021 23:12, Scott Lurndal wrote:
> Guillaume <message@bottle.org> writes:
>> Le 27/07/2021 à 19:55, Keith Thompson a écrit :
>>> Kaz Kylheku <563-365-8930@kylheku.com> writes:
>>>> On 2021-07-26, John Bode <jfbode1029@gmail.com> wrote:
>>>>> If you're going to hide a struct or union type behind a typedef name,
>>>>> don't make me hunt down the typedef to know how to access the members -
>>>>> provide an API to do that for me.
>>>>
>>>> I don't find that reasonable; it's pretty common to make typedef names
>>>> for structures just to have a shorthand for declaring them, without
>>>> intending to create a fully opaque type with abstracted operations.
>>>>
>>>> typedef struct version {
>>>> int major;
>>>> int minor;
>>>> } version_t;
>>>>
>>>> The typedef is co-located with the struct declaration; your ediutor
>>>> should be able to jump to the definition of version_t which is
>>>> the above line.
>>>
>>> I disagree. I prefer to refer to the type as "struct version" and not
>>> bother with the typedef.
>>
>> Okay,then certainly it's a matter of taste, and that can't be discussed.
>>
>> All I'm seeing though is that your argument could be used for just any
>> type really. Any typedef "hides" the type. It's made for that. It's an
>> abstraction. It's the whole point. Are you for typeless languages?
>>
>> Or, what is it that you specifically have with structs that you wouldn't
>> mind with other types? Like, why does it bother you not to directly see
>> that a type is a struct, while the fact it's an int, a double, or an
>> array would matter to you? In any case, you must know what a given type
>> is for properly using it.
>
> Consider abstract types such as pid_t or off_t. These allow
> the underlying field to change in size (e.g. from unsigned
> short to unsigned int) without changing the semantics of
> the use of the type. A simple recompile/relink is all that is
> necessary to switch to the new definition on a new machine with
> different fundamental types.

I would rather see specific types, such as i16 i32 i64.

If they need to vary by platform, then provide specific headers for that
platform, instead of ending up with an unmaintainable, unreadable,
fragile mess by trying to have one header for everything.

Some integer types will depend on the target so, fine, use special types
for those (size_t and intptr_t for example). But DON'T have a dedicated
integer typedef for every field of every struct! Declarations like this
are a joke:

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 */
};

I think there are 13 fields and 10 different types! There will be a
section of header where those 10 typedefs are defined differently per
platform; just use that same mechanism to define specific stat structs
instead.

> When you hide a struct behind a typedef, it's not opaque,
> as the field names are not generic (there was a time when any
> field name could be used with any pointer, but that's long in
> the past now).
>
> I generally fall into Keith's camp on this in C, and in C++
> I never use typedef to hide a struct (the struct tag is,
> in a sense, a typedef in C++).

You don't need to hide it:

typedef struct {...} struct_T;

instead of:

struct T {...};

Use typedef and you can be consistent with all other named user types.

Guillaume <message@bottle.org> writes:
> Le 27/07/2021 à 19:55, Keith Thompson a écrit :
>> Kaz Kylheku <563-365-8930@kylheku.com> writes:
>>> On 2021-07-26, John Bode <jfbode1029@gmail.com> wrote:
>>>> If you're going to hide a struct or union type behind a typedef name,
>>>> don't make me hunt down the typedef to know how to access the members -
>>>> provide an API to do that for me.
>>>
>>> I don't find that reasonable; it's pretty common to make typedef names
>>> for structures just to have a shorthand for declaring them, without
>>> intending to create a fully opaque type with abstracted operations.
>>>
>>> typedef struct version {
>>> int major;
>>> int minor;
>>> } version_t;
>>>
>>> The typedef is co-located with the struct declaration; your ediutor
>>> should be able to jump to the definition of version_t which is
>>> the above line.
>> I disagree. I prefer to refer to the type as "struct version" and
>> not
>> bother with the typedef.
>
> Okay,then certainly it's a matter of taste, and that can't be discussed.
>
> All I'm seeing though is that your argument could be used for just any
> type really. Any typedef "hides" the type. It's made for that. It's an
> abstraction. It's the whole point. Are you for typeless languages?
>
> Or, what is it that you specifically have with structs that you
> wouldn't mind with other types? Like, why does it bother you not to
> directly see that a type is a struct, while the fact it's an int, a
> double, or an array would matter to you? In any case, you must know
> what a given type is for properly using it.
>
> I don't get it. And others seem not to as well. I guess we will never
> get it, and that's fine.

As I said, I've discussed my reasoning here before, but I don't mind
doing so again.

For me, the point is that "struct version" already has a perfectly good
name: "struct version". I see no great value in giving it another name,
such as "version_t", or even "version". It introduces potential
confusion with no particular benefit.

FILE is a great example of an appropriate use of a typedef. It's
required to be an object type, but code that uses it doesn't and
shouldn't care that it's a struct, and shouldn't attempt to refer to its
members, if any. But code that uses struct version needs to know that
it's a struct, and needs to be able to refer to its members.

Typedefs are also a good way to define a name for an integer type where
code that uses it doesn't need to know which underlying type it is.
They can provide information about what the type is used for (size_t,
for example). A struct tag can provide that same information.

Historically, typedefs were a relatively late addition to C.
In pre-typedef C, a type name could never be just an identifier. Type
names (unlike in some languages) were always constructed using syntax
involving some combination of keywords, symbols, and identifiers.
It's possible but not practical to give *all* types names consisting of
a single identifier. I see no great advantage in doing so just for
struct types.

Having said that, if I were working on a C project that had a convention
of using typedefs for struct types, I would follow that convention
without hesitation. If there were inconsistent rules about the
relationship between tag names and typedef names, I might raise that as
a concern and suggest using the same identifier for both. And in
$DAYJOB I work in C++, which doesn't have this issue (defining "struct
foo" creates a type named "foo", and I don't call it "struct foo",
because C++ is a different language with different rules).

Routinely using typedefs for struct types strikes me as a way of
papering over an aspect of the C language that some people dislike.
Since I personally don't dislike it, I don't bother unless there's a
good reason to do so.

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

Bart <bc@freeuk.com> writes:
> On 27/07/2021 23:12, Scott Lurndal wrote:
[...]
>> Consider abstract types such as pid_t or off_t. These allow
>> the underlying field to change in size (e.g. from unsigned
>> short to unsigned int) without changing the semantics of
>> the use of the type. A simple recompile/relink is all that is
>> necessary to switch to the new definition on a new machine with
>> different fundamental types.
>
> I would rather see specific types, such as i16 i32 i64.

C has those in <stdint.h> (though not by those names).

> If they need to vary by platform, then provide specific headers for
> that platform, instead of ending up with an unmaintainable,
> unreadable, fragile mess by trying to have one header for everything.

The audience for most system headers is the compiler, not the
programmer. I don't need to look at /usr/include/stdint.h to understand
what int32_t means.

> Some integer types will depend on the target so, fine, use special
> types for those (size_t and intptr_t for example). But DON'T have a
> dedicated integer typedef for every field of every struct!
> Declarations like this are a joke:
>
> 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 */
> };

Would you insist on using the [u]intN_t types for all those members?
And if the requirements for a field vary from one system to another,
what then? Would st_dev and st_ino be the same type on one platform and
different types on another?

> I think there are 13 fields and 10 different types! There will be a
> section of header where those 10 typedefs are defined differently per
> platform; just use that same mechanism to define specific stat structs
> instead.

Are you saying I'd have to use
#include <sys/foostat.h>
on one system and
#include <sys/barstat.h>
on another? I don't think that's really what you meant.

>> When you hide a struct behind a typedef, it's not opaque,
>> as the field names are not generic (there was a time when any
>> field name could be used with any pointer, but that's long in
>> the past now).
>> I generally fall into Keith's camp on this in C, and in C++
>> I never use typedef to hide a struct (the struct tag is,
>> in a sense, a typedef in C++).
>
> You don't need to hide it:
>
> typedef struct {...} struct_T;
>
> instead of:
>
> struct T {...};
>
> Use typedef and you can be consistent with all other named user types.

As you know, that doesn't allow for the very common case of a struct
that contains a pointer to itself. And "struct_T" is (very slightly)
more difficult to type than "struct T".

Most "named user types" are structs. I use a consistent naming scheme
for them. I don't give separate names to pointer or array types, and
most named integer types that I use are defined in standard or system
headers.

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

On 2021-07-27, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Kaz Kylheku <563-365-8930@kylheku.com> writes:
>> On 2021-07-26, John Bode <jfbode1029@gmail.com> wrote:
>>> If you're going to hide a struct or union type behind a typedef name,
>>> don't make me hunt down the typedef to know how to access the members -
>>> provide an API to do that for me.
>>
>> I don't find that reasonable; it's pretty common to make typedef names
>> for structures just to have a shorthand for declaring them, without
>> intending to create a fully opaque type with abstracted operations.
>>
>> typedef struct version {
>> int major;
>> int minor;
>> } version_t;
>>
>> The typedef is co-located with the struct declaration; your ediutor
>> should be able to jump to the definition of version_t which is
>> the above line.
>
> I disagree. I prefer to refer to the type as "struct version" and not
> bother with the typedef.
>
> I'm not arguing I'm right and you're wrong. It's just my preference
> (for which I've given reasons before).

Right, of course; but all I'm saying is that there exists a certain
coding style with those typedefs, in which the typedefs do *not* signify
"I am an opaque type accessed only by an API".

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

Kaz Kylheku <563-365-8930@kylheku.com> writes:
> On 2021-07-27, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Kaz Kylheku <563-365-8930@kylheku.com> writes:
>>> On 2021-07-26, John Bode <jfbode1029@gmail.com> wrote:
>>>> If you're going to hide a struct or union type behind a typedef name,
>>>> don't make me hunt down the typedef to know how to access the members -
>>>> provide an API to do that for me.
>>>
>>> I don't find that reasonable; it's pretty common to make typedef names
>>> for structures just to have a shorthand for declaring them, without
>>> intending to create a fully opaque type with abstracted operations.
>>>
>>> typedef struct version {
>>> int major;
>>> int minor;
>>> } version_t;
>>>
>>> The typedef is co-located with the struct declaration; your ediutor
>>> should be able to jump to the definition of version_t which is
>>> the above line.
>>
>> I disagree. I prefer to refer to the type as "struct version" and not
>> bother with the typedef.
>>
>> I'm not arguing I'm right and you're wrong. It's just my preference
>> (for which I've given reasons before).
>
> Right, of course; but all I'm saying is that there exists a certain
> coding style with those typedefs, in which the typedefs do *not* signify
> "I am an opaque type accessed only by an API".

Agreed.

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

On 28/07/2021 02:30, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:

>> I think there are 13 fields and 10 different types! There will be a
>> section of header where those 10 typedefs are defined differently per
>> platform; just use that same mechanism to define specific stat structs
>> instead.
>
> Are you saying I'd have to use
> #include <sys/foostat.h>
> on one system and
> #include <sys/barstat.h>
> on another? I don't think that's really what you meant.

No, you'd use:

#include <sys/stat.h>

If you compile on platform foo, the contents of stat.h will be relevant
to foo; on bar, relevant to bar. You don't have one stat.h containing
declarations for a dozen irrelevant platforms to the one you're on.

If you need to cross-compile for foo or bar on X, then you give the
compiler suitable options as to where to look for system headers. (I
guess the same as happens when you give -m32 or -m64 options.) Or you
just have separate compiler installations.

>> You don't need to hide it:
>>
>> typedef struct {...} struct_T;
>>
>> instead of:
>>
>> struct T {...};
>>
>> Use typedef and you can be consistent with all other named user types.
>
> As you know, that doesn't allow for the very common case of a struct
> that contains a pointer to itself.

I think that's covered with:

typedef struct T {...; struct T*...} struct_T;

> And "struct_T" is (very slightly)
> more difficult to type than "struct T".

That was a suggestion. Other hints can be used. For example I commonly
use Trec, or in the past, rT (eg. rsystemtime).

>
> Most "named user types" are structs.

Apart from off_t, clock_t and friends!

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Bart <bc@freeuk.com> writes:
>> On 27/07/2021 23:12, Scott Lurndal wrote:
>[...]

>
>> Some integer types will depend on the target so, fine, use special
>> types for those (size_t and intptr_t for example). But DON'T have a
>> dedicated integer typedef for every field of every struct!
>> Declarations like this are a joke:
>>
>> 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 */
>> };
>
>Would you insist on using the [u]intN_t types for all those members?

We learned thirty years ago that using sized integer types instead
of abstract types in struct stat (and other application<->OS APIs)
was a very, very, very, very bad idea.

Bart has this bugaboo about having to track down the final definitions
of these abstract types, which is, frankly, ridiculous and short-sighted.

In any case, a simple gcc -E will provide the exact line and exact
source file name for any abstract type defined by the implementation
easily and simply.

$ (cd ~; cc -E a.c | grep ino_t)
typedef unsigned long int __ino_t;
typedef __ino_t ino_t;
__ino_t st_ino;

Bart <bc@freeuk.com> writes:
> On 28/07/2021 02:30, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> I think there are 13 fields and 10 different types! There will be a
>>> section of header where those 10 typedefs are defined differently per
>>> platform; just use that same mechanism to define specific stat structs
>>> instead.
>> Are you saying I'd have to use
>> #include <sys/foostat.h>
>> on one system and
>> #include <sys/barstat.h>
>> on another? I don't think that's really what you meant.
>
> No, you'd use:
>
> #include <sys/stat.h>

Right, that's what I do now.

> If you compile on platform foo, the contents of stat.h will be
> relevant to foo; on bar, relevant to bar. You don't have one stat.h
> containing declarations for a dozen irrelevant platforms to the one
> you're on.
>
> If you need to cross-compile for foo or bar on X, then you give the
> compiler suitable options as to where to look for system headers. (I
> guess the same as happens when you give -m32 or -m64 options.) Or you
> just have separate compiler installations.

The approach you suggest is perfectly possible and permitted by the
language. Your complaint isn't about C; it's about how implementers
choose to write their headers.

Personally, it wouldn't affect me, since when I use <sys/stat.h> I
usually consult the relevant documentation, not the contents of the
header file.

I suggest that providing a single header makes maintenance easier. If
an implementer chooses to maintain separate "foo" and "bar" versions of
stat.h, they're likely to generate them from a common source anyway.
It's easy enough to use the preprocessor to generate the different
versions.

>>> You don't need to hide it:
>>>
>>> typedef struct {...} struct_T;
>>>
>>> instead of:
>>>
>>> struct T {...};
>>>
>>> Use typedef and you can be consistent with all other named user types.
>> As you know, that doesn't allow for the very common case of a struct
>> that contains a pointer to itself.
>
> I think that's covered with:
>
> typedef struct T {...; struct T*...} struct_T;

Yes, it is, and that's what often done in practice. And if you want to
do it that way, you certainly can. I suggest that just using "struct T"
and dropping the typedef is simpler.

>> And "struct_T" is (very slightly)
>> more difficult to type than "struct T".
>
> That was a suggestion. Other hints can be used. For example I commonly
> use Trec, or in the past, rT (eg. rsystemtime).

Why are "hints" needed? Why use different identifiers for the tag and
the typedef? There are probably some reasons to do that, but *if*
you're going to use typedefs, it's simpler to write:

typedef struct T { ... } T;

>> Most "named user types" are structs.
>
> Apart from off_t, clock_t and friends!

As I wrote, and you snipped (emphasis added):

Most "named user types" are structs. I use a consistent naming
scheme for them. I don't give separate names to pointer or array
types, **and most named integer types that I use are defined in
standard or system headers**.

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

On 28/07/2021 15:06, Scott Lurndal wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Bart <bc@freeuk.com> writes:
>>> On 27/07/2021 23:12, Scott Lurndal wrote:
>> [...]
>
>>
>>> Some integer types will depend on the target so, fine, use special
>>> types for those (size_t and intptr_t for example). But DON'T have a
>>> dedicated integer typedef for every field of every struct!
>>> Declarations like this are a joke:
>>>
>>> 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 */
>>> };
>>
>> Would you insist on using the [u]intN_t types for all those members?
>
> We learned thirty years ago that using sized integer types instead
> of abstract types in struct stat (and other application<->OS APIs)
> was a very, very, very, very bad idea.
>
> Bart has this bugaboo about having to track down the final definitions
> of these abstract types, which is, frankly, ridiculous and short-sighted.
>
> In any case, a simple gcc -E will provide the exact line and exact
> source file name for any abstract type defined by the implementation
> easily and simply.
>
> $ (cd ~; cc -E a.c | grep ino_t)
> typedef unsigned long int __ino_t;
> typedef __ino_t ino_t;
> __ino_t st_ino;
>

Here's my definition of struct stat as used in stat.h for my Win64 C
compiler:

struct _stat {
unsigned int st_dev;
unsigned short st_ino;
unsigned short st_mode;
short st_nlink;
short st_uid;
short st_gid;
unsigned long st_rdev;
unsigned int st_size;
unsigned long long int st_atime;
unsigned long long int st_mtime;
unsigned long long int st_ctime;
};

This doesn't tell you exactly what short, long etc are, but neither does
you grep example.

But since this is for Windows, that specifies short, int, long, long
long as 16, 32, 32 and 64 bits respectively.

(BTW there are 2 bytes of padding between st_gid and st_rdev fields. You
can determine this by carefully counting, but only becauses the field
sizes are much easier to determine.)

Below are versions from stat.h belonging to Windows SDK. Even though
they are already specific, they still make extensive use of typedefed names!

You can imagine it's rather puzzling figuring out which one I ought to
be using, if I wanted to use some of that functions via a FFI, even
before I need to determine what the types mean.

(I wonder what the purpose of __time32_t is, if this is supposed to be a
32-bit field anyway?)

struct _stat32
{ _dev_t st_dev;
_ino_t st_ino;
unsigned short st_mode;
short st_nlink;
short st_uid;
short st_gid;
_dev_t st_rdev;
_off_t st_size;
__time32_t st_atime;
__time32_t st_mtime;
__time32_t st_ctime;
};

struct _stat32i64
{ _dev_t st_dev;
_ino_t st_ino;
unsigned short st_mode;
short st_nlink;
short st_uid;
short st_gid;
_dev_t st_rdev;
__int64 st_size;
__time32_t st_atime;
__time32_t st_mtime;
__time32_t st_ctime;
};

struct _stat64i32
{ _dev_t st_dev;
_ino_t st_ino;
unsigned short st_mode;
short st_nlink;
short st_uid;
short st_gid;
_dev_t st_rdev;
_off_t st_size;
__time64_t st_atime;
__time64_t st_mtime;
__time64_t st_ctime;
};

struct _stat64
{ _dev_t st_dev;
_ino_t st_ino;
unsigned short st_mode;
short st_nlink;
short st_uid;
short st_gid;
_dev_t st_rdev;
__int64 st_size;
__time64_t st_atime;
__time64_t st_mtime;
__time64_t st_ctime;
};

#define __stat64 _stat64 // For legacy compatibility

#if defined(_CRT_INTERNAL_NONSTDC_NAMES) && _CRT_INTERNAL_NONSTDC_NAMES
&& !defined _CRT_NO_TIME_T
struct stat
{
_dev_t st_dev;
_ino_t st_ino;
unsigned short st_mode;
short st_nlink;
short st_uid;
short st_gid;
_dev_t st_rdev;
_off_t st_size;
time_t st_atime;
time_t st_mtime;
time_t st_ctime;
};
#endif

Bart <bc@freeuk.com> writes:
>On 28/07/2021 15:06, Scott Lurndal wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Bart <bc@freeuk.com> writes:
>>>> On 27/07/2021 23:12, Scott Lurndal wrote:
>>> [...]
>>
>>>
>>>> Some integer types will depend on the target so, fine, use special
>>>> types for those (size_t and intptr_t for example). But DON'T have a
>>>> dedicated integer typedef for every field of every struct!
>>>> Declarations like this are a joke:
>>>>
>>>> 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 */
>>>> };
>>>
>>> Would you insist on using the [u]intN_t types for all those members?
>>
>> We learned thirty years ago that using sized integer types instead
>> of abstract types in struct stat (and other application<->OS APIs)
>> was a very, very, very, very bad idea.
>>
>> Bart has this bugaboo about having to track down the final definitions
>> of these abstract types, which is, frankly, ridiculous and short-sighted.
>>
>> In any case, a simple gcc -E will provide the exact line and exact
>> source file name for any abstract type defined by the implementation
>> easily and simply.
>>
>> $ (cd ~; cc -E a.c | grep ino_t)
>> typedef unsigned long int __ino_t;
>> typedef __ino_t ino_t;
>> __ino_t st_ino;
>>
>
>Here's my definition of struct stat as used in stat.h for my Win64 C
>compiler:

You are willfully ignoring what I wrote.

The point is that _nobody_ cares what the underlying type
of ino_t is.

The point is that we learned the hard way that your solution
isn't future-safe.

The point is that 'struct stat' is data structure defined
by standards that mandate the member data types.

How many customers use your Win64 C compiler for anything,
particularly for production code? How many different computer
architectures does your C compiler support?

On 28/07/2021 16:21, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:

>> Here's my definition of struct stat as used in stat.h for my Win64 C
>> compiler:
>
> You are willfully ignoring what I wrote.
>
> The point is that _nobody_ cares what the underlying type
> of ino_t is.

I do. Or more likely types such as off_t , or off64_t which are also
used in applications. (Wouldn't off_t just be i64?)

> The point is that we learned the hard way that your solution
> isn't future-safe.

It's not my language that is stuck at int = 32 bits, while everything
these days is 64 bits.

> The point is that 'struct stat' is data structure defined
> by standards that mandate the member data types.

What standards? I showed half-a-dozen different versions! Two more below...

> How many customers use your Win64 C compiler for anything,
> particularly for production code? How many different computer
> architectures does your C compiler support?

This is exactly my point. A compiler installation can exist for just one
platform. This goes for Windows compilers such as Pelles C (2 targets),
DMC, lccwin (2 targets), Tcc (2 targets).

The 2 targets in each case are Win32 and Win64. There only really need
to be two targets, in the case of struct stat, because of NOT
future-proofing sufficiently: the needs for file and volume sizes beyond
32-bit capacity were clear 30 years ago.

A product like gcc is huge (like 100,000 development files); having
dedicated definitions for a handful of system header files is
insignificant compared with the dedicated files needed for all its
various targets.

BTW here are two more struct stat definitions to add the mix, this time
from DMC (the one that ONLY needs to support Win32); ghastly isn't it?

Suppose your job is to call one of the myriad *stat() functions from a
non-C language, to find out some info about a file; you'll have your
work cut out. (Actually I don't think I ever bothered trying to call it.)

#if !defined(_STYPES)

#define _ST_FSTYPSZ 16

/* SVR4 stat */

struct stat {
dev_t st_dev;
long st_pad1[3];
ino_t st_ino;
mode_t st_mode;
nlink_t st_nlink;
uid_t st_uid;
gid_t st_gid;
dev_t st_rdev;
long st_pad2[2];
off_t st_size;
long st_pad3;
union
{
time_t st__sec;
timestruc_t st__tim;
} st_atim,
st_mtim,
st_ctim;
long st_blksize;
long st_blocks;
char st_fstype[_ST_FSTYPSZ];
int st_aclcnt;
level_t st_level;
ulong_t st_flags;
lid_t st_cmwlevel;
long st_pad4[4];
};

#define st_atime st_atim.st__sec
#define st_mtime st_mtim.st__sec
#define st_ctime st_ctim.st__sec

#else /* !defined(_STYPES) */

/* SVID 2 stat */

struct stat {
o_dev_t st_dev;
o_ino_t st_ino;
o_mode_t st_mode;
o_nlink_t st_nlink;
o_uid_t st_uid;
o_gid_t st_gid;
o_dev_t st_rdev;

off_t st_size;
time_t st_atime;
time_t st_mtime;
time_t st_ctime;
};

int __cdecl stat(const char *,struct stat *);
int __cdecl fstat(int,struct stat *);

#if !defined(_POSIX_SOURCE)
int __cdecl lstat(const char *, struct stat *);
int __cdecl mknod(const char *, mode_t, dev_t);
#endif

#endif /* !defined(_STYPES) */

Bart <bc@freeuk.com> writes:
>On 28/07/2021 16:21, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> Here's my definition of struct stat as used in stat.h for my Win64 C
>>> compiler:
>>
>> You are willfully ignoring what I wrote.
>>
>> The point is that _nobody_ cares what the underlying type
>> of ino_t is.
>
>I do. Or more likely types such as off_t , or off64_t which are also
>used in applications. (Wouldn't off_t just be i64?)

But you are a minority of one. Why should the world cater to
your whims?

(And no, it wouldn't be i64; some implementations may not support
64-bit integers, others may prefer an unsigned definition (although
in this case, posix has specific requirements that off_t be a signed
integer type). All the programmer needs to know that it is a
signed integer type.

>
>> The point is that we learned the hard way that your solution
>> isn't future-safe.
>
>It's not my language that is stuck at int = 32 bits, while everything
>these days is 64 bits.
>
>> The point is that 'struct stat' is data structure defined
>> by standards that mandate the member data types.
>
>What standards? I showed half-a-dozen different versions! Two more below...
>

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html

>
>This is exactly my point. A compiler installation can exist for just one
>platform. This goes for Windows compilers such as Pelles C (2 targets),
>DMC, lccwin (2 targets), Tcc (2 targets).

So what? Programmers generally[*] don't write code for a particular compiler or platform,
they write code to the language specification to solve some problem, which is independent
of any particular compiler implementation. Portability of C code is what
has built the internet as we know it.

And for other languages, the language provides the binding, for
example:

http://www.nongnu.org/posix90/#SEC7

[*] exceptions exist for OS, firmware and to a much lesser extent,
compiler programmers.

On 28/07/2021 18:21, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 28/07/2021 16:21, Scott Lurndal wrote:
>>> Bart <bc@freeuk.com> writes:
>>
>>>> Here's my definition of struct stat as used in stat.h for my Win64 C
>>>> compiler:
>>>
>>> You are willfully ignoring what I wrote.
>>>
>>> The point is that _nobody_ cares what the underlying type
>>> of ino_t is.
>>
>> I do. Or more likely types such as off_t , or off64_t which are also
>> used in applications. (Wouldn't off_t just be i64?)
>
> But you are a minority of one. Why should the world cater to
> your whims?

Because it makes sense? These types are long overdue for a clearout.

> (And no, it wouldn't be i64;

I meant why wouldn't off64_t be just i64. Having off64_t be uint16_t or
whatever would be perverse.

some implementations may not support
> 64-bit integers, others may prefer an unsigned definition (although
> in this case, posix has specific requirements that off_t be a signed
> integer type). All the programmer needs to know that it is a
> signed integer type.

I want to call a C function via an FFI from a language that I've
devised. The public API says one parameter type is off_t.

Which type matches that in my language? I have to choose from i8-i64 and
u8-u64.

The kind of answer I want is (a) 'It uses i64' etc; or (b) 'It uses i32
or u64 depending on platform'.

Not keeping the answer buried for decades under a dozen typedefs,
dependent on a dozen conditional macros, dependent on the C compilers
used [what C compiler? I might not have one] and hidden in include files
6 levels deep, scattered across multiple directories, to make it as hard
as possible to find out.

I think the WINAPI also defines far too many different types, but at
least they are better documented:

https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types

You can find all the information needed here, to be able to use these
types from a language that is not C.

>>
>>> The point is that we learned the hard way that your solution
>>> isn't future-safe.
>>
>> It's not my language that is stuck at int = 32 bits, while everything
>> these days is 64 bits.
>>
>>> The point is that 'struct stat' is data structure defined
>>> by standards that mandate the member data types.
>>
>> What standards? I showed half-a-dozen different versions! Two more below...
>>
>
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html

The one that comes with gcc/tdm only defines half a dozen of those (but
takes 115 lines to do so!). Others I've seen define 3 or 4.

>>
>> This is exactly my point. A compiler installation can exist for just one
>> platform. This goes for Windows compilers such as Pelles C (2 targets),
>> DMC, lccwin (2 targets), Tcc (2 targets).
>
> So what? Programmers generally[*] don't write code for a particular compiler or platform,
> they write code to the language specification to solve some problem, which is independent
> of any particular compiler implementation. Portability of C code is what
> has built the internet as we know it.
>
> And for other languages, the language provides the binding, for
> example:
>
> http://www.nongnu.org/posix90/#SEC7

This doesn't do struct stat. But supposing it did, how did /they/ pick
up the necessary information? Although they seem to have clocked that
'clock_t' is an integer type, rather than float, something else that C
prefers to keep under wraps.

Bart <bc@freeuk.com> writes:
> On 28/07/2021 18:21, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:

[...]

> I want to call a C function via an FFI from a language that I've
> devised. The public API says one parameter type is off_t.
>
> Which type matches that in my language? I have to choose from i8-i64
> and u8-u64.
>
> The kind of answer I want is (a) 'It uses i64' etc; or (b) 'It uses
> i32 or u64 depending on platform'.

POSIX says that off_t is a signed integer type.

Is there some reason that compiling and running this program on the
target system doesn't solve your problem?

#include <stdio.h>
#include <limits.h>
int main(void) {
printf("off_t is %c%zu\n",
(off_t)-1 < (off_t)0 ? 'i' : 'u',
CHAR_BIT * sizeof (off_t));
}

> Not keeping the answer buried for decades under a dozen typedefs,
> dependent on a dozen conditional macros, dependent on the C compilers
> used [what C compiler? I might not have one] and hidden in include
> files 6 levels deep, scattered across multiple directories, to make it
> as hard as possible to find out.

Yeah, you don't need to do any of that.

[...]

>>> This is exactly my point. A compiler installation can exist for just one
>>> platform. This goes for Windows compilers such as Pelles C (2 targets),
>>> DMC, lccwin (2 targets), Tcc (2 targets).
>> So what? Programmers generally[*] don't write code for a
>> particular compiler or platform,
>> they write code to the language specification to solve some problem, which is independent
>> of any particular compiler implementation. Portability of C code is what
>> has built the internet as we know it.
>> And for other languages, the language provides the binding, for
>> example:
>> http://www.nongnu.org/posix90/#SEC7
>
> This doesn't do struct stat. But supposing it did, how did /they/ pick
> up the necessary information? Although they seem to have clocked that
> 'clock_t' is an integer type, rather than float, something else that C
> prefers to keep under wraps.

POSIX says that clock_t can be either integer or floating-point. You
can use a method similar to what I wrote above to find out what it is in
a particular implementation (without reading the header files).

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

On 29/07/2021 00:07, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 28/07/2021 18:21, Scott Lurndal wrote:
>>> Bart <bc@freeuk.com> writes:
>
> [...]
>
>> I want to call a C function via an FFI from a language that I've
>> devised. The public API says one parameter type is off_t.
>>
>> Which type matches that in my language? I have to choose from i8-i64
>> and u8-u64.
>>
>> The kind of answer I want is (a) 'It uses i64' etc; or (b) 'It uses
>> i32 or u64 depending on platform'.
>
> POSIX says that off_t is a signed integer type.
>
> Is there some reason that compiling and running this program on the
> target system doesn't solve your problem?
>
> #include <stdio.h>
> #include <limits.h>
> int main(void) {
> printf("off_t is %c%zu\n",
> (off_t)-1 < (off_t)0 ? 'i' : 'u',
> CHAR_BIT * sizeof (off_t));
> }

Sure, I can do that (after fixing the code with the right includes and
avoiding %zu). But that's the trial and error approach.

In the end I might end up with a list of such types for my platform, and
what concrete types they actually are.

But, why doesn't such a list already exist anyway? It's not as though my
platform is a rare, obscure one out of hundreds; it's Windows on x64.
The other two I might be interested in are Linux on x64 and on arm64.

>>> http://www.nongnu.org/posix90/#SEC7
>>
>> This doesn't do struct stat. But supposing it did, how did /they/ pick
>> up the necessary information? Although they seem to have clocked that
>> 'clock_t' is an integer type, rather than float, something else that C
>> prefers to keep under wraps.
>
> POSIX says that clock_t can be either integer or floating-point. You
> can use a method similar to what I wrote above to find out what it is in
> a particular implementation (without reading the header files).

Actually I don't know what type Fortran is trying to represent; it might
not be clock_t; the info at that link is incomplete, and rather poor.

Bart <bc@freeuk.com> writes:
> On 29/07/2021 00:07, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 28/07/2021 18:21, Scott Lurndal wrote:
>>>> Bart <bc@freeuk.com> writes:
>> [...]
>>
>>> I want to call a C function via an FFI from a language that I've
>>> devised. The public API says one parameter type is off_t.
>>>
>>> Which type matches that in my language? I have to choose from i8-i64
>>> and u8-u64.
>>>
>>> The kind of answer I want is (a) 'It uses i64' etc; or (b) 'It uses
>>> i32 or u64 depending on platform'.
>> POSIX says that off_t is a signed integer type.
>> Is there some reason that compiling and running this program on the
>> target system doesn't solve your problem?
>> #include <stdio.h>
>> #include <limits.h>
>> int main(void) {
>> printf("off_t is %c%zu\n",
>> (off_t)-1 < (off_t)0 ? 'i' : 'u',
>> CHAR_BIT * sizeof (off_t));
>> }
>
> Sure, I can do that (after fixing the code with the right includes and
> avoiding %zu). But that's the trial and error approach.

%zu is the correct format specifier. I'm not even going to ask why
you'd want to avoid it.

Yes, I probably should have used `#include <sys/types.h>`.

No, it's not trial and error. Write the program once, compile and run
it on each platform of interest. Expand the program as needed to show
the characteristcs of all the types you're interested in. Tweak the
output any way you like to suit your purposes. Make it generate source
code in your personal language if you like.

> In the end I might end up with a list of such types for my platform,
> and what concrete types they actually are.
>
> But, why doesn't such a list already exist anyway? It's not as though
> my platform is a rare, obscure one out of hundreds; it's Windows on
> x64. The other two I might be interested in are Linux on x64 and on
> arm64.

Such a list might exist somewhere. If it doesn't, or if it's hard to
find, it's probably because not many people are interested in it.

And I've just shown you how you can generate such a list yourself, by
writing a C program that generates it.

[snip]

(I didn't look at the Fortran stuff.)

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

On 29/07/2021 03:20, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 29/07/2021 00:07, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 28/07/2021 18:21, Scott Lurndal wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>
>>>> I want to call a C function via an FFI from a language that I've
>>>> devised. The public API says one parameter type is off_t.
>>>>
>>>> Which type matches that in my language? I have to choose from i8-i64
>>>> and u8-u64.
>>>>
>>>> The kind of answer I want is (a) 'It uses i64' etc; or (b) 'It uses
>>>> i32 or u64 depending on platform'.
>>> POSIX says that off_t is a signed integer type.
>>> Is there some reason that compiling and running this program on the
>>> target system doesn't solve your problem?
>>> #include <stdio.h>
>>> #include <limits.h>
>>> int main(void) {
>>> printf("off_t is %c%zu\n",
>>> (off_t)-1 < (off_t)0 ? 'i' : 'u',
>>> CHAR_BIT * sizeof (off_t));
>>> }
>>
>> Sure, I can do that (after fixing the code with the right includes and
>> avoiding %zu). But that's the trial and error approach.
>
> %zu is the correct format specifier. I'm not even going to ask why
> you'd want to avoid it.

I'll tell you anyway: it doesn't work on Windows.

> Yes, I probably should have used `#include <sys/types.h>`.
>
> No, it's not trial and error. Write the program once, compile and run
> it on each platform of interest. Expand the program as needed to show
> the characteristcs of all the types you're interested in. Tweak the
> output any way you like to suit your purposes. Make it generate source
> code in your personal language if you like.

This is stuff I've had to do years ago. More recently, I could
semi-translate C APIs (although normally I'd exclude system headers), by
using a special option on my C compiler, which will generate a
particular rendering, as often APIs bristle with compile-specific code.

It doesn't attempt most of the macros that are normally used, which in
general contain expressions in C syntax which is not trivially convertible.

Generating FFI bindings of C APIs is a big job. Most people who have to
do similar things are not going to be writing their own C parsers or
whatever; they might have to use more heavyweight solutions, or simply
do a huge amount of work.

The off_t and other types are examples of where how C is typically
written makes it harder than necessary. Instead of using a plain type,
or even using one layer of typedefs, it uses several.

(For gcc/tdm, off_t is defined inside _mingw_off_t.h (it has its own
header!). This defines also _off_t and off32_t as 'long'; _off64_t and
off64_t; and off_t itself as either off64_t or off32_t

One clock_t type used 6 layers of typedefs and macros; what the hell
happended there? This is why I'm saying this stuff should be overhauled.
Obviously no one wants to mess with it, so they add their own
abstractions. Then someone else does the same... Eventually someone
whats to printf such a value!)

-----------------------------------------------
_mingw_off_t.h
-----------------------------------------------
#ifndef _OFF_T_DEFINED
#define _OFF_T_DEFINED
#ifndef _OFF_T_
#define _OFF_T_
typedef long _off_t;
#if !defined(NO_OLDNAMES) || defined(_POSIX)
typedef long off32_t;
#endif
#endif

#ifndef _OFF64_T_DEFINED
#define _OFF64_T_DEFINED
__MINGW_EXTENSION typedef long long _off64_t;
#if !defined(NO_OLDNAMES) || defined(_POSIX)
__MINGW_EXTENSION typedef long long off64_t;
#endif
#endif /*_OFF64_T_DEFINED */

#ifndef _FILE_OFFSET_BITS_SET_OFFT
#define _FILE_OFFSET_BITS_SET_OFFT
#if !defined(NO_OLDNAMES) || defined(_POSIX)
#if (defined(_FILE_OFFSET_BITS) && (_FILE_OFFSET_BITS == 64))
typedef off64_t off_t;
#else
typedef off32_t off_t;
#endif /* #if !defined(NO_OLDNAMES) || defined(_POSIX) */
#endif /* (defined(_FILE_OFFSET_BITS) && (_FILE_OFFSET_BITS == 64)) */
#endif /* _FILE_OFFSET_BITS_SET_OFFT */

#endif /* _OFF_T_DEFINED */
-----------------------------------------------

All to define a type which is i32 or i64; wonderful isn't it?

Let's face it, if you had to write some functions or data types that
expressed a file offset, you'd just use int64_t and be done with it.