On 2021-05-10, Bart <bc@freeuk.com> 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);

I think the stdint.h material is supposed to simplify the programming
task of defining the local identifiers like u32, not necessarily to make
that practice go away.

If I were to guess, C99 was concerned with solving the gap caused by the
complete absence of these types, and code golfing their names didn't
come up as a priority.

If u32 is widely used in code, that's a good reason not to introduce it
into a standard header.

Some of these short names defined in C programs are actually macros and
not typedef names, like

#if FOO_OS
#define u32 unsigned int
#endif

Now if stdint is included and tries to define a u32 typedef, it breaks.

My code is optimized away because of your a < 0 and not because
and not because something with my operator is unexpectedly optimized.
If you strip the a < 0, everything works as intended.

On 10/05/2021 21:36, Bart wrote:
> 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.

I go to appropriate lengths to make the object code smaller and faster
as needed. I have no concern about the size of the /source/ code,
except in how it affects readability. And trying to make the source
smaller usually makes it less readable. (Which in turn makes it slower
to read, navigate and understand.)

>
> 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!
>

I think you are having some kind of brain-fart here. The size of type
names and the use of spaces in expressions does not affect the object code.

> 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.
>

It knows nothing about "u64" either. But C programmers know 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!
>

Gratuitous types, no. Useful types, yes.

From your example here, there are types like "dev_t" for holding device
type numbers, "uid_t" for user id numbers, "ino_t" for holding inode
numbers. When *nix was young and computers were small, these types were
smaller - probably 16-bit for the ids and 32-bit for the inodes. Later
as machines got bigger, perhaps 16-bit was too small for the number of
users, and uid_t was changed to 32-bit but the others stayed the same.
On kernels made for large file systems, "ino_t" might be changed to
64-bit. "time_t" was probably first 32-bit, then perhaps changed to
64-bit to avoid Y2K issues, and on some systems it is 128-bit to allow
fine resolution on time stamps.

(I may have the details wrong here, but the principle is right.)

When the different "kinds" of data are represented by different named
types, it is easy to change them independently without needing
unnecessary changes elsewhere.

This is why it /is/ a really good way to write code, and how you end up
with code that has worked for nearly 50 years for millions of
programmers. Code filled with fixed sizes directly is fine when you
only use it once on one system.

Typedefs give you a zero-cost indirection layer that (when used
appropriately) make code clearer, more portable, more flexible, and more
maintainable. That greatly outweighs the benefit of quickly knowing the
size of the types.

On 10/05/2021 18: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.

People /write/ code, and /read/ code - they rarely try to pronounce it.
If you do, then saying "int 32 tee" is quite simple and every C
programmer knows what you mean - pronouncing brackets and other syntax
is far harder.

If you think it is so difficult to type "int32_t", get a better keyboard
or do some typing exercises.

> The term for a 16 bit type is "plyte" and a 32 bit type a "dyner", but they have never
> really caught on.

Where are these terms from?

> Technically a "byte" doesn't mean "8 bits" either, as we all know
> on comp.lang.c.
>

"Byte" does not necessarily mean 8 bit, in historical contexts - as
different sizes were used long ago. ("octet" is fixed as 8-bit, and is
used in some contexts such as network protocols.) But even C
programmers know that without additional information (such as talking
about highly portable C code), "byte" can be assumed to be 8-bit, as it
is in most other contexts. On C systems where char is not 8-bit, such
as some DSPs, documentation never (IME - and I've used a couple such
DSPs) uses the term "byte" to avoid confusion.

On 10/05/2021 20:38, Malcolm McLean wrote:
> 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.
>

A joke term that pretty much no one has ever heard of, and conveys no
meaning, has advantages over a term that says simply and concisely
exactly what it means? Pray tell.

(I suppose the one advantage is that no one would have used it
previously to standardising it as a type name, so there would be no
possible conflict with older code. However, no one would have used the
identifier "uint32_t" for anything other than an unsigned 32 bit integer
type.)

On 10/05/2021 20:58, Bart wrote:

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

Do you hear that whooshing sound? It is the point of this discussion
flying way over your head. It is such a shame you would rather spend so
much effort arguing and complaining, rather than trying to understand
what others say.

No one has ever been in doubt about what you meant by "i64", etc. We
know from the context that you are not referring to "Interstate 64"
(which is a road somewhere, according to Wikipedia), or using it to mean
the Itanium architecture.

This is a C discussion group. When we talk about a concept that has a
particular technical term in C, we use that term. We talk about
"functions" - not "procedures" or "subroutines", even though we would
all know what was meant. And conversely, when we talk about
"functions", we mean C functions, not mathematical functions or wedding
receptions.

In C, there is a name for "signed integer type of exactly 64 bits" - it
is "int64_t". So use it when you are in a C discussion group. If you
start your own language group for your own language, you can pick your
own terms.

On 11/05/2021 07:07, Bonita Montero wrote:
> My code is optimized away because of your a < 0 and not because
> and not because something with my operator is unexpectedly optimized.

Your code is not "optimised away" - the compiler implements your code
exactly as it is written, according to the meaning of the language. The
extra information (from the "a < 0" and other conditional) means that
the compiler can implement /your/ code more efficiently.

> If you strip the a < 0, everything works as intended.

Everything works as intended by the source code, whether that
conditional is there or not.

Your problem is that the source code you wrote does not mean what you
intended it to mean. You made a mistake because you misunderstand the
language.

And while the particular conditional here is an artificial example,
there is a very real risk that somewhere along the line, such mistakes
in the source code will result in actual bugs in real systems. The risk
increases with the size of the program, the frequency of such mistakes,
and the abilities of development tools.

Sometimes code is throw-away - you write a quick bit of code to use
once, and "it works when I test it" is good enough. For something like
a re-usable low-level class, that is /not/ good enough. It needs to be
/designed/ correctly.

It is laughable, really, that in a class designed precisely to deal with
integer overflow in a specified manner, you have failed to deal with
integer overflow correctly - and then deny and defend your mistakes.

> Your code is not "optimised away" - the compiler implements your code
> exactly as it is written, according to the meaning of the language. ..

No, it is optimsed away because of a < 0.

> extra information (from the "a < 0" and other conditional) means that
> the compiler can implement /your/ code more efficiently.

It sees that a is < 0 and shorcuts to return.

On Tuesday, 11 May 2021 at 08:22:54 UTC+1, David Brown wrote:
> On 10/05/2021 20:38, Malcolm McLean wrote:
> > 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.
> >
> A joke term that pretty much no one has ever heard of, and conveys no
> meaning, has advantages over a term that says simply and concisely
> exactly what it means? Pray tell.
>
> (I suppose the one advantage is that no one would have used it
> previously to standardising it as a type name, so there would be no
> possible conflict with older code. However, no one would have used the
> identifier "uint32_t" for anything other than an unsigned 32 bit integer
> type.)
>
The big advantage is that these are words.

David Brown:

> if you want to use assert (I avoid it because it's effect
> typically depends on compiler or build flags) :

One can always write one's own assert that will internally
call abort(), perhaps after some nice logging.

--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]

On 11/05/2021 11:25, Anton Shepelev wrote:
> David Brown:
>
>> if you want to use assert (I avoid it because it's effect
>> typically depends on compiler or build flags) :
>
> One can always write one's own assert that will internally
> call abort(), perhaps after some nice logging.
>

Sure, but I would not call it "assert" in order to avoid confusion with
the standard macro.

On 11/05/2021 10:50, Malcolm McLean wrote:
> On Tuesday, 11 May 2021 at 08:22:54 UTC+1, David Brown wrote:
>> On 10/05/2021 20:38, Malcolm McLean wrote:
>>> 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.
>>>
>> A joke term that pretty much no one has ever heard of, and conveys no
>> meaning, has advantages over a term that says simply and concisely
>> exactly what it means? Pray tell.
>>
>> (I suppose the one advantage is that no one would have used it
>> previously to standardising it as a type name, so there would be no
>> possible conflict with older code. However, no one would have used the
>> identifier "uint32_t" for anything other than an unsigned 32 bit integer
>> type.)
>>
> The big advantage is that these are words.
>

For the same reason, we should replace all instances of the number 10 in
our code with the word "splarif", and start C code with

#define ropiq {
#define plusique }

and then use these instead of brackets. After all, even made-up words
are a big advantage over non-words, apparently.

On 11/05/2021 10:15, Bonita Montero wrote:
>> Your code is not "optimised away" - the compiler implements your code
>> exactly as it is written, according to the meaning of the language. ..
>
> No, it is optimsed away because of a < 0.
>
>> extra information (from the "a < 0" and other conditional) means that
>> the compiler can implement /your/ code more efficiently.
>
> It sees that a is < 0 and shorcuts to return.

I should have done this long ago - I give up. I have to conclude you
are unteachable.

On Tuesday, 11 May 2021 at 11:07:38 UTC+1, David Brown wrote:
> On 11/05/2021 10:50, Malcolm McLean wrote:
> > On Tuesday, 11 May 2021 at 08:22:54 UTC+1, David Brown wrote:
> >> On 10/05/2021 20:38, Malcolm McLean wrote:
> >>> 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.
> >>>
> >> A joke term that pretty much no one has ever heard of, and conveys no
> >> meaning, has advantages over a term that says simply and concisely
> >> exactly what it means? Pray tell.
> >>
> >> (I suppose the one advantage is that no one would have used it
> >> previously to standardising it as a type name, so there would be no
> >> possible conflict with older code. However, no one would have used the
> >> identifier "uint32_t" for anything other than an unsigned 32 bit integer
> >> type.)
> >>
> > The big advantage is that these are words.
> >
> For the same reason, we should replace all instances of the number 10 in
> our code with the word "splarif", and start C code with
>
> #define ropiq {
> #define plusique }
>
> and then use these instead of brackets. After all, even made-up words
> are a big advantage over non-words, apparently.
>
There's an argument for start .. end to demark blocks rather than curly brackets.
Personally I would disagree here. Deep nesting isn't really a natural language concept.
There's also an argument for not having raw literals in code. So if you want to include
the ten commandments

const char *commandments{NCOMMANDMENTS] = {"I am the Lord thy God, that
brought thee out of Egypt, out of the house of oppression ..." ...}

even though these are fixed and could never be changed to nine or eleven.

We don't have good words for 16 bit, 32 bit, and 64 bit values. "Plyte" and "dyner"
have been proposed, but they haven't caught on, largely because they were
consciously silly. It might have been a joke or it might have been an attempt to be
cutesy. If we did have accepted words they would be far preferable to uint32_t and
the like.

On 11/05/2021 12:40, Malcolm McLean wrote:
> On Tuesday, 11 May 2021 at 11:07:38 UTC+1, David Brown wrote:
>> On 11/05/2021 10:50, Malcolm McLean wrote:
>>> On Tuesday, 11 May 2021 at 08:22:54 UTC+1, David Brown wrote:
>>>> On 10/05/2021 20:38, Malcolm McLean wrote:
>>>>> 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.
>>>>>
>>>> A joke term that pretty much no one has ever heard of, and conveys no
>>>> meaning, has advantages over a term that says simply and concisely
>>>> exactly what it means? Pray tell.
>>>>
>>>> (I suppose the one advantage is that no one would have used it
>>>> previously to standardising it as a type name, so there would be no
>>>> possible conflict with older code. However, no one would have used the
>>>> identifier "uint32_t" for anything other than an unsigned 32 bit integer
>>>> type.)
>>>>
>>> The big advantage is that these are words.
>>>
>> For the same reason, we should replace all instances of the number 10 in
>> our code with the word "splarif", and start C code with
>>
>> #define ropiq {
>> #define plusique }
>>
>> and then use these instead of brackets. After all, even made-up words
>> are a big advantage over non-words, apparently.
>>
> There's an argument for start .. end to demark blocks rather than curly brackets.

But no argument for "ropiq / plusique". Just as there is an argument
(though a poor one) for "word / dword / qword" rather than "uint16_t /
uint32_t / uint64_t", but no argument for "plyte" or "dyner".

On Tuesday, 11 May 2021 at 12:10:44 UTC+1, David Brown wrote:
> On 11/05/2021 12:40, Malcolm McLean wrote:
> > On Tuesday, 11 May 2021 at 11:07:38 UTC+1, David Brown wrote:
> >> On 11/05/2021 10:50, Malcolm McLean wrote:
> >>> On Tuesday, 11 May 2021 at 08:22:54 UTC+1, David Brown wrote:
> >>>> On 10/05/2021 20:38, Malcolm McLean wrote:
> >>>>> 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.
> >>>>>
> >>>> A joke term that pretty much no one has ever heard of, and conveys no
> >>>> meaning, has advantages over a term that says simply and concisely
> >>>> exactly what it means? Pray tell.
> >>>>
> >>>> (I suppose the one advantage is that no one would have used it
> >>>> previously to standardising it as a type name, so there would be no
> >>>> possible conflict with older code. However, no one would have used the
> >>>> identifier "uint32_t" for anything other than an unsigned 32 bit integer
> >>>> type.)
> >>>>
> >>> The big advantage is that these are words.
> >>>
> >> For the same reason, we should replace all instances of the number 10 in
> >> our code with the word "splarif", and start C code with
> >>
> >> #define ropiq {
> >> #define plusique }
> >>
> >> and then use these instead of brackets. After all, even made-up words
> >> are a big advantage over non-words, apparently.
> >>
> > There's an argument for start .. end to demark blocks rather than curly brackets.
> But no argument for "ropiq / plusique". Just as there is an argument
> (though a poor one) for "word / dword / qword" rather than "uint16_t /
> uint32_t / uint64_t", but no argument for "plyte" or "dyner".
>
No, "dword" and "qword" are not "words".

On 11/05/2021 12:10, David Brown wrote:
> On 11/05/2021 12:40, Malcolm McLean wrote:

>>> #define ropiq {
>>> #define plusique }
>>>
>>> and then use these instead of brackets. After all, even made-up words
>>> are a big advantage over non-words, apparently.
>>>
>> There's an argument for start .. end to demark blocks rather than curly brackets.
>
> But no argument for "ropiq / plusique". Just as there is an argument
> (though a poor one) for "word / dword / qword" rather than "uint16_t /
> uint32_t / uint64_t", but no argument for "plyte" or "dyner".
>

unsigned long long int add3(unsigned long long int a, unsigned long
long int b, unsigned long long int c) ...

uint64_t add3(uint64_t a, uint64_t b, uint64_t c) ...

u64 add3(u64 a, u64 b, u64 c) ...

u64 add3(u64 a, b, c)

I find ergonomic design of syntax interesting. But more interesting is
some people's preference for the first two of these examples (in
particular the second), rather than the third or fourth.

The third is out because it is not standard C - you have to create your
own typedefs which is apparenly a no no (but myriad typedefs for stat
structs is fine).

The fourth is out because C doesn't have that syntax. But at least a
hypothethical preference can be expressed. C syntax /could/ have been
tweaked to allow that form, with its obvious advantages, if enough
people were more vocal.

On 11/05/2021 13:22, Malcolm McLean wrote:
> On Tuesday, 11 May 2021 at 12:10:44 UTC+1, David Brown wrote:
>> On 11/05/2021 12:40, Malcolm McLean wrote:
>>> On Tuesday, 11 May 2021 at 11:07:38 UTC+1, David Brown wrote:
>>>> On 11/05/2021 10:50, Malcolm McLean wrote:
>>>>> On Tuesday, 11 May 2021 at 08:22:54 UTC+1, David Brown wrote:
>>>>>> On 10/05/2021 20:38, Malcolm McLean wrote:
>>>>>>> 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.
>>>>>>>
>>>>>> A joke term that pretty much no one has ever heard of, and conveys no
>>>>>> meaning, has advantages over a term that says simply and concisely
>>>>>> exactly what it means? Pray tell.
>>>>>>
>>>>>> (I suppose the one advantage is that no one would have used it
>>>>>> previously to standardising it as a type name, so there would be no
>>>>>> possible conflict with older code. However, no one would have used the
>>>>>> identifier "uint32_t" for anything other than an unsigned 32 bit integer
>>>>>> type.)
>>>>>>
>>>>> The big advantage is that these are words.
>>>>>
>>>> For the same reason, we should replace all instances of the number 10 in
>>>> our code with the word "splarif", and start C code with
>>>>
>>>> #define ropiq {
>>>> #define plusique }
>>>>
>>>> and then use these instead of brackets. After all, even made-up words
>>>> are a big advantage over non-words, apparently.
>>>>
>>> There's an argument for start .. end to demark blocks rather than curly brackets.
>> But no argument for "ropiq / plusique". Just as there is an argument
>> (though a poor one) for "word / dword / qword" rather than "uint16_t /
>> uint32_t / uint64_t", but no argument for "plyte" or "dyner".
>>
> No, "dword" and "qword" are not "words".
>

Nor are "plyte" or "dyner" (at least, not in English).

On 11/05/2021 13:38, Bart wrote:
> On 11/05/2021 12:10, David Brown wrote:
>> On 11/05/2021 12:40, Malcolm McLean wrote:
>
>>>> #define ropiq {
>>>> #define plusique }
>>>>
>>>> and then use these instead of brackets. After all, even made-up words
>>>> are a big advantage over non-words, apparently.
>>>>
>>> There's an argument for start .. end to demark blocks rather than
>>> curly brackets.
>>
>> But no argument for "ropiq / plusique".  Just as there is an argument
>> (though a poor one) for "word / dword / qword" rather than "uint16_t /
>> uint32_t / uint64_t", but no argument for "plyte" or "dyner".
>>
>
>
>   unsigned long long int add3(unsigned long long int a, unsigned long
> long int b, unsigned long long int c) ...
>

Valid, but horrible.

>   uint64_t add3(uint64_t a, uint64_t b, uint64_t c) ...

Looks fine - a good balance between succinctness and explicitness.

>
>   u64 add3(u64 a, u64 b, u64 c) ...

Ugly and cryptic.

>
>   u64 add3(u64 a, b, c)

Ugly types, but allowing the type to be given once in the parameters is
not a bad idea. It would not be good in C (because of C's way of
expressing pointers - "uint64_t foo(uint64_t a, *b)" would be bad). But
for a different language in which the pointer bit is attached to the
type rather than the identifier, it would work.

>
> I find ergonomic design of syntax interesting. But more interesting is
> some people's preference for the first two of these examples (in
> particular the second), rather than the third or fourth.
>
> The third is out because it is not standard C - you have to create your
> own typedefs which is apparenly a no no (but myriad typedefs for stat
> structs is fine).

Appropriate new typedefs is fine. A typedef just to save a couple of
characters is silly. (The typedefs you see in the stat struct are not
for the stat struct - that is just a use-case for those types.)

>
> The fourth is out because C doesn't have that syntax. But at least a
> hypothethical preference can be expressed. C syntax /could/ have been
> tweaked to allow that form, with its obvious advantages, if enough
> people were more vocal.
>

It would need more than a tweak in its syntax to allow it, I think, but
I can see the convenience of:

uint64_t add3(uint64_t a, b, c);

Bart <bc@freeuk.com> writes:

> 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, [...]

No.

On 11/05/2021 13:37, Tim Rentsch wrote:
> Bart <bc@freeuk.com> writes:
>
>> 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, [...]
>
> No.

The people who package Zig disagree. My Zig installation contains no
less than 74 different stat.h files.

Although that doesn't to make them any less cryptic. I looked at one of
the larger versions (they vary from 300 bytes to 16KB), and it was still
gobbledygook. It took a while to establish that it did not contain a
struct stat definition. It was basically loads of #ifdefs and little else.

There was an '#include <bits\stat.h>', and I guessed which one of the
(97!) bits directories it was refering to, I eventually got this:

/* Structure describing file characteristics. */
struct stat
{
/* These are the members that POSIX.1 requires. */

__mode_t st_mode; /* File mode. */
#ifndef __USE_FILE_OFFSET64
__ino_t st_ino; /* File serial number. */
#else
__ino64_t st_ino; /* File serial number. */
#endif
__dev_t st_dev; /* Device containing the file. */
__nlink_t st_nlink; /* Link count. */

__uid_t st_uid; /* User ID of the file's owner. */
__gid_t st_gid; /* Group ID of the file's group. */
#ifndef __USE_FILE_OFFSET64
__off_t st_size; /* Size of file, in bytes. */
#else
__off64_t st_size; /* Size of file, in bytes. */
#endif

__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. */

/* This should be defined if there is a `st_blksize' member. */
#undef _STATBUF_ST_BLKSIZE
};

Nice. So just having typedefs is not enough; it still needs conditional
code. In that case why not make the whole thing conditional, so that
once you've established which struct stat configuration is needed, then
it will be human readable.

At the very least, take that conditional code outside of the struct, and
use proper indentation, example:

/* These are the members that POSIX.1 requires. */

#ifndef __USE_FILE_OFFSET64
struct stat
{
__mode_t st_mode; /* File mode. */
__ino_t st_ino; /* File serial number. */
__dev_t st_dev; /* Device containing the file. */
__nlink_t st_nlink; /* Link count. */

__uid_t st_uid; /* User ID of the file's owner. */
__gid_t st_gid; /* Group ID of the file's group. */
__off_t st_size; /* Size of file, in bytes. */

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

#else
struct stat
{
__mode_t st_mode; /* File mode. */
__ino64_t st_ino; /* File serial number. */
__dev_t st_dev; /* Device containing the file. */
__nlink_t st_nlink; /* Link count. */

__uid_t st_uid; /* User ID of the file's owner. */
__gid_t st_gid; /* Group ID of the file's group. */
__off64_t st_size; /* Size of file, in bytes. */

__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. */

};

#endif

(What all this stuff is doing in a Zig implementation, which is not C,
is anyone's guess. I'd been looking for an MSVS version of stat.h which
/did/ have multiple struct stat definitions in the same file.)

On 11/05/2021 13:32, David Brown wrote:
> On 11/05/2021 13:38, Bart wrote:

>>   uint64_t add3(uint64_t a, uint64_t b, uint64_t c) ...
>
> Looks fine - a good balance between succinctness and explicitness.
>
>>
>>   u64 add3(u64 a, u64 b, u64 c) ...
>
> Ugly and cryptic.

Now I know you're winding me up! What about this one then:

uint64 add3(uint64 a, uint64 b, uint64 c) ...

I've just taken out the _t; still cryptic? 'uint64' is used in several
languages, while u64 is used in Rust:

fn bill(a:u64, b:u64, c:u64) -> u64 {...}

'u64' is 'uint64_t' minus the 'int' part (you now, like you can write
'unsigned' without the 'int') and minus the '_t'.

I'm surprised actually that more languages don't decorate their types
with "_t" suffixes if it makes them less ugly!

>

>> The fourth is out because C doesn't have that syntax. But at least a
>> hypothethical preference can be expressed. C syntax /could/ have been
>> tweaked to allow that form, with its obvious advantages, if enough
>> people were more vocal.
>>
>
> It would need more than a tweak in its syntax to allow it, I think, but
> I can see the convenience of:
>
> uint64_t add3(uint64_t a, b, c);
>

This can be done in C, by allowing '*' just before the type, but it will
only work in certain contexts like parameter lists, otherwise '*' could
either start a declaration type, or an expression, so it's ambiguous.

Or you can use a keyword in its place.

(I use the following, when all parameters are pointers:

function add3(ref word a, b, c)word = ...

'word' is a synonym for u64 or 'word64' (both mean unsigned 64-bit
ints). I rarely use 'u64' for this except when the that exact width is
important. Then I will specify rather than rely on 'word's default size.

However, neither 'word' nor 'word64' would be meaningful when posting on
a public forum, as they are peculiar to may language. So I will use
'u64' as shorthand for 'unsigned 64-bit integer', whatever the forum and
whatever the language.)

On 11/05/2021 16:14, Bart wrote:
> On 11/05/2021 13:32, David Brown wrote:
>> On 11/05/2021 13:38, Bart wrote:
>
>>>    uint64_t add3(uint64_t a, uint64_t b, uint64_t c) ...
>>
>> Looks fine - a good balance between succinctness and explicitness.
>>
>>>
>>>    u64 add3(u64 a, u64 b, u64 c) ...
>>
>> Ugly and cryptic.
>
> Now I know you're winding me up!

No - honestly, I do not think these very short type names are any
improvement whatsoever. I /do/ think they are ugly, and they are /not/
standard C and thus more cryptic. I'd quickly guess what they meant, of
course - but I would also get somewhat irritated at yet another
programmer re-inventing the wheel.

> What about this one then:
>
>     uint64 add3(uint64 a, uint64 b, uint64 c) ...
>
> I've just taken out the _t; still cryptic? 'uint64' is used in several
> languages, while u64 is used in Rust:

Again, I'd know what is meant - but I'd still find the non-standard
names pointlessly jarring and I'd be left feeling the programmer doesn't
know the language.

When programming in C, I don't care what Rust uses (or any other
language, except perhaps C++ as the two are sometimes mixed in the same
program). But if I were programming in Rust and I saw someone write
"uint64_t", I would find /that/ jarring and an indication that the
programmer is mixing languages and trying to write C code in Rust.

Different languages have different typenames and conventions. It makes
sense to follow the standards of the language you are using. Anything
else is just going to irritate people for no reason.

>
>   fn bill(a:u64, b:u64, c:u64) -> u64 {...}
>
> 'u64' is 'uint64_t' minus the 'int' part (you now, like you can write
> 'unsigned' without the 'int') and minus the '_t'.
>
> I'm surprised actually that more languages don't decorate their types
> with "_t" suffixes if it makes them less ugly!
>

Ugliness is in the eye of the beholder - I can only say how they look to
/me/.

Language standards and conventions, however, are objective fact. And I
think you need /very/ good reasons for flying in the face of the
language convention. The length of typenames like uint64_t is very,
very far from being a "good" reason in my book.

There used to be a strange poster here who prefaced their files with:

#define R return
#define G goto
...

There is no doubt that "R 1;" is shorter than "return 1;". Do you think
that too means it is a good idea? If a programming language had "ret"
as its return statement, however, then "#define return ret" and using
"return" would be equally bad.

>>
>
>>> The fourth is out because C doesn't have that syntax. But at least a
>>> hypothethical preference can be expressed. C syntax /could/ have been
>>> tweaked to allow that form, with its obvious advantages, if enough
>>> people were more vocal.
>>>
>>
>> It would need more than a tweak in its syntax to allow it, I think, but
>> I can see the convenience of:
>>
>>     uint64_t add3(uint64_t a, b, c);
>>
>
>
> This can be done in C, by allowing '*' just before the type, but it will
> only work in certain contexts like parameter lists, otherwise '*' could
> either start a declaration type, or an expression, so it's ambiguous.
>
> Or you can use a keyword in its place.

Or you could use C++ and write:

template <typename T> using Pointer = T*;

Then you can use Pointer<int> instead of "int *", and it works
"naturally" when declaring multiple variables:

Pointer<int> p, q, r;

is the same as :

int *p, *q, *r;

You'd still need to change the syntax to allow :

uint64_t add3(Pointer<uint64_t> p, q);

but at least there are no annoying "*" symbols.

>
> (I use the following, when all parameters are pointers:
>
>  function add3(ref word a, b, c)word = ...
>
> 'word' is a synonym for u64 or 'word64' (both mean unsigned 64-bit
> ints). I rarely use 'u64' for this except when the that exact width is
> important. Then I will specify rather than rely on 'word's default size.
>

"word" is likely to be ambiguous unless a particular language defines it
clearly. "word64" is no worse than "u64".

> However, neither 'word' nor 'word64' would be meaningful when posting on
> a public forum, as they are peculiar to may language. So I will use
> 'u64' as shorthand for 'unsigned 64-bit integer', whatever the forum and
> whatever the language.)

I've noticed you are not particularly concerned about the language used
for forums.

Bart <bc@freeuk.com> writes:
>On 11/05/2021 13:37, Tim Rentsch wrote:

>>>
>>> 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, [...]
>>
>> No.
>
>
>The people who package Zig disagree. My Zig installation contains no
>less than 74 different stat.h files.

What is Zig? There are a lot of incompetent programmers around;
picking some random package from the internet is irrelevent to
the point that system headers are designed to maintain source
(and often even binary) compatability
forever insofar as possible. Hence abstract types whose size
can change based on target architecture or future needs without
requiring changes to the applications using the header files.

The people that matter would answer "no" to your question above.

And nobody reads system header files. They simply include them
when the API documentation tells them to. The complexity of the
header file(s) is completely irrelevent to the programmer using
the API.

On Tuesday, 11 May 2021 at 16:17:21 UTC+1, David Brown wrote:
>
> When programming in C, I don't care what Rust uses (or any other
> language, except perhaps C++ as the two are sometimes mixed in the same
> program). But if I were programming in Rust and I saw someone write
> "uint64_t", I would find /that/ jarring and an indication that the
> programmer is mixing languages and trying to write C code in Rust.
>
> Different languages have different typenames and conventions. It makes
> sense to follow the standards of the language you are using. Anything
> else is just going to irritate people for no reason.
>
However we are discussing establishing the conventions.

There are two opposed considerations. If languages all have essentially the
same syntax as each other, then it's easier to read and understand, and you don't
make irritating errors like typing "='" in Fortran when you mean "assignment"

However if two languages are essentially identical, then what is the point in them
being two languages? Really you want languages to be very different so that
there is no confusion. If in C, "int x = y + z" can overflow, whilst in whizzyscript
integers are all variable width and essentially cannot overflow, it would be better
of whizzyscript did not use "int" as a typename.