On Thursday, 27 July 2023 at 12:34:50 UTC+1, David Brown wrote:
>
> I can't answer for Scott, but for me it could be int16_t, int32_t or
> int64_t, depending on the context - I make sure I use appropriate types
> for the calculations I need, balanced with the efficiency requirements
> on the particular target.
>
Take this code

void filter(float *out, const float *in, size_t N, const float *filter, size_t Nf)
{ mysterytype_t index;
size_t i, j;

for ( i =0; i < N; i=i++)
{
out[i] = 0.0f;
for(j = 0, index = i - Nf/2; j < Nf; j++, index++)
{
if (index < 0 || index >= N)
contiue;
out[index] += in[i] * filter[j];
}
}
}

What would you use for mysterytype_t?

On 27/07/2023 14:15, Malcolm McLean wrote:
> On Thursday, 27 July 2023 at 12:34:50 UTC+1, David Brown wrote:
>>
>> I can't answer for Scott, but for me it could be int16_t, int32_t or
>> int64_t, depending on the context - I make sure I use appropriate types
>> for the calculations I need, balanced with the efficiency requirements
>> on the particular target.
>>
> Take this code
>
> void filter(float *out, const float *in, size_t N, const float *filter, size_t Nf)
> {
> mysterytype_t index;
> size_t i, j;
>
> for ( i =0; i < N; i=i++)
> {
> out[i] = 0.0f;
> for(j = 0, index = i - Nf/2; j < Nf; j++, index++)
> {
> if (index < 0 || index >= N)
> contiue;
> out[index] += in[i] * filter[j];
> }
> }
> }
>
> What would you use for mysterytype_t?
>

I wouldn't. I'd start with index at 0, and adjust the rest of the
variables to suit. And I would not have partial filter application at
the ends of the data sample - there's no point in making the inner loop
significantly slower just to generate incorrect (potentially wildly
incorrect) and useless results there. The useful output will of size N
- Nf, not N.

If I really had to include these wrong results, I'd do them separately
from the main loop - usually with such filters, speed is important and
you want the inner loop to work neatly - with automatic SIMD processing
if the compiler and target support it.

If I /really/ had to include the wrong results, and /really/ wanted to
do them at the same time, I'd take advantage of the fact that (2N + Nf)
<= SIZE_MAX to know what types I could safely use in the arithmetic.
(If the various arrays could overlap, the algorithm would have to be
changed dramatically. Oh, and I'd remember that this is the 21st
century, and add "restrict" to the parameters.)

On 27/07/2023 12:34, David Brown wrote:
> On 26/07/2023 23:07, Bart wrote:
> /Your/ assertion was that half the existing programs would break if
> "int" were 64 bits instead of the more common 32 bits. You have failed
> to produce the slightest justification for that. It is irrelevant
> whether Scott or anyone else knows of programs that might have issues
> with such a change. And Scott did not in any way say that you were
> wrong in your claim - he just noted that you are apparently unable to
> justify it. (I, for one, have little idea if you are right or wrong
> because I am not familiar with the vast majority of C code written. I
> don't believe you know any better either - but we await your evidence.)
>

Common sense and experience ought to tell you that I'm probably right.

But what evidence exactly do you want?

Either there is going to be a big problem, or there isn't, but suppose
you need to decide whether you're going to make 'int' 64 bits. What
would /you/ do?

Do /you/ think there will be many problems with programs breaking,
because there is either a deliberate or inadvertent reliance on int
being 32 bits?

'int' is probably the most-used C type in C code.

Time to put your money on this again! Or will you just go for it
because, after all, there is no real evidence that anything will go wrong?

Note that MS probably left 'long' as 32 bits, when 'int' became 32 bits
too, for similar reasons.

(I suspect I'm the only one here who has attempted to make a C with a
64-bit int, to try it out. It didn't work, but there were many other
reasons for that.

That the C library still used 32 bits, even if I changed the APIs to
ensure that was 'int' was the 32-bit equivalent, may have been one
factor why the experiment wouldn't work unless I also recompiled the
library from source using 64-bit int.)

> I think most C programmers have come across variants and alternatives to
> "int32_t" that have much the same meaning. But these alternatives
> typically come from either:
>
> 1. Code with a history from before C99 and the <stdint.h> types.
> 2. Code written to work with pre-C99 toolchains.
> 3. Newer code referring to or using type 1 or 2 code.
> 4. Code that uses different names to distinguish types for different
> purposes, perhaps using more advanced linters to check usage in a
> stronger manner than C compilers typically support.

You're not going to be convinced are you, no matter how many examples I
might come up with!

There must always be /some other/ reason why somebody defines a new
alias on top of `int32_t`, because there's hardly going to be a comment
that says it's because they are ugly or long-winded.

BTW here's an extract from a Raylib module:

unsigned int defaultFontData[512] = {
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00200020, 0x0001b000, 0x00000000, 0x00000000,
0x8ef92520, 0x00020a00, 0x7dbe8000, 0x1f7df45f,

I guess 'int' had better be 32 bits in this case!

> I have only ever heard of one person who actively chooses some variant
> other than the <stdint.h> types such as int32_t from a free choice,
> without any particular reason or justification other than that they
> think the identifier "int32_t" is ugly. You can guess who that
person is.

If you're generating C code, then those also take up more space for no
reason. There I will use short forms like 'i32'.

(Actually, my generated C code doesn't use any standard headers, so that
`int32_t` doesn't exist, and the standard header would anyway only
define it on top of `int`.)

On Thursday, 27 July 2023 at 14:14:30 UTC+1, David Brown wrote:
> On 27/07/2023 14:15, Malcolm McLean wrote:
> > On Thursday, 27 July 2023 at 12:34:50 UTC+1, David Brown wrote:
> >>
> >> I can't answer for Scott, but for me it could be int16_t, int32_t or
> >> int64_t, depending on the context - I make sure I use appropriate types
> >> for the calculations I need, balanced with the efficiency requirements
> >> on the particular target.
> >>
> > Take this code
> >
> > void filter(float *out, const float *in, size_t N, const float *filter, size_t Nf)
> > {
> > mysterytype_t index;
> > size_t i, j;
> >
> > for ( i =0; i < N; i=i++)
> > {
> > out[i] = 0.0f;
> > for(j = 0, index = i - Nf/2; j < Nf; j++, index++)
> > {
> > if (index < 0 || index >= N)
> > contiue;
> > out[index] += in[i] * filter[j];
> > }
> > }
> > }
> >
> > What would you use for mysterytype_t?
> >
> I wouldn't. I'd start with index at 0, and adjust the rest of the
> variables to suit. And I would not have partial filter application at
> the ends of the data sample - there's no point in making the inner loop
> significantly slower just to generate incorrect (potentially wildly
> incorrect) and useless results there. The useful output will of size N
> - Nf, not N.
>
> If I really had to include these wrong results, I'd do them separately
> from the main loop - usually with such filters, speed is important and
> you want the inner loop to work neatly - with automatic SIMD processing
> if the compiler and target support it.
>
What to do with the sample edges is one of those problems which doesn't
have a good answer. Here the samples beyond the input are set to zero.
Which is often what you want.
You Fourier transform the signal if speed is a problem.

But yes, there's a lot you could do to optimise this simple filter code. But
that's not the job.
>
> If I /really/ had to include the wrong results, and /really/ wanted to
> do them at the same time, I'd take advantage of the fact that (2N + Nf)
> <= SIZE_MAX to know what types I could safely use in the arithmetic.
> (If the various arrays could overlap, the algorithm would have to be
> changed dramatically. Oh, and I'd remember that this is the 21st
> century, and add "restrict" to the parameters.)
>
But you haven't answered the question, which is a victory for Bart. There
is no type we can use for mysterytype_t which is really satisfactory.

David Brown <david.brown@hesbynett.no> writes:
>On 26/07/2023 23:07, Bart wrote:

>> >> * 64-bit ints would kick the signed overflow can much further down the
>
>(I actually agree that there would have been many advantages to making
>"int" 64-bit on 64-bit systems. But there would also have been a key
>disadvantage - it would make it very inconvenient to get 16-bit and
>32-bit types with standard C integer types.)

The concerns at the time revolved around the additional memory
required to make all 'int' (and enum, etc) 64-bit.

>
>> >
>> > I, personally, haven't experienced any issues with signed overflow;>
>> primarily because I very seldom actually use 'int' types in C or C++
>> > myself.
>>
>> OK. Think about /why/ you avoid using 'int' types, then think about
>> those who do, which is going to be in the millions. All of those, of any
>> range of skill and experience, will of course have carefully weighed the
>> pros and cons of their decisions, and will have factored in the possible
>> switch of `int` to a 64-bit type in the future.
>>
>> (I'd be curious as to what actual types you use where the problems of
>> overflow vanish, but never mind, it's going to be just another
>> belittling remark.)
>>
>
>I can't answer for Scott, but for me it could be int16_t, int32_t or
>int64_t, depending on the context - I make sure I use appropriate types
>for the calculations I need, balanced with the efficiency requirements
>on the particular target.

As I otherwise noted, I very seldom need signed integers. When I do,
I use the appropriate type based on context as you do.

On 27/07/2023 15:31, Malcolm McLean wrote:

> But you haven't answered the question, which is a victory for Bart. There
> is no type we can use for mysterytype_t which is really satisfactory.
>

If you wanted an artificial question to provoke an answer of "there is
no good answer", why not just ask for a C type that is guaranteed to
have more than 64 bits?

My answer to your question was, I think, a lot more informative - it
showed that in realistic situations when there is apparently a problem
picking a type, it is more likely that there is a problem with the code
or algorithm, or at least better ways to formulate it.

However, if you were to simply ask "what type should you use in C for 65
bits signed", there is no suitable type in standard C. You could use
common 64-bit compiler extensions such as __int128 or similar names, or
you would have to build one manually from two 64-bit integer types. But
this is nothing new or surprising to anyone.

On 27/07/2023 15:30, Bart wrote:
>
> On 27/07/2023 12:34, David Brown wrote:
> > On 26/07/2023 23:07, Bart wrote:
> > /Your/ assertion was that half the existing programs would break if
> > "int" were 64 bits instead of the more common 32 bits.  You have failed
> > to produce the slightest justification for that.  It is irrelevant
> > whether Scott or anyone else knows of programs that might have issues
> > with such a change.  And Scott did not in any way say that you were
> > wrong in your claim - he just noted that you are apparently unable to
> > justify it.  (I, for one, have little idea if you are right or wrong
> > because I am not familiar with the vast majority of C code written.  I
> > don't believe you know any better either - but we await your evidence.)
> >
>
> Common sense and experience ought to tell you that I'm probably right.
>

No, it does not. Seriously. There's a great deal of C code that
assumes "int" is at least 32-bit - for a lot of it, the assumption is
reasonable (due to other constraints, such as using Windows or *nix API
calls), and for some the code could have been more portable without such
assumptions.

However, I think it is actually rare to assume a /maximum/ size for int.

The one common case might be malloc'ing an array of int using a style of
"int * p = malloc(N * 4)" rather than "int * p = malloc(N *
sizeof(int))" or "int * p = malloc(N * sizeof(*p))".

Do over half of C programs have such allocations? I doubt it. I
certainly can't be sure, but common sense and experience suggest it is
unlikely. However, I don't have anything like a statistical basis for
claiming one way or the other.

(Maybe there are other issues that would cause programs to fail with
64-bit int.)

> But what evidence exactly do you want?
>

A link to a study or report saying "We took 1000 C programs and tried
compiling them with 64-bit int - over 50% had serious problems" would be
nice. Something other than pure gut feeling from one person.

(I haven't any doubt that /some/ programs would fail with 64-bit int.
It's the claim of more than half that is the problem.)

> Either there is going to be a big problem, or there isn't, but suppose
> you need to decide whether you're going to make 'int' 64 bits. What
> would /you/ do?
>

Clearly it's too late for existing C implementations or platforms (other
than old Cray's), so are you talking about a hypothetical new one for a
new platform with an ABI that has 64-bit int? It is, after all, the
platform ABI that determines the size of "int" - C compilers do not have
a free choice if they want to be useful.

> Do /you/ think there will be many problems with programs breaking,
> because there is either a deliberate or inadvertent reliance on int
> being 32 bits?
>

I think a lot more would break because they assume "int" is at least
32b-bit, than would break because they assume "int" is at most 32-bit or
exactly 32-bit.

> 'int' is probably the most-used C type in C code.
>
> Time to put your money on this again! Or will you just go for it
> because, after all, there is no real evidence that anything will go wrong?
>

I am not a betting man. But if I were, I would bet good money that you
would never be able to gather real evidence to your claim within a
period of, say, 5 years.

I am sure you would have no problem finding a range of examples where
64-bit int would cause trouble. But that would not prove your claim, or
even count as supporting evidence for it.

> Note that MS probably left 'long' as 32 bits, when 'int' became 32 bits
> too, for similar reasons.
>

You haven't given any reasons as to why 64-bit int could be a problem.
I gave one myself, further up - if you have others, feel free to add the
main ones.

Remember, MS could well have left "long" as 32-bit for efficiency
reasons - that would not count.

> (I suspect I'm the only one here who has attempted to make a C with a
> 64-bit int, to try it out. It didn't work, but there were many other
> reasons for that.
>
> That the C library still used 32 bits, even if I changed the APIs to
> ensure that was 'int' was the 32-bit equivalent, may have been one
> factor why the experiment wouldn't work unless I also recompiled the
> library from source using 64-bit int.)
>

You can't make "int" 32-bit in the compiler alone - it has to be part of
the ABI. That means it would be the size used in any API's on the
platform. (System libraries also count as "programs" that would need to
be recompiled with 64-bit int.)

> > I think most C programmers have come across variants and alternatives to
> > "int32_t" that have much the same meaning.  But these alternatives
> > typically come from either:
> >
> > 1. Code with a history from before C99 and the <stdint.h> types.
> > 2. Code written to work with pre-C99 toolchains.
> > 3. Newer code referring to or using type 1 or 2 code.
> > 4. Code that uses different names to distinguish types for different
> > purposes, perhaps using more advanced linters to check usage in a
> > stronger manner than C compilers typically support.
>
> You're not going to be convinced are you, no matter how many examples I
> might come up with!
>

I am reasonably sure - from common sense and experience - that what I
gave above are the main reasons for programmers to use some kind of
equivalent to "int32_t" with a different name but the same meaning. I
don't see any examples that you have listed that do not fit at least one
of these categories.

> There must always be /some other/ reason why somebody defines a new
> alias on top of `int32_t`, because there's hardly going to be a comment
> that says it's because they are ugly or long-winded.

Yes, I think that is usually the case. I don't suggest that everyone
thinks "int32_t" is particularly "pretty", but I do think that few
people care enough to use a different name solely because they find it
ugly or want to save a couple of keypresses. I have seen no
justification that anyone other than /you/ thinks this way.

>
> BTW here's an extract from a Raylib module:
>
>   unsigned int defaultFontData[512] = {
>         0x00000000, 0x00000000, 0x00000000, 0x00000000,
>         0x00200020, 0x0001b000, 0x00000000, 0x00000000,
>         0x8ef92520, 0x00020a00, 0x7dbe8000, 0x1f7df45f,
>
> I guess 'int' had better be 32 bits in this case!
>

Yes, I guess so. But what do you think that proves?

If the file had started with:

#include <stdint.h>

// uint32_t is just so horribly ugly and long-winded
// that I can't bear to use it in my coding
typedef uint32_t uint32;

and then later written:

uint32 defaultFontData[512] = ...

then I would accept that you are not alone in your opinions. But that's
not what your example shows - it merely shows the well-known fact that a
lot of code assumes "int" is at least 32-bit. (It does not show that it
assumes "int" is /exactly/ 32-bit.)

>
>
> > I have only ever heard of one person who actively chooses some variant
> > other than the <stdint.h> types such as int32_t from a free choice,
> > without any particular reason or justification other than that they
> > think the identifier "int32_t" is ugly.  You can guess who that
> person is.
>
> If you're generating C code, then those also take up more space for no
> reason. There I will use short forms like 'i32'.
>

That would be saving space for no reason. But we already know you have
unusual ideas about what is important to you in your generated code, and
things like portability and use of standard types means nothing to you.

> (Actually, my generated C code doesn't use any standard headers, so that
> `int32_t` doesn't exist, and the standard header would anyway only
> define it on top of `int`.)
>
>

On Thursday, 27 July 2023 at 15:17:33 UTC+1, David Brown wrote:
> On 27/07/2023 15:31, Malcolm McLean wrote:
>
> > But you haven't answered the question, which is a victory for Bart. There
> > is no type we can use for mysterytype_t which is really satisfactory.
> >
> If you wanted an artificial question to provoke an answer of "there is
> no good answer", why not just ask for a C type that is guaranteed to
> have more than 64 bits?
>
> My answer to your question was, I think, a lot more informative - it
> showed that in realistic situations when there is apparently a problem
> picking a type, it is more likely that there is a problem with the code
> or algorithm, or at least better ways to formulate it.
>
You can always code round problems. So if you are banned from using
signed types, there are ways and means of writing code so that you can
still obtain correct answer, even if the straightforwards thing to do would
be to generate a negative integer. But there's basically nothing wrong
with the filter code. It's not terribly efficient, but in a lot of contexts,
that doesn't matter, and it's far preferable to have simple code which
can be easily checked, and written very quickly, rather than a complicated
solution.
>
> However, if you were to simply ask "what type should you use in C for 65
> bits signed", there is no suitable type in standard C. You could use
> common 64-bit compiler extensions such as __int128 or similar names, or
> you would have to build one manually from two 64-bit integer types. But
> this is nothing new or surprising to anyone.
>
It's quite likely that size_t is 64 bits. If size_t is 32 bits, it's just possible that
the sample size plus the filter size overflows a size_t (it would have to be
an odd architecture with non-flat memory spaces). If we make index an
int64_t then we are safe. But it's slow. However you can argue that since
the function is slower than it needs to be anyway, a bit of a further slowdown
won't hurt.

On 27/07/2023 15:07, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 26/07/2023 23:07, Bart wrote:
>
>>> >> * 64-bit ints would kick the signed overflow can much further
down the
>>
>> (I actually agree that there would have been many advantages to making
>> "int" 64-bit on 64-bit systems. But there would also have been a key
>> disadvantage - it would make it very inconvenient to get 16-bit and
>> 32-bit types with standard C integer types.)
>
> The concerns at the time revolved around the additional memory
> required to make all 'int' (and enum, etc) 64-bit.

An enum name is just a named constant. It doesn't take up any more space
than is needed.

If you mean the space needed when used as a variable's type like this:

enum {x, y, z} c[1000];

where `c` occupies 4000 bytes, then you can equally say that it wastes
2000 or 3000 bytes given that you only need a byte to represent the
values of x, y, z.

Is there no way of overriding the type in C? (Other than just using an
8- or 16-bit type anyway as I do.)

Otherwise there is no real issue with space, not for standalone
variables. Bear in that registers and stacks will be 64 bits anyway.

For the most efficient arrays and structs, people can use narrower ints
as needed, even for individual variables if worried about a few extra bytes.

The only problem I've found is specific to x64, since 64-bit versions of
many instruction encodings often need an extra byte compared to the
32-bit version (due to needing the W-bit set in the REX prefix).

But even here, the language could be designed so that 32-bit operands of
a binary op are not automatically promoted to the full 64 bits.

However that is not how C works, and not how mine works now (versions of
it for Z80 for example, which came up in another thread, did not promote
8-bit operands to 16-bits).

On 27/07/2023 15:48, David Brown wrote:
> On 27/07/2023 15:30, Bart wrote:
>>
>> Note that MS probably left 'long' as 32 bits, when 'int' became 32
>> bits too, for similar reasons.
>>
>
> You haven't given any reasons as to why 64-bit int could be a problem. I
> gave one myself, further up - if you have others, feel free to add the
> main ones.

It either won't work, or will result in programs that are not as
efficient as expected, because that tightly crafted struct now takes up
16 bytes rather than 8 (and on Win64 is passed by reference rather than
by value):

struct {
int a;
char b,c,e,f;
} S;

> You can't make "int" 32-bit in the compiler alone - it has to be part of
> the ABI.

The ABI is nothing to do with it. 'int' is a label used in many
programming languages where it has a meaning specific to those languages.

The main Win64 ABI reference doesn't assign type names to the
1-2-4-8-byte sizes that are passed in GP registers, but where it does,
then C's 'int' is a minor part of it:

https://learn.microsoft.com/en-us/cpp/build/x64-software-conventions?view=msvc-170

Because, when you think about it, when language A wants to call language
B via an FFI, C doesn't come into it at all. Neither A nor B might even
have a type called 'int'.

The compilers of both A and B need to know where to put objects of a
certain size when making function calls using the FFI.

>> You're not going to be convinced are you, no matter how many examples
>> I might come up with!
>>
>
> I am reasonably sure - from common sense and experience - that what I
> gave above are the main reasons for programmers to use some kind of
> equivalent to "int32_t" with a different name but the same meaning. I
> don't see any examples that you have listed that do not fit at least one
> of these categories.
>
>> There must always be /some other/ reason why somebody defines a new
>> alias on top of `int32_t`, because there's hardly going to be a
>> comment that says it's because they are ugly or long-winded.
>
> Yes, I think that is usually the case. I don't suggest that everyone
> thinks "int32_t" is particularly "pretty", but I do think that few
> people care enough to use a different name solely because they find it
> ugly or want to save a couple of keypresses. I have seen no
> justification that anyone other than /you/ thinks this way.

I have seen plenty of open source examples that precisely use typedefs
to define i32 etc on top of the stdint.h types. Or maybe they're Rust or
Zig programmers forced to write some C, and want to feel at home.

But I'm not going to spend days trawling through 1000s of sites I've
visited to try and find those examples.

See, however, pages like this:

https://stackoverflow.com/questions/3340843/why-do-c-programmers-use-typedefs-to-rename-basic-types

Or this:

https://stackoverflow.com/questions/30896489/why-is-u8-u16-u32-u64-used-instead-of-unsigned-int-in-kernel-programming

This one might help explain why C99 went with uint32_t instead of u32,
but you will at least think about why they used such a short type name
in that software, and not have have few letters, some underscores, and a
pointless suffix that you see in NO other langauges.

As I said, you will not be convinced, or will say it's a one-off. (Why
won't you be convinced? Is it that inconceivable that someone might
prefer a snappier, possibly more euphonious set of types for their coding?)

>> BTW here's an extract from a Raylib module:
>>
>> unsigned int defaultFontData[512] = {
>> 0x00000000, 0x00000000, 0x00000000, 0x00000000,
>> 0x00200020, 0x0001b000, 0x00000000, 0x00000000,
>> 0x8ef92520, 0x00020a00, 0x7dbe8000, 0x1f7df45f,
>>
>> I guess 'int' had better be 32 bits in this case!
>>
>
> Yes, I guess so. But what do you think that proves?

This is the conversation from a week ago where people had a go at me for
assuming int = 32 bits, but EVERYONE does it in the real word.

BTW, if `int` was to changed to 64 bits, this table would be double the
size needed.

>> If you're generating C code, then those also take up more space for no
>> reason. There I will use short forms like 'i32'.
>>
>
> That would be saving space for no reason.

Fine, I'll start using `unsigned long long int` then instead of `u64`!
It takes 1% longer to generate, takes 1% more disk space, and takes 1%
bit longer longer to parse, but that's OK.

BTW 1% is also the UK's contribution to global warming, where it is
considered a big deal.

In my generated code, casts involving these types are used VERY
extensively. For example, every `0` constant is written as `(i64)0`.

> But we already know you have
> unusual ideas about what is important to you in your generated code, and
> things like portability

I'm the one who used to test generated code across across 6 compilers,
remember, and that was just the Windows versions.

> and use of standard types means nothing to you.

It's generated code, who cares?! The file starts off like this, using
STANDARD TYPES:

typedef signed char i8;
typedef short i16;
typedef int i32;
typedef long long i64;

typedef unsigned char u8;
typedef unsigned short u16;
typedef unsigned int u32;
typedef unsigned long long u64;

typedef unsigned char byte;

typedef float r32;
typedef double r64;

I do have to inspect the code from time to type when things go wrong,
and these forms suit me.

Have you never used a typedef to create an alias for a numeric type? If
not, then what on earth is typedef for? It can't be solely for
simplifying complicated type specs.

On Thursday, 27 July 2023 at 17:18:36 UTC+1, Bart wrote:
>
> It's generated code, who cares?! The file starts off like this, using
> STANDARD TYPES:
>
> typedef signed char i8;
> typedef short i16;
> typedef int i32;
> typedef long long i64;
>
> typedef unsigned char u8;
> typedef unsigned short u16;
> typedef unsigned int u32;
> typedef unsigned long long u64;
>
> typedef unsigned char byte;
>
> typedef float r32;
> typedef double r64;
>
> I do have to inspect the code from time to type when things go wrong,
> and these forms suit me.
>
> Have you never used a typedef to create an alias for a numeric type? If
> not, then what on earth is typedef for? It can't be solely for
> simplifying complicated type specs.
>
I'm very unwilling to do this.
If we say typedef double real; is that meant to mean that the code should still
work if we replace double with float? Is this tested? Or does it mean that for
some reason we must have 64 bit floating point numbers? Or is it just that
someone thinks that "real" is a more informative nane for a type than "double"?

Then what is the scope of this symbol. What business has a graphics library, for example,
in exporting an identifier like "real"?

On 2023-07-27, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> You can argue that char *str = "123" is not a string of letters because digits
> are not letters, and if you were using the term normally then that's what you
> might mean. But I'm using "of letters" as a drop-in for "literal", to show you
> that that's what it means. "Litera", Latin "letter" so "literal", "of letters".

JulyTheTwentySeventhTwentyTwentyThreeFromManOfLettersToMalcolmMacLeanDearMalcolmCouldYouExplainTheJokeInYourPreviousLetterItWentOverMyHead

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

On 27/07/2023 17:45, Malcolm McLean wrote:
> On Thursday, 27 July 2023 at 17:18:36 UTC+1, Bart wrote:
>>
>> It's generated code, who cares?! The file starts off like this, using
>> STANDARD TYPES:
>>
>> typedef signed char i8;
>> typedef short i16;
>> typedef int i32;
>> typedef long long i64;
>>
>> typedef unsigned char u8;
>> typedef unsigned short u16;
>> typedef unsigned int u32;
>> typedef unsigned long long u64;
>>
>> typedef unsigned char byte;
>>
>> typedef float r32;
>> typedef double r64;
>>
>> I do have to inspect the code from time to type when things go wrong,
>> and these forms suit me.
>>
>> Have you never used a typedef to create an alias for a numeric type? If
>> not, then what on earth is typedef for? It can't be solely for
>> simplifying complicated type specs.
>>
> I'm very unwilling to do this.
> If we say typedef double real; is that meant to mean that the code
should still
> work if we replace double with float?

What if you replaced double with float anyway; what has that got to do
with that typedef?

Note that the example above comes from generated code; the scope is
purely the extent of that source file.

However, if I see these types in an API (presumably with some matching
typedefs nearby), I wouldn't have a problem with them at all.

> Is this tested? Or does it mean that for
> some reason we must have 64 bit floating point numbers? Or is it just
that
> someone thinks that "real" is a more informative nane for a type than
"double"?

Is it for other people's use or your own? I wouldn't use 'real' in an
API I expect other people to use; I'd use something like f64 or float32.

But what on earth are `float` and `double` anyway? They are /probably/
f32 and f64, but I'm sure the C standard does not define them as clearly
as that!

> Then what is the scope of this symbol. What business has a graphics
library, for example,
> in exporting an identifier like "real"?

I gave an example last week where each of OpenGL, GTK an SDL used their
own typedefs for integer types. 'real' would be too obscure for that
purpose.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Wednesday, 26 July 2023 at 21:19:55 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > On Wednesday, 26 July 2023 at 05:09:22 UTC+1, Keith Thompson wrote:
>> >> Tim Rentsch <tr.1...@z991.linuxsc.com> writes:
>> >> > Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>> >> [...]
>> >> >> Yes, C++ calls them literals. But that site does use the same
>> >> >> terminology as the C standard when talking about C:
>> >> >>
>> >> >> https://en.cppreference.com/w/c/language/integer_constant
>> >> >>
>> >> >> I prefer C++'s usage, since "integer constant" can be so easily
>> >> >> confused for "integer constant expression".
>> >> >
>> >> > Using the same term for both suggests a false equivalence, and
>> >> > also is ahistorical. The two kinds of entities are fundamentally
>> >> > different: constants denote values, literals denote objects.
>> >> > Constants, like mathematical constants, always denote the same
>> >> > value; literals denote different objects at different times or
>> >> > places, even if the values used to produce a given literal are
>> >> > always the same, which they need not be. The distinctions are
>> >> > too important to gloss over by using a common term for both.
>> >> When you say that "literals denote objects", are you referring
>> >> specifically to the way C uses the terms "string literal" and "compound
>> >> literal"?
>> >>
>> >> I haven't done an exhaustive search, but every language other than C
>> >> whose documentation I've just checked (C++, Ada, Perl, Python, Go, Java)
>> >> calls 42 an integer literal and "foo" a string literal. C is a bit of
>> >> an outlier in callling 42 an integer constant.
>> >>
>> >> I suggest that the fact that C uses "constant" for tokens that refer to
>> >> values and "literal" (string or compound) for constructs that refer to
>> >> anonymous objects was an arbitrary choice, and the distinction you
>> >> mention is not nearly as fundamental as you suggest it is.
>> >>
>> >> I do prefer to use the term "integer constant" when discussing C, but
>> >> the phrase "integer literal" is (a) correct in most other languages and
>> >> (b) perfectly clear. It wouldn't occur to me that "integer literal"
>> >> implies something that refers to an object.
>> >>
>> > The word "literal" means "of letters". So in this case C has it right, the
>> > other languages have it wrong.
>> If you are going be so literal, you need to explain how "" (in C) is "of
>> letters". And, since you presumably consider "123" to be "of letters",
>> why calling 123 an "integer literal" would be wrong. Anyway, technical
>> uses of words like literal are almost always figurative!
>>
> C source is human-readable. So in a sense, everything in the source
> code is "literal". So in the statement int x = 123; we can say that
> "123" is a "literal" if we want. But only if we also accept that
> "int", "x" and "=" are also "literals".

What a silly thing to say. We are entitled to use words in helpful
ways. We are not forced by naive etymology to give up a useful term
that is widely accepted and has a long history. I will continue to
refer to things like 123 as literals (though I do try to avoid that
usage when talking about C) without feeling any obligation follow your
notion of what we must accept.

--
Ben.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> Take this code

Is this obviously not real code. That does not normally matter, but I
think you've ended up with something that can't illustrate the problem
you have in mind.

> void filter(float *out, const float *in, size_t N, const float *filter, size_t Nf)
> {
> mysterytype_t index;
> size_t i, j;
>
> for ( i =0; i < N; i=i++)

The assignment to i is UB. Looks like a typo for either i=i+1 or i++.

> {
> out[i] = 0.0f;
> for(j = 0, index = i - Nf/2; j < Nf; j++, index++)
> {
> if (index < 0 || index >= N)

Here, it looks like index is supposed to be a signed type, but it gets
assigned a value with (probable) unsigned type (i - Nf/2) and is only
ever incremented.

> contiue;

typo

> out[index] += in[i] * filter[j];
> }
> }
> }
>
> What would you use for mysterytype_t?

As the code stands (with the typos corrected) an unsigned type like
size_t would work, but I don't think that's what you were asking.
Something is wrong in the rest of the code.

--
Ben.

Bart <bc@freeuk.com> writes:
[...]
> (I suspect I'm the only one here who has attempted to make a C with a
> 64-bit int, to try it out. It didn't work, but there were many other
> reasons for that.

I've worked on implementations with 64-bit int. One such system had
8-bit char and 64-bit short, int, and long. Another had 8-bit char,
32-bit short, and 64-bit int and long. I worked with C and C++ code
running under a Unix-based OS, though I was not a direct author of
maintainer of that code. I don't recall any problems due to int being
wider than 32 bits. There may well have been some problems that I
wasn't aware of. (The systems were Cray vector computers.)

As you know, making int 64 bits is a choice of an implementation, not a
change to the language. Making char 8 bits and int 64 bits means that
you can't have predefined 16-bit and 32-bit integer types (short can be
one or the other, or neither). That, I speculate, is part of the reason
modern 64-bit systems tend to have 32-bit int.

> That the C library still used 32 bits, even if I changed the APIs to
> ensure that was 'int' was the 32-bit equivalent, may have been one
> factor why the experiment wouldn't work unless I also recompiled the
> library from source using 64-bit int.)

If you change int to 64 bits for user code and leave it as 32 bits in
the API and standard library, *of course* you're going to break things.

(It would be interesting to have, say, a Linux x86_64 distribution with
64-bit int. CHAR_BIT > 8 would also be interesting, but that would
violate POSIX.)

[...]

> BTW here's an extract from a Raylib module:
>
> unsigned int defaultFontData[512] = {
> 0x00000000, 0x00000000, 0x00000000, 0x00000000,
> 0x00200020, 0x0001b000, 0x00000000, 0x00000000,
> 0x8ef92520, 0x00020a00, 0x7dbe8000, 0x1f7df45f,
>
> I guess 'int' had better be 32 bits in this case!

Certainly int would have to be *at least* 32 bits wide for that
declaration to be valid. Taking a look at the source code (see, for
example, src/rcore.c lines 201-210), it requires either _WIN32 or POSIX,
which guarantees that int is at least 32 bits.

I haven't studied the code closely enough to know whether it would work
with a 64-bit int.

Have you?

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

David Brown <david.brown@hesbynett.no> writes:

> (Lack of time means I am afraid I must cut this short, and I don't expect
> to post again for a couple of weeks. It has been an enjoyable discussion.
> Next time I will try to arm myself with references and examples first, and
> then express myself a bit better!)

I'm going to wrap this up too. I always find it interesting when
there's a disagreement about stuff like this, but although I could say
more, I don't think there much more to be gained.

--
Ben.

On 27/07/2023 21:13, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> (I suspect I'm the only one here who has attempted to make a C with a
>> 64-bit int, to try it out. It didn't work, but there were many other
>> reasons for that.
>
> I've worked on implementations with 64-bit int. One such system had
> 8-bit char and 64-bit short, int, and long. Another had 8-bit char,
> 32-bit short, and 64-bit int and long. I worked with C and C++ code
> running under a Unix-based OS, though I was not a direct author of
> maintainer of that code. I don't recall any problems due to int being
> wider than 32 bits. There may well have been some problems that I
> wasn't aware of. (The systems were Cray vector computers.)

I was thinking of a more contemporary scenario, one where there are
billions of lines of existing code that may have assume a certain 'int'
size that would be put to the test.

A large proportion of which would not have been written by the sort of
exacting programmers who would have been allowed near 1970s supercomputers.

> As you know, making int 64 bits is a choice of an implementation, not a
> change to the language. Making char 8 bits and int 64 bits means that
> you can't have predefined 16-bit and 32-bit integer types (short can be
> one or the other, or neither). That, I speculate, is part of the reason
> modern 64-bit systems tend to have 32-bit int.

So you only have 'short' to select between 16-bit and 32-bit ints? I
admit that can be a bit of quandry, but surely it is a ridiculous reason
to deny language users a proper 64-bit type!

>> BTW here's an extract from a Raylib module:
>>
>> unsigned int defaultFontData[512] = {
>> 0x00000000, 0x00000000, 0x00000000, 0x00000000,
>> 0x00200020, 0x0001b000, 0x00000000, 0x00000000,
>> 0x8ef92520, 0x00020a00, 0x7dbe8000, 0x1f7df45f,
>>
>> I guess 'int' had better be 32 bits in this case!
>
> Certainly int would have to be *at least* 32 bits wide for that
> declaration to be valid. Taking a look at the source code (see, for
> example, src/rcore.c lines 201-210), it requires either _WIN32 or POSIX,
> which guarantees that int is at least 32 bits.
>
> I haven't studied the code closely enough to know whether it would work
> with a 64-bit int.

My interest in it is purely due to being routinely castigated for
assuming that 'int' these days is typically 32 bits in size for most
developers.

But presumably such an assumption is OK when everyone else does it.

So does POSIX not work on any 16-bit UNIX systems where 'int' might be
16 bits?

My assertion is that most involved with software development are using
the kinds of machines that Raylib runs on, and those using C will likely
be using a 32-bit 'int'.

It makes sense then to assume that in discussions, and to only bring up
the pedantic fact that the C standard, which has to cater for obsolete
and unusual systems, defines only a minimum 16-bit size, when it's
relevant. And not use that to browbeat people with.

But it is also those very assumptions which lead me to /speculate/ that
suddenly making 'int' and '123' be 64 bits overnight would not end well.

> Have you?

I have used 64-bit ints in my everyday language for a decade. So I am
sensitive to the exact types used within arrays and structs since just
blindly using `int` could easily make them inefficient, since it means 4
extra bytes on top of 2-3 extra when 32-bit int is already overkill.

But to answer your question, no I haven't looked at it. However I /have/
worked extensively decades ago with just such bitmapped character glyph
data, and having the wrong stride between elements could easily cause
significant problems.

Bart <bc@freeuk.com> writes:
> On 27/07/2023 21:13, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> (I suspect I'm the only one here who has attempted to make a C with a
>>> 64-bit int, to try it out. It didn't work, but there were many other
>>> reasons for that.
>>
>> I've worked on implementations with 64-bit int. One such system had
>> 8-bit char and 64-bit short, int, and long. Another had 8-bit char,
>> 32-bit short, and 64-bit int and long. I worked with C and C++ code
>> running under a Unix-based OS, though I was not a direct author of
>> maintainer of that code. I don't recall any problems due to int being
>> wider than 32 bits. There may well have been some problems that I
>> wasn't aware of. (The systems were Cray vector computers.)
>
> I was thinking of a more contemporary scenario, one where there are
> billions of lines of existing code that may have assume a certain
> 'int' size that would be put to the test.
>
> A large proportion of which would not have been written by the sort of
> exacting programmers who would have been allowed near 1970s
> supercomputers.

The systems in question ran Unicos, Cray's version of Unix. The system
included the usual Unix software. Presumably programmers working for
Cray would have ported it to those systems; the original authors likely
didn't have access to such systems. I have no idea how much effort was
required to port it. Much of it might have just had to be recompiled.

>> As you know, making int 64 bits is a choice of an implementation, not a
>> change to the language. Making char 8 bits and int 64 bits means that
>> you can't have predefined 16-bit and 32-bit integer types (short can be
>> one or the other, or neither). That, I speculate, is part of the reason
>> modern 64-bit systems tend to have 32-bit int.
>
> So you only have 'short' to select between 16-bit and 32-bit ints? I
> admit that can be a bit of quandry, but surely it is a ridiculous
> reason to deny language users a proper 64-bit type!

C has required support for at least 64-bit integers since C99. (Yes, I
know you're offended by the fact that int is not typically 64 bits.)

[...]

> My interest in it is purely due to being routinely castigated for
> assuming that 'int' these days is typically 32 bits in size for most
> developers.

I don't recall anyone castigating you for that. I believe you've been
criticized for saying, without qualification, that int is 32 bits, and
you react badly when anyone points out that the language doesn't
guarantee it.

In this thread, you've talked about changing int from 32 to 64 bits *as
if it were a change to the language*.

[...]

> So does POSIX not work on any 16-bit UNIX systems where 'int' might be
> 16 bits?

POSIX requires INT_MAX to be at least 2147483647 and INT_MIN to be at
most -2147483647. (I think that originated in Issue 5, 1997.) Any C
implementation that does not meet that requirement does not conform to
the current version of POSIX. I'm not aware of any current UNIX-like
systems with 16-bit int; there may be some for small embedded systems.

Perhaps what you're getting at is that the original PDP-11 UNIX would
not conform to POSIX?

> My assertion is that most involved with software development are using
> the kinds of machines that Raylib runs on, and those using C will
> likely be using a 32-bit 'int'.

Most. Not all.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On Friday, 28 July 2023 at 23:35:23 UTC+1, Bart wrote:
> On 27/07/2023 21:13, Keith Thompson wrote:
> > Bart <b...@freeuk.com> writes:
> > [...]
> >> (I suspect I'm the only one here who has attempted to make a C with a
> >> 64-bit int, to try it out. It didn't work, but there were many other
> >> reasons for that.
> >
> > I've worked on implementations with 64-bit int. One such system had
> > 8-bit char and 64-bit short, int, and long. Another had 8-bit char,
> > 32-bit short, and 64-bit int and long. I worked with C and C++ code
> > running under a Unix-based OS, though I was not a direct author of
> > maintainer of that code. I don't recall any problems due to int being
> > wider than 32 bits. There may well have been some problems that I
> > wasn't aware of. (The systems were Cray vector computers.)
> I was thinking of a more contemporary scenario, one where there are
> billions of lines of existing code that may have assume a certain 'int'
> size that would be put to the test.
>
> A large proportion of which would not have been written by the sort of
> exacting programmers who would have been allowed near 1970s supercomputers.
> > As you know, making int 64 bits is a choice of an implementation, not a
> > change to the language. Making char 8 bits and int 64 bits means that
> > you can't have predefined 16-bit and 32-bit integer types (short can be
> > one or the other, or neither). That, I speculate, is part of the reason
> > modern 64-bit systems tend to have 32-bit int.
> So you only have 'short' to select between 16-bit and 32-bit ints? I
> admit that can be a bit of quandry, but surely it is a ridiculous reason
> to deny language users a proper 64-bit type!
>
You'd have to either make int32_t or similar a built in type, or you'd have to
invent an extension like "medium" . Otherwise with the rules as they are you
can have 16 bit or 32 bit shorts, but not both, and long has to be at least
as long as int.
int is the natural type to use for the number of children in a family.
int is the natural type to use for the number of employees in a company.
int is the natural type to use for the number of sound samples in an audio signal.

In the first case it is unlikely to go above ten and can't go above thirty.
In the second case it could go over 16 thousand but not over 2 billion.
In the third case it could go extremely high, but not above the capacity
of the machine to process the signal.

The first case is the most common type of data. Most integers in programs
are small. But normally iterating over children won't be. a performance
bottleneck. If we've got a 64 bit machine, we can afford the extra padding bytes.

The third case is more interesting. Iterating over audio samples could be enough
of a bottle neck that we need to use an efficient type. And a 44100 MHz stereo
sample will, break the 2 billion mark at about 8 hours. Unlikely you'd have a
sample that long, but not impossible (the movie Shoah is 9 hours 21 minutes).
However if you're going to slurp in the sundtrack to Shoah as one signal and
process it, you will certainly have a 64 bit machine. So the C system where int is
the "natural integer type to use on the machine" is ideal here.

On 29/07/2023 08:05, Malcolm McLean wrote:
> On Friday, 28 July 2023 at 23:35:23 UTC+1, Bart wrote:
>> On 27/07/2023 21:13, Keith Thompson wrote:
>>> Bart <b...@freeuk.com> writes:
>>> [...]
>>>> (I suspect I'm the only one here who has attempted to make a C with a
>>>> 64-bit int, to try it out. It didn't work, but there were many other
>>>> reasons for that.
>>>
>>> I've worked on implementations with 64-bit int. One such system had
>>> 8-bit char and 64-bit short, int, and long. Another had 8-bit char,
>>> 32-bit short, and 64-bit int and long. I worked with C and C++ code
>>> running under a Unix-based OS, though I was not a direct author of
>>> maintainer of that code. I don't recall any problems due to int being
>>> wider than 32 bits. There may well have been some problems that I
>>> wasn't aware of. (The systems were Cray vector computers.)
>> I was thinking of a more contemporary scenario, one where there are
>> billions of lines of existing code that may have assume a certain 'int'
>> size that would be put to the test.
>>
>> A large proportion of which would not have been written by the sort of
>> exacting programmers who would have been allowed near 1970s
supercomputers.
>>> As you know, making int 64 bits is a choice of an implementation, not a
>>> change to the language. Making char 8 bits and int 64 bits means that
>>> you can't have predefined 16-bit and 32-bit integer types (short can be
>>> one or the other, or neither). That, I speculate, is part of the reason
>>> modern 64-bit systems tend to have 32-bit int.
>> So you only have 'short' to select between 16-bit and 32-bit ints? I
>> admit that can be a bit of quandry, but surely it is a ridiculous reason
>> to deny language users a proper 64-bit type!
>>
> You'd have to either make int32_t or similar a built in type, or
you'd have to
> invent an extension like "medium" . Otherwise with the rules as they
are you
> can have 16 bit or 32 bit shorts, but not both, and long has to be at
least
> as long as int.

This is just bikeshedding. An acceptable solution might have been:

* Keep int as 32 bits
* Make long 64 bits across all platforms (at present only Linux 64
has that size)
* Make integer constants 64 bits
* Promote all integer types to 64 bits

In short, use 'long' for the name of the 64-bit type, similar to a a
number of other languages, AND make that the default type for constants
and evaluation.

> int is the natural type to use for the number of children in a family.
> int is the natural type to use for the number of employees in a company.
> int is the natural type to use for the number of sound samples in an
audio signal.
>
> In the first case it is unlikely to go above ten and can't go above
thirty.

Here u8 would be the natural size, if you had to represent a million
such families in a program.

> In the second case it could go over 16 thousand but not over 2 billion.
> In the third case it could go extremely high, but not above the capacity
> of the machine to process the signal.

> The first case is the most common type of data. Most integers in programs
> are small. But normally iterating over children won't be. a performance
> bottleneck. If we've got a 64 bit machine, we can afford the extra
padding bytes.
>
> The third case is more interesting. Iterating over audio samples
could be enough
> of a bottle neck that we need to use an efficient type. And a 44100
MHz stereo
> sample will, break the 2 billion mark at about 8 hours. Unlikely
you'd have a
> sample that long, but not impossible (the movie Shoah is 9 hours 21
minutes).

Yes, but now there is a realistic limit that you have to worry about.
Here, 4 extra bytes compared with the potential size of the data
(billions of 8 or 16-bit samples) is irrelevant.

> However if you're going to slurp in the sundtrack to Shoah as one
signal and
> process it, you will certainly have a 64 bit machine. So the C system
where int is
> the "natural integer type to use on the machine" is ideal here.

The default Int is predominantly used for standalone variables,
parameters, and named constants. There will be a max of a few thousand
value across a program, many of them sharing memory (as they will occupy
the same stack frame memory since only a handful of all functions are
active at any one time).

It is when you create data structures that you need to consider using
narrower types.

Now let's look at some situations where 32-bit int might not be quite
enough:

* The sizeof() of a data structure or type
* The number of bytes of memory ...
* ... or in a file
* ... or in a storage device
* ... or in a string
* The number of bits in a data structure (8 times as many bytes)
* The number of pixels in all frames of a 3 hour 60fps 4K movie (2500
billion)
* Doing calculations with 32-bit quantities
* Integer inputs from a command line
* The world population
* The age of the earth in years
* The number of milliseconds in a month
* ...

2 billion is just too narrow for comfort for many things. And in C,
integer constants have a type of `int`, so a simple calculation like
1<<33 will overflow.

With 16-bit machines, ints were 16 bits.
With 32-bit machines, ints were 32 bits.
But with 64-bit machines, ints are still 32 bits?

With 8-bit machines, you needed to think twice using 16-bit values,
since support was very limited, and inefficient. But 64-bit machines
HAVE that support, and in spades! 128-bit values become viable.

So why the reluctance to use 64-bit in C /as the default/? It's like
having a default 4-bit int on an 8-bit device.

My theory is that it would break too much code.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On Friday, 28 July 2023 at 23:35:23 UTC+1, Bart wrote:
>> On 27/07/2023 21:13, Keith Thompson wrote:
>> > Bart <b...@freeuk.com> writes:
>> > [...]
>> >> (I suspect I'm the only one here who has attempted to make a C with a
>> >> 64-bit int, to try it out. It didn't work, but there were many other
>> >> reasons for that.
>> >
>> > I've worked on implementations with 64-bit int. One such system had
>> > 8-bit char and 64-bit short, int, and long. Another had 8-bit char,
>> > 32-bit short, and 64-bit int and long. I worked with C and C++ code
>> > running under a Unix-based OS, though I was not a direct author of
>> > maintainer of that code. I don't recall any problems due to int being
>> > wider than 32 bits. There may well have been some problems that I
>> > wasn't aware of. (The systems were Cray vector computers.)
>> I was thinking of a more contemporary scenario, one where there are
>> billions of lines of existing code that may have assume a certain 'int'
>> size that would be put to the test.
>>
>> A large proportion of which would not have been written by the sort of
>> exacting programmers who would have been allowed near 1970s supercomputers.
>> > As you know, making int 64 bits is a choice of an implementation, not a
>> > change to the language. Making char 8 bits and int 64 bits means that
>> > you can't have predefined 16-bit and 32-bit integer types (short can be
>> > one or the other, or neither). That, I speculate, is part of the reason
>> > modern 64-bit systems tend to have 32-bit int.
>> So you only have 'short' to select between 16-bit and 32-bit ints? I
>> admit that can be a bit of quandry, but surely it is a ridiculous reason
>> to deny language users a proper 64-bit type!
>>
>You'd have to either make int32_t or similar a built in type, or you'd have to
>invent an extension like "medium" . Otherwise with the rules as they are you
>can have 16 bit or 32 bit shorts, but not both, and long has to be at least
>as long as int.
>int is the natural type to use for the number of children in a family.

Can a family have a negative number of children? No. 'unsigned int'
then becomes the natural type to use for the number of children in
a family. etc.

On 29/07/2023 14:47, Scott Lurndal wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On Friday, 28 July 2023 at 23:35:23 UTC+1, Bart wrote:
>>> On 27/07/2023 21:13, Keith Thompson wrote:
>>>> Bart <b...@freeuk.com> writes:
>>>> [...]
>>>>> (I suspect I'm the only one here who has attempted to make a C with a
>>>>> 64-bit int, to try it out. It didn't work, but there were many other
>>>>> reasons for that.
>>>>
>>>> I've worked on implementations with 64-bit int. One such system had
>>>> 8-bit char and 64-bit short, int, and long. Another had 8-bit char,
>>>> 32-bit short, and 64-bit int and long. I worked with C and C++ code
>>>> running under a Unix-based OS, though I was not a direct author of
>>>> maintainer of that code. I don't recall any problems due to int being
>>>> wider than 32 bits. There may well have been some problems that I
>>>> wasn't aware of. (The systems were Cray vector computers.)
>>> I was thinking of a more contemporary scenario, one where there are
>>> billions of lines of existing code that may have assume a certain 'int'
>>> size that would be put to the test.
>>>
>>> A large proportion of which would not have been written by the sort of
>>> exacting programmers who would have been allowed near 1970s supercomputers.
>>>> As you know, making int 64 bits is a choice of an implementation, not a
>>>> change to the language. Making char 8 bits and int 64 bits means that
>>>> you can't have predefined 16-bit and 32-bit integer types (short can be
>>>> one or the other, or neither). That, I speculate, is part of the reason
>>>> modern 64-bit systems tend to have 32-bit int.
>>> So you only have 'short' to select between 16-bit and 32-bit ints? I
>>> admit that can be a bit of quandry, but surely it is a ridiculous reason
>>> to deny language users a proper 64-bit type!
>>>
>> You'd have to either make int32_t or similar a built in type, or you'd have to
>> invent an extension like "medium" . Otherwise with the rules as they are you
>> can have 16 bit or 32 bit shorts, but not both, and long has to be at least
>> as long as int.
>> int is the natural type to use for the number of children in a family.
>
> Can a family have a negative number of children? No. 'unsigned int'
> then becomes the natural type to use for the number of children in
> a family. etc.
>

I'd be wary of such conclusions.

Sometimes negative values come up even for quantities that physically
cannot be zero. So I can't have a negative number of actual dollar
bills, but if I owed you $10 and only have $6, my net worth, or disposal
amount, is -$4.

Besides if I wanted to know how many more children family A has than
family B, if's quite possible that `a - b` could yield a negative value,
if B in fact has more children.

(I know I suggested `u8` (uint8_t) for this in my other post, but I
didn't want to open this can of worms. Besides, calculations with such
quantities will be done using full-width signed integers - you can have
your negative results.)

On 2023-07-29, Scott Lurndal <scott@slp53.sl.home> wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>You'd have to either make int32_t or similar a built in type, or you'd have to
>>invent an extension like "medium" . Otherwise with the rules as they are you
>>can have 16 bit or 32 bit shorts, but not both, and long has to be at least
>>as long as int.
>>int is the natural type to use for the number of children in a family.
>
> Can a family have a negative number of children? No. 'unsigned int'
> then becomes the natural type to use for the number of children in
> a family. etc.

Sure; if you don't mind problems like not being able to do basic
derivation:

a < b + c

a - c < b # subtract c from both sides

If a, b, and c are small numbers like number of children in a family,
the above holds for signed int. You can "fearlessly" refactor
inequality expressions in code.

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

Bart <bc@freeuk.com> writes:
>On 29/07/2023 14:47, Scott Lurndal wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>> On Friday, 28 July 2023 at 23:35:23 UTC+1, Bart wrote:
>>>> On 27/07/2023 21:13, Keith Thompson wrote:
>>>>> Bart <b...@freeuk.com> writes:
>>>>> [...]
>>>>>> (I suspect I'm the only one here who has attempted to make a C with a
>>>>>> 64-bit int, to try it out. It didn't work, but there were many other
>>>>>> reasons for that.
>>>>>
>>>>> I've worked on implementations with 64-bit int. One such system had
>>>>> 8-bit char and 64-bit short, int, and long. Another had 8-bit char,
>>>>> 32-bit short, and 64-bit int and long. I worked with C and C++ code
>>>>> running under a Unix-based OS, though I was not a direct author of
>>>>> maintainer of that code. I don't recall any problems due to int being
>>>>> wider than 32 bits. There may well have been some problems that I
>>>>> wasn't aware of. (The systems were Cray vector computers.)
>>>> I was thinking of a more contemporary scenario, one where there are
>>>> billions of lines of existing code that may have assume a certain 'int'
>>>> size that would be put to the test.
>>>>
>>>> A large proportion of which would not have been written by the sort of
>>>> exacting programmers who would have been allowed near 1970s supercomputers.
>>>>> As you know, making int 64 bits is a choice of an implementation, not a
>>>>> change to the language. Making char 8 bits and int 64 bits means that
>>>>> you can't have predefined 16-bit and 32-bit integer types (short can be
>>>>> one or the other, or neither). That, I speculate, is part of the reason
>>>>> modern 64-bit systems tend to have 32-bit int.
>>>> So you only have 'short' to select between 16-bit and 32-bit ints? I
>>>> admit that can be a bit of quandry, but surely it is a ridiculous reason
>>>> to deny language users a proper 64-bit type!
>>>>
>>> You'd have to either make int32_t or similar a built in type, or you'd have to
>>> invent an extension like "medium" . Otherwise with the rules as they are you
>>> can have 16 bit or 32 bit shorts, but not both, and long has to be at least
>>> as long as int.
>>> int is the natural type to use for the number of children in a family.
>>
>> Can a family have a negative number of children? No. 'unsigned int'
>> then becomes the natural type to use for the number of children in
>> a family. etc.
>>
>
>I'd be wary of such conclusions.
>
>Sometimes negative values come up even for quantities that physically
>cannot be zero. So I can't have a negative number of actual dollar
>bills, but if I owed you $10 and only have $6, my net worth, or disposal
>amount, is -$4.
>
>Besides if I wanted to know how many more children family A has than
>family B, if's quite possible that `a - b` could yield a negative value,
>if B in fact has more children.

if (a_children > b_children) x else y.