Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

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

The Crays were word addressed with specially encoded byte pointers were
they not?

I had to port some Unix (v7) utilities to a word addressed machine, and
some were really hard work. Pre-ANSI C often assumed that pointer
conversions were null operations, so if you had a

struct S *sp;

you could call f(s) and, in another file, f would pick up the pointer
like this:

f(p)
char *p;
{ ... }

(This was before void *, so char * was seen as a kind of universal
pointer for function that did general things with a pointer to any kind
of object. Not that void * would have helped much. I'm just explaining
why this sort of thing was written.)

--
Ben.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Friday, 28 July 2023 at 23:35:23 UTC+1, Bart wrote:
[...]
>> 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.

An implementation could define one or more extended integer types and
make int16_t and int32_t typedefs for those types. (Such a type could
not be called "medium"; its name would be a keyword with the form of a
reserved name like __int16_t.)

Extended integer types were introduced in C99. As far as I know, no
compiler has actually implemented them. (gcc has __int128, but it
doesn't meet the requirements of an extended integer type.)

[...]

Cray's C compilers for the T90 and SV1 had 8-bit char and 64-bit short,
int, and long. (Making char 8 bits required some extra work in the
compiler, and string manipulation was slow.) They *could* have used
some kind of extension to provide 16-bit and 32-bit integers.
Apparently they felt it wasn't worth the effort. These were specialized
machines optimized for floating-point calculations, but they were also
general-purpose Unix systems with the usual collection of text editors,
file utilities, compilers, et al. It's likely there was some software
that could not easily be ported, but any such software could be run on a
cheaper computer.

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

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> 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.
>
> The Crays were word addressed with specially encoded byte pointers were
> they not?

Yes. 64-bit pointers pointing to 64-bit words; byte pointers were
implemented in the compiler by storing a byte offset in the upper 3 bits
of a pointer.

> I had to port some Unix (v7) utilities to a word addressed machine, and
> some were really hard work. Pre-ANSI C often assumed that pointer
> conversions were null operations, so if you had a
>
> struct S *sp;
>
> you could call f(s) and, in another file, f would pick up the pointer
> like this:
>
> f(p)
> char *p;
> { ... }
>
> (This was before void *, so char * was seen as a kind of universal
> pointer for function that did general things with a pointer to any kind
> of object. Not that void * would have helped much. I'm just explaining
> why this sort of thing was written.)

In fact I ran across some code that did char pointer subtraction by
converting both pointers to integers and subtracting them. The solution
was simply to subtract the pointers directly.

(IIRC the code converted the pointers to uintptr_t, which raises doubts
about my recollection that the implementation was C90 only. Perhaps it
supported some C99 features. I don't think it had long long; if it had,
it would have been the same size as long.)

--
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 Saturday, 29 July 2023 at 22:22:56 UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> Cray's C compilers for the T90 and SV1 had 8-bit char and 64-bit short,
> int, and long. (Making char 8 bits required some extra work in the
> compiler, and string manipulation was slow.) They *could* have used
> some kind of extension to provide 16-bit and 32-bit integers.
> Apparently they felt it wasn't worth the effort. These were specialized
> machines optimized for floating-point calculations, but they were also
> general-purpose Unix systems with the usual collection of text editors,
> file utilities, compilers, et al. It's likely there was some software
> that could not easily be ported, but any such software could be run on a
> cheaper computer.
>
You don't write your novel on a Cray. But, despite what some people who
have no experience of working with supercomputers seem to think, you
do need to be able to do a bit of text file editing in situ.

On 27/07/2023 18:18, Bart wrote:
>
> 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):

Efficiency (or lack thereof) is not an issue. I would expect that
changing to 64-bit int will make some code more efficient (on 64-bit
platforms), and some code less efficient. Whether it works or not is
the crucial issue.

(I still would like to hear examples of reasonably likely situations
where changing "int" to 64-bit would stop code from working correctly.
I think we can all imagined plenty of situations where it makes code
less efficient.)

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

No, in C the size of "int" is determined by the implementation (which
includes the compiler, standard library, assembler, linker, and any
other tools needed to make an executable). Implementations need an ABI,
and almost always follow standard platform ABI's. (What the word "int"
means in other languages doesn't matter to C - different languages do
things in different ways.)

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

That says that C "int" is 32-bit for the Win64 ABI. (Calling
conventions are only part of an ABI.)

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

Yes, that is why an ABI is important.

It would certainly be possible to specify a platform ABI that does not
make any reference to C. Then you would have a C ABI for the platform
that details how C works on the platform. Then it would be this "C ABI"
that determines the size of "int" on any C toolchains for the platform.

Given the popularity of C as the common language for library interfaces
and low-level code, ABI's generally include C details. But they might
also contain specifications that are independent of C - such as types
named "INT32" and the like in the Win64 ABI. And languages A and B
could certainly refer to these type names rather than C type names when
interacting.

Other languages may not feel they need an ABI at all for determining how
they work internally, only for FFI's. But C implementations generally
do work to an ABI.

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

Other languages start from scratch, and pick names they like based on
the style of the language.

I am asking if there are any examples of others who explicitly make
typedefs like :

typedef int32_t i32;

because they think "int32_t" is too ugly or hard to type and/or read.

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

That is a standard "why do people use typedef's for sized integer
types?" question, and answered in the standard "you use it for
portability when you need specific sizes - use the C99 <stdint.h> types"
manner.

I think most people agree that prior to C99, such size-specific typedefs
were often very useful - that's not a point of contention. And your
reference here strongly recommends, as I do, using the <stdint.h> types
when you want size-specific types in C.

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

The top answer makes it clear - the Linux kernel predates C99, which is
why it does not use <stdint.h> types when it needs sized types.
(Actually, <stdint.h> types are used throughout the kernel and most
Linux code, but other size-specific type names are also used - for
historical code, or consistency with historical code, or for providing
additional information to the reader and/or linting tools.)

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

The use of a "_t" suffix for types has been traditional in C and *nix
long before C99. It seems an obvious and consistent choice to make when
the types were standardised in C99.

Other languages don't have the same history, and use type names that
match the style of those languages - sometimes longer, sometimes
shorter, sometimes imported (as in C), sometimes built-in, sometimes
with particular capitalisation, sometimes with implicit fixed sizes,
sometimes explicit sizes, sometimes sizes that vary with the platform or
target.

You seem to have this belief that /only/ C uses the style "int32_t", and
every other language uses "int32" or "i32". That's just nonsense.
Equally, you seem to believe that C99 picked this style of naming to be
awkward, or to annoy people who don't type well, or just to annoy you
personally. You also think nobody (except a few people in comp.lang.c)
likes them, or even uses them. The reality, is, of course, that it was
a considered decision based on a balance of many factors, and C
programmers the world over are entirely happy with them.

> 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?)
>

I'd find your arguments a lot more convincing if you made an attempt to
answer the question, or give justification for your opinions. We all
know of a number of good reasons why size-specific typenames other than
those in <stdint.h> are sometimes used in C programming. I listed the
main ones (as far as I see them). You have made claims that people use
different typenames (in C programming) because the <stdint.h> names are
ugly or long-winded. I have asked you to back up those claims. All I
got was a note that sometimes different names are used in different
languages (which is irrelevant), a claim that you have thousands of
examples but don't want to show any (that's hardly convincing), and a
couple of links that strongly support /my/ position, and don't come
close to supporting your ideas.

On 01/08/2023 14:00, David Brown wrote:
> On 27/07/2023 18:18, Bart wrote:
>> 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):

> Efficiency (or lack thereof) is not an issue. I would expect that
> changing to 64-bit int will make some code more efficient (on 64-bit
> platforms), and some code less efficient. Whether it works or not is
> the crucial issue.
>
> (I still would like to hear examples of reasonably likely situations
> where changing "int" to 64-bit would stop code from working correctly.

OK, let's try it. I took one of my generated C files which had these two
typedefs at the start:

typedef int i32;
typedef unsigned int u32;

I changed them to:

typedef long long i32;
typedef unsigned long long u32;

Then I recompiled the 40Kloc file (it was an interpreter) and tried to
run a script; it crashed. I can't say I was surprised: there are plenty
of unions where the relations between the elements have to be exact.

(At first I though it had worked, but I'd forgotten gcc's moronic habit
of naming output files as a.exe, so I was running prog.exe instead, an
existing working version.)

>> 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
>
> That says that C "int" is 32-bit for the Win64 ABI. (Calling
> conventions are only part of an ABI.)

It also says that a 32-bit type is called "long" and "INT32" as well as
"int".

I doubt that purpose of this chart is to define what "int" is in C, but
what is clear is that it expects it to be 32 bits. It doesn't say what
version of C it has in mind. It also doesn't mention `long long` for 64
bits, nor any of the `stdint.h` types.

> It would certainly be possible to specify a platform ABI that does not
> make any reference to C.

The main Win64 ABI page doesn't mention C or any language (only in
examples, although it calls it 'C++'):
https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170

> Other languages may not feel they need an ABI at all for determining how
> they work internally, only for FFI's. But C implementations generally
> do work to an ABI.
Mine doesn't.

>> 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.
>>
>
> Other languages start from scratch, and pick names they like based on
> the style of the language.

And they like i32 etc. They DON'T like int32_t otherwise they'd all be
using them! C users have to like it or lump it; they are not allowed to
use typedefs.

> The use of a "_t" suffix for types has been traditional in C and *nix
> long before C99. It seems an obvious and consistent choice to make when
> the types were standardised in C99.
Obviously not in the Linux kernel.
> Other languages don't have the same history, and use type names that
> match the style of those languages - sometimes longer, sometimes
> shorter, sometimes imported (as in C), sometimes built-in, sometimes
> with particular capitalisation, sometimes with implicit fixed sizes,
> sometimes explicit sizes, sometimes sizes that vary with the platform or
> target.
>
> You seem to have this belief that /only/ C uses the style "int32_t", and
> every other language uses "int32" or "i32". That's just nonsense.

I gave a list of about 10 different languages that use variations of
`int32`, `i32`, `int` (when it is a fixed 32-bit type), but none that
have anything like that funny _t suffix, and I think none where those
types are unknown to the language unless you specifically import some
module.

So which languages other than C and C++ use `int32_t`?

What would you think of C allowing people to write `char_t` and `int_t`
as well as `char` and `int`, just for consistency; do you think that
suffix brings anything to the table?

And if not, what does in bring in the case of `int32_t`? It's evident
the `_t` only existes to avoid clashing with existing uses of `int32` (I
guess there was no problem with existing uses of `int32_t`!)

> Equally, you seem to believe that C99 picked this style of naming to be
> awkward, or to annoy people who don't type well, or just to annoy you
> personally.

Not me personally. It just seems a thing with C that, terrified of
making new keywords that look good and are easy to type but that might
clash with user identifiers, they introduce capitalisation, leading and
embedded underscores, and weird suffixes to make a new keyword so ugly
that nobody would have chosen it!

> You also think nobody (except a few people in comp.lang.c)
> likes them, or even uses them. The reality, is, of course, that it was
> a considered decision based on a balance of many factors, and C
> programmers the world over are entirely happy with them.

Did they have a choice?

>> 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?)
>>
>
> I'd find your arguments a lot more convincing if you made an attempt to
> answer the question, or give justification for your opinions. We all
> know of a number of good reasons why size-specific typenames other than
> those in <stdint.h> are sometimes used in C programming.

I can't win because for every example I can find, you will bring up the
possibility that it might be linked to the availability of stdint.h or
to make it independent of stdint.h.

What would an example look like that would satisfy you that someone is
creating a snappier typedef alias for purely aesthetic, ergonomic or
other reasons than the ones you listed? How can you tell from the bare
typedef what the reason is?

> I listed the
> main ones (as far as I see them). You have made claims that people use
> different typenames (in C programming) because the <stdint.h> names are
> ugly or long-winded. I have asked you to back up those claims.

They ARE long-winded, although not as much as 'unsigned long long int`,
and they ARE ugly.

I doubt that my views are that unique. For example:

"A lot of good programmers do that and the reason given is that types in
stdint.h have ugly long names like uint32_t. "_t" thing rubs a lot of
people the wrong way so I am not surprised they change it to something
more pleasant. I like using uint64, int32 etc. but the convention where
it's u64, i32, f32, f64 is something I would get behind."

(https://news.ycombinator.com/item?id=13061837, last comment)

Note they talk about a 'convention', and 'a lot of good programmers do
that'.

>> BTW 1% is also the UK's contribution to global warming, where it is
>> considered a big deal.
>>
>
> So now you are comparing using "u64" to saving the planet.

Actually I've just measured it: using the uint64_t instead of u64 etc
made the output 6.5% bigger.

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

> First off, that is usually a silly idea.

Integer constants in the source language are 64 bits and need to be so
in the C. So, how would /you/ do it? Remember that 0L and 0LL (and 0UL
and 0ULL) do not have precisely defined widths on their types.

And in what way would that be superior to just using a cast?

On 27/07/2023 20:18, Bart wrote:
>
> On 27/07/2023 17:45, Malcolm McLean wrote:
> > On Thursday, 27 July 2023 at 17:18:36 UTC+1, Bart wrote:

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

If someone had "typedef double real;", I'd have to wonder what they
intended. A typedef is useful for making code clearer and/or easier to
modify or adapt. I can't think how the name "real" does that. But
maybe Malcolm is imagining some use I haven't thought aobut.

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

I think that sounds fine.

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

C23 has added _Float32 and _Float64 specifically as interchange formats
- they will always be in the standard IEEE formats. (If an
implementation can't support them, they won't exist as type names.) C23
also defines _Float32x and some other types, which I can't really see
the point of - but I don't work with very advanced floating point code.
Others who are much more careful about floating point details presumably
have use of these.

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

No, it is flexible and portable - not all systems use IEEE formats for
floating point. (The x86 world in particular has had a mess with the
x87 formats.) Most systems have standardised on IEEE formats now, but
sometimes internal formats are different. There are C pre-processor
macros that can be checked, and some pragmas that can be set, for
particular needs - again, I am not familiar with the details.

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

Agreed. You really want tighter specifications in an API - defining the
size and the format - not looser ones.

Bart <bc@freeuk.com> writes:
>

>(At first I though it had worked, but I'd forgotten gcc's moronic habit
>of naming output files as a.exe, so I was running prog.exe instead, an
>existing working version.)

gcc has supported the '-o' option since day one. I haven't seen a
a.out for decades. (a.exe is an artifact of whoever ported gcc to windblows).

On 01/08/2023 17:16, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>>
>
>> (At first I though it had worked, but I'd forgotten gcc's moronic habit
>> of naming output files as a.exe, so I was running prog.exe instead, an
>> existing working version.)
>
>
> gcc has supported the '-o' option since day one. I haven't seen a
> a.out for decades. (a.exe is an artifact of whoever ported gcc to
windblows).

So? You have to remember to use it, if invoking gcc in ad hoc ways from
the command line as I do. And you have to type the name of the program
twice. Either that or remember that the output is a.exe not prog.exe,
unlike other compilers.

It's a nuisance. What's more, newer compilers like Clang and Zig cc are
now having to copy that ridiculous behaviour in order to be drop-in
replacements for gcc:

gcc prog.c -oprog.exe
prog

or:

gcc prog.c
a

Compare with:

tcc prog.c (tcc on Linux still does the a.out thing)
prog

or:

bcc prog
prog

Now you want to recall that and instead compile prog2.c. With bcc you
press up-arrow twice then type "2".

With tcc you press up-arrow twice, backspace twice then type "2.c".

With gcc you press up-arrow twice, press backspace THIRTEEN times (I
think), then type "2.c -oprog2.exe". Actually, forget it; it's easier to
just type a whole new line!

See how unfriendly such a feature is? Just needing the extension is a
nuisance since you have to backspace through the extension, then restore
it, or do more fiddly editing.

On 2023-08-01, Bart <bc@freeuk.com> wrote:
> It's a nuisance. What's more, newer compilers like Clang and Zig cc are
> now having to copy that ridiculous behaviour in order to be drop-in
> replacements for gcc:
>
> gcc prog.c -oprog.exe
> prog

gcc is designed for the Unix environment. In Unix, there is a make
utility (required by POSIX) with built-in rules (also required by
POSIX in environments that support XSI extensions).

If you have a prog.c, you should be able able to build prog like this:

make prog

If you have to explicitly use gcc, you're not in the home turf.

> Now you want to recall that and instead compile prog2.c. With bcc you
> press up-arrow twice then type "2".

Up arrow recall of compiler commands is not very important in the
world of "what gets programmed with C for what purpose".

Most C programs consist of multiple files, and link libraries.

The majority of C programming ss now is embedded, where you
don't have edit-compile-run but edit-compile-uploadtotarget-run.

> See how unfriendly such a feature is? Just needing the extension is a

If you wanted friendly, why wouldn't you just use a language in which
you don't have to leave the running program at all in order to rewrite
some parts of it?

Also, do you know about shell functions and aliases?

b()
{ gcc -o $1 $1.c
}

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

On 01/08/2023 16:41, Bart wrote:
>
> On 01/08/2023 14:00, David Brown wrote:
> > On 27/07/2023 18:18, Bart wrote:
> >> 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):
>
> > Efficiency (or lack thereof) is not an issue.  I would expect that
> > changing to 64-bit int will make some code more efficient (on 64-bit
> > platforms), and some code less efficient.  Whether it works or not is
> > the crucial issue.
> >
> > (I still would like to hear examples of reasonably likely situations
> > where changing "int" to 64-bit would stop code from working correctly.
>
> OK, let's try it. I took one of my generated C files which had these two
> typedefs at the start:
>
>     typedef int                i32;
>     typedef unsigned int       u32;
>
> I changed them to:
>
>     typedef long long          i32;
>     typedef unsigned long long u32;
>
> Then I recompiled the 40Kloc file (it was an interpreter) and tried to
> run a script; it crashed. I can't say I was surprised: there are plenty
> of unions where the relations between the elements have to be exact.
>

So we have an example of one single program that has trouble when the
size-specific 32-bit type is changed to 64 bits. No one doubted that
some programs would have trouble. And I think people using a type named
"i32" would do so with a much stronger assumption about the type's size
than when using "int".

I am still waiting for a justification that /half/ the C programs in
existence would have trouble when /int/ is changed to 64 bits (no one
suggests changing int32_t). And I am still waiting for examples of what
you think (or know) is likely to go wrong.

> (At first I though it had worked, but I'd forgotten gcc's moronic habit
> of naming output files as a.exe, so I was running prog.exe instead, an
> existing working version.)
>

If only the tool came with instructions, you might have had a way to
learn after only a decade or so of use.

>
> >> 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
>
> >
> > That says that C "int" is 32-bit for the Win64 ABI.   (Calling
> > conventions are only part of an ABI.)
>
> It also says that a 32-bit type is called "long" and "INT32" as well as
> "int".
>

It says that C "long" and C "int" are both 32 bits - it does not say
they are the same type in C (they are not - even if the sizes are the same).

> I doubt that purpose of this chart is to define what "int" is in C, but
> what is clear is that it expects it to be 32 bits. It doesn't say what
> version of C it has in mind. It also doesn't mention `long long` for 64
> bits, nor any of the `stdint.h` types.
>

MS has always been famously poor at this kind of thing, and their ABI is
the least well defined of any platform I have seen.

> >
> > Other languages start from scratch, and pick names they like based on
> > the style of the language.
>
> And they like i32 etc. They DON'T like int32_t otherwise they'd all be
> using them!

As I said - languages use a style that suits the language. "int32_t"
might seem very out of place in Zig, just as "int32" might seem
inconsistent with many of the other types in C. And if you look at
other languages, you will see type names such as "Int64.int",
"INTEGER_64", "BINARY-DOUBLE SIGNED", "range -2**31 .. 2**31 - 1",
"BigInt", all according to what suits the language.

> C users have to like it or lump it; they are not allowed to
> use typedefs.

Of course they are /allowed/ to use typedefs. But silly little "typedef
int32_t int32;" typedefs are not recommended by any serious programmer
without a good reason (such as compatibility with existing code).

>
> > The use of a "_t" suffix for types has been traditional in C and *nix
> > long before C99.  It seems an obvious and consistent choice to make when
> > the types were standardised in C99.
> Obviously not in the Linux kernel.

The Linux kernel is written in C - it does not define the language.

> > Other languages don't have the same history, and use type names that
> > match the style of those languages - sometimes longer, sometimes
> > shorter, sometimes imported (as in C), sometimes built-in, sometimes
> > with particular capitalisation, sometimes with implicit fixed sizes,
> > sometimes explicit sizes, sometimes sizes that vary with the platform or
> > target.
> >
> > You seem to have this belief that /only/ C uses the style "int32_t", and
> > every other language uses "int32" or "i32".  That's just nonsense.
>
> I gave a list of about 10 different languages that use variations of
> `int32`, `i32`, `int` (when it is a fixed 32-bit type), but none that
> have anything like that funny _t suffix, and I think none where those
> types are unknown to the language unless you specifically import some
> module.

Stop cherry picking.

<https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(basic_instructions)#Integers>

Lots of languages require a module import, or equivalent, to access
size-specific types. This applies especially to higher level languages
that don't have much use for such types.

>
> So which languages other than C and C++ use `int32_t`?
>

The ones I know of are related to C (such as Objective C).

The _t suffix in C is primarily historical. I don't think it would be
likely to be useful in newer languages, without the history of C.
Different languages have different styles for this kind of thing.

I am not (and never have) argued that "int32_t" and similar is superior
to "int32". But it is definitely superior (IMHO) to minimalist names
like "i32". I am merely arguing that it is not worse - it really is not
the kind of horror story you seem to imagine, and there is no evidence
to suggest that there exists any kind of widespread dislike for the
name, either amongst C programmers or other programmers. (There is
plenty of dislike for the implementation-dependent nature of the
standard integer types in C, though often when people insist they want
fixed size types, they don't actually need them.)

> What would you think of C allowing people to write `char_t` and `int_t`
> as well as `char` and `int`, just for consistency; do you think that
> suffix brings anything to the table?
>
> And if not, what does in bring in the case of `int32_t`? It's evident
> the `_t` only existes to avoid clashing with existing uses of `int32` (I
> guess there was no problem with existing uses of `int32_t`!)
>

That is not "evident" at all. The names are only available if
<stdint.h> is included, and therefore clashes with existing names is not
an issue. Indeed, the C99 rationale describes that the names were
picked to match existing usage.

>
>
> > Equally, you seem to believe that C99 picked this style of naming to be
> > awkward, or to annoy people who don't type well, or just to annoy you
> > personally.
>
> Not me personally. It just seems a thing with C that, terrified of
> making new keywords that look good and are easy to type but that might
> clash with user identifiers, they introduce capitalisation, leading and
> embedded underscores, and weird suffixes to make a new keyword so ugly
> that nobody would have chosen it!
>

Other people view this as a professional decision to maintain
compatibility and minimise the risk of conflicts between existing code
bases and newer tools. Thus almost all keywords added to C have the
style _Keyword - precisely because words of this style were reserved for
this purpose and should not be found as user identifiers.

Note that the <stdint.h> types are /not/ keywords, and that clearly
newer C keywords and identifiers cannot be as "ugly" as you claim
because they /were/ chosen.

> >  You also think nobody (except a few people in comp.lang.c)
> > likes them, or even uses them.  The reality, is, of course, that it was
> > a considered decision based on a balance of many factors, and C
> > programmers the world over are entirely happy with them.
>
> Did they have a choice?

On 01/08/2023 18:04, Kaz Kylheku wrote:
> On 2023-08-01, Bart <bc@freeuk.com> wrote:
>> It's a nuisance. What's more, newer compilers like Clang and Zig cc are
>> now having to copy that ridiculous behaviour in order to be drop-in
>> replacements for gcc:
>>
>> gcc prog.c -oprog.exe
>> prog
>
> gcc is designed for the Unix environment. In Unix, there is a make
> utility (required by POSIX) with built-in rules (also required by
> POSIX in environments that support XSI extensions).
>
> If you have a prog.c, you should be able able to build prog like this:
>
> make prog
>
> If you have to explicitly use gcc, you're not in the home turf.
>
>> Now you want to recall that and instead compile prog2.c. With bcc you
>> press up-arrow twice then type "2".
>
> Up arrow recall of compiler commands is not very important in the
> world of "what gets programmed with C for what purpose".
>
> Most C programs consist of multiple files, and link libraries.
>
> The majority of C programming ss now is embedded, where you
> don't have edit-compile-run but edit-compile-uploadtotarget-run.
>
>> See how unfriendly such a feature is? Just needing the extension is a
>
> If you wanted friendly, why wouldn't you just use a language in which
> you don't have to leave the running program at all in order to rewrite
> some parts of it?
>
> Also, do you know about shell functions and aliases?
>
> b()
> {
> gcc -o $1 $1.c
> }
>

All this is beating about the bush. Either gcc is a program intended to
be used directly from a command line or it's not.

You shouldn't need DIY workarounds just to get it to do its basic job,
or use alternates like make which have their own problems.

Often I need to compile the same program across compilers, sometimes
across languages; then `make` will not help. Neither does having a
special set of options and exceptions just for gcc.

I mean, why doesn't gcc just implement your 'gcc -o $1 $1.c' suggestion?

I do use scripts when the requirements and options are too elaborate to
retype every time, but to compile ONE source file into an executable?

Here's something funny:

zig build-exe hello.zig

This produces hello.exe. But Zig can also compile C code:

zig cc hello.c

This produces a.exe. Words fail me... An opportunity to fix something
that's broken ('zig cc' is your script idea but on a massive scale), and
it completely passes it up.

David Brown <david.brown@hesbynett.no> writes:
>On 01/08/2023 16:41, Bart wrote:
>>
>> On 01/08/2023 14:00, David Brown wrote:
>> > On 27/07/2023 18:18, Bart wrote:
>> >> 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):
>>
>> > Efficiency (or lack thereof) is not an issue.  I would expect that
>> > changing to 64-bit int will make some code more efficient (on 64-bit
>> > platforms), and some code less efficient.  Whether it works or not is
>> > the crucial issue.
>> >
>> > (I still would like to hear examples of reasonably likely situations
>> > where changing "int" to 64-bit would stop code from working correctly.
>>
>> OK, let's try it. I took one of my generated C files which had these two
>> typedefs at the start:
>>
>>     typedef int                i32;
>>     typedef unsigned int       u32;
>>
>> I changed them to:
>>
>>     typedef long long          i32;
>>     typedef unsigned long long u32;
>>
>> Then I recompiled the 40Kloc file (it was an interpreter) and tried to
>> run a script; it crashed. I can't say I was surprised: there are plenty
>> of unions where the relations between the elements have to be exact.
>>
>
>So we have an example of one single program that has trouble when the
>size-specific 32-bit type is changed to 64 bits.

Moreover it was using type-punning, where all bets are off anyway.

On 27/07/2023 17:03, Bart wrote:
>
> On 27/07/2023 15:07, Scott Lurndal wrote:
> > David Brown <david.brown@hesbynett.no> writes:

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

C23 allows you to write

enum colour : uint8_t { red, green, blue };

You can specify any integer type as the underlying type. (C++ had this
feature first, and it is good to see it added to C.)

Most C compilers will also let you have bitfields of enumerated types.

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

As always - you are talking about 64-bit processors only. That's the
standard for "big" systems, but not for embedded systems.

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

Yes. It is also common to arrange structs to fit closely with cache
lines, when you want fast code.

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

The prefix system for x86 is a huge mess anyway - it's hard to tell what
might be faster or slower with all the prefixes needed for accessing
different registers and different sizes. Much of it is already figured
out early in the instruction prefetch buffers, so they don't affect
decode speed - but the details vary wildly between different x86-64
processors.

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

In a new language aimed at "big" processors, you'd either want all local
work to be done at 64-bit, or you'd never want any promotion and have
operations done at the size of the operands. (But with the "as-if" rule
allowing for optimisations.) I can't see any reason, other than
historical compatibility, for a mixture.

> 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 2023-08-01, Bart <bc@freeuk.com> wrote:
> On 01/08/2023 18:04, Kaz Kylheku wrote:
> > On 2023-08-01, Bart <bc@freeuk.com> wrote:
> All this is beating about the bush. Either gcc is a program intended to
> be used directly from a command line or it's not.

Mostly, it isn't.

> You shouldn't need DIY workarounds just to get it to do its basic job,

"make prog" isn't a DIY workaround; it's an IEEE standard workaround.

> or use alternates like make which have their own problems.

"make" and "cc" are part of the same standard environment.

Unix has had make since the 1970's and used it for most of the C
compiling.

It's part and parcel of one system.

> I mean, why doesn't gcc just implement your 'gcc -o $1 $1.c' suggestion?

Someone in this thread remarked how even Clang and Zig cc have to
imitate the behavior in order to drop in. So that's the reason gcc
cannot just implement the suggestion.

Just like clang has to be a drop-in for gcc, new gcc has to be a drop-in
for old gcc.

If the gcc command changed the default name `a.out` to something else,
it would break all build systems which happen to rely on that behavior.

In the first place, gcc itself took on that convention in order to be a
drop-in for Unix cc.

Stallman wasn't crazy about Unix! He really wanted a Lisp machine. But
Unix was the proprietary software that people were using, that had
to be replaced with free software, in his view, and replacing requires
playing the compatibility game. So, for instance, Bash had all the dumb
whitespace and escaping issues as the Bourne shell.

GNU went with shit-for-shit compatibility with Unix; but at least they
tried to make the tools internally more robust to bad inputs, and
extended them with useful features.

So, there is no way something like "gcc foo.c" producing ./foo could be
merged. A remote possibility would be that gcc can be installed under an
alias like gccp (gcc, make program). Where if gcc sees that it is
invoked under that name, it auto-configures the -o option. gccp would
likely be rejected as something that can just be a shell script wrapper
that you can develop as a separate project.

GCC is FOSS, so you can contribute that, if it bothers you.

However, it's a difficult project to get into.

I developed a useful (IMHO) extension to GCC's preprocessor in April
2022 and posted that to the GCC mailing list. My patch included
documentation and test cases; all the homework was done. I never
received a reply. I pinged several times in the ensuing months, then
gave up on it.

If you disagree with the design of the gcc command line, a productive
way to do something about it would be to develop a wrapper, say
one called "wcc". If enough users share your views, they will widely
install wcc, and people will start building their stuff through it.
It could just be a single file shell script.

"wcc" could examine its own name and look for the real compiler
accordingly, so that if it were installed as "wcc-arm-gnu-linux",
it will massage the arguments and hand them off to "gcc-arm-gnu-linux".

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

David Brown <david.brown@hesbynett.no> writes:
>On 27/07/2023 17:03, Bart wrote:
>>
>> On 27/07/2023 15:07, Scott Lurndal wrote:
>> > David Brown <david.brown@hesbynett.no> writes:

>
>> 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).
>>
>
>The prefix system for x86 is a huge mess anyway - it's hard to tell what
>might be faster or slower with all the prefixes needed for accessing
>different registers and different sizes. Much of it is already figured
>out early in the instruction prefetch buffers, so they don't affect
>decode speed - but the details vary wildly between different x86-64
>processors.

And there's a new prefix (REX2) coming, which doubles the number
of general purpose registers to 32, and extends some instructions to be
three-operand instead of two. A set of new conditional instructions,
including load and store, are added.

https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html

On 01/08/2023 18:18, David Brown wrote:
> On 01/08/2023 16:41, Bart wrote:
> If only the tool came with instructions, you might have had a way to
> learn after only a decade or so of use.

I don't use gcc that often. Most command line tools have sensible UIs,
I'd forgotten that gcc was so dumb.

Let's face it, if gcc had not had that quirk, would there have been a
million programmers clamouring for its introduction? I don't think so!

While do people feel the need to defend every stupid feature? Just admit
it was a bad idea which is still being perpetuated decades later.

> Stop cherry picking.
>
>
<https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(basic_instructions)#Integers>

That chart confirms what I said. It's only C, C++ and OK, Objective C
that use that form.

From the chart, C#, Java, Rust, Go, D, Swift, even F#, Scala and Raku,
use simple forms with single, tidy keywords and fixed sizes.

The chart leaves out Zig, Julia and Odin which I think were part of my
list.

That leaves some ancient languages like COBOL to support your claim.

My remarks were to do with languages that supported fixed-width integer
types, which are expected to be lower-level. I wouldn't have put COBOL
in that group ...

> Lots of languages require a module import, or equivalent, to access
> size-specific types. This applies especially to higher level languages
> that don't have much use for such types.

.... or ones like Haskell. (I don't know which ones need the fundamental
types to be specifically requested, but I guess you do.)

> I am not (and never have) argued that "int32_t" and similar is superior
> to "int32". But it is definitely superior (IMHO) to minimalist names
> like "i32".

I do something which may be controversial: I allow both 'int32' and
'i32'! That allows for differing styles and preferences. It also makes
porting fragments of code either way a little easier.

Before you say that you shouldn't allow too much freedom, remember that
C allows 'int', 'signed int', 'int signed', 'signed', 'int32_t', and,
sometimes, 'long' (and 'signed long', 'long signed') for the same
machine type.

(It's a good thing we're not enumerating the variations of 'uint64_t'!)

> I am merely arguing that it is not worse - it really is not
> the kind of horror story you seem to imagine, and there is no evidence
> to suggest that there exists any kind of widespread dislike for the
> name, either amongst C programmers or other programmers.

That most languages have made tidier, snappier choices says quite a lot.

> That is not "evident" at all. The names are only available if
> <stdint.h> is included, and therefore clashes with existing names is not
> an issue. Indeed, the C99 rationale describes that the names were
> picked to match existing usage.

So, why did existing usage employ that '_t'?

> You could "win" by trying to answer the question - or at least, by
> trying to understand it.

Nobody can win because this is a matter of opinion. However, I don't
believe I know your actual opinion, as you seem happy to go along with
whatever ungainly syntax that C has decreed, and will defend that
against my view.

No number of contemporary languages that have made more pleasing choices
will convince you. In fact you have to dredge up examples from ancient
history to show that sometimes other languages have terrible syntax too!

> You are the one that has claimed people (other than you) find the
> <stdint.h> names so ugly and long-winded that they use typedefs to avoid
> them. All I want is for some justification or evidence to support such
> a claim.

In what form?

Use of names such as "int32" or "i32" for other reasons (such
> as pre-C99 historical reasons) is not relevant.
>
> Alternatively, simply accept that while it may be the case that some
> people find "int32_t" ugly, pretty much no one is particularly bothered,

Most people are happy to go along with `int32_t` like you are. Many
might have been happier with `int32` or `i32`. Some will go so far as to
define their own set of more pleasing and ergonomic types, and if they
know what's good for them, will keep that quiet.

A smaller number may be more vocal about it.

The tiny number who go on to create new languages will show how much
they love the C99 types by instead choosing something better!

> "They", in this context, being "some guy on the internet", with all the
> authority that implies.

The link I wanted was from Reddit proposing that everyone should get
behind using 'i8-i64' typedefs in C, but I couldn't locate it. I
remember it had quite a few upvotes.

> You'll also see a lot of support for macros like PRI32i being ugly, but
> that is more an issue with printf-style formatting. (C23, you'll be
> pleased to hear, lets you use "%w32i" and "%w64u" for formatting int32_t
> and uint64_t values.)

Nice. In my everyday language since 1981, I've had to use nothing at
all; the compiler already knows the the type of the expression it's
printing! I know, it's magic.

And in my C compiler since 2017, I can use "%?" format for any numeric type.

>> Actually I've just measured it: using the uint64_t instead of u64 etc
>> made the output 6.5% bigger.
>>
>
> You are right up there with Flash Gordon, saviour of the universe!

So, how big a percentage will make you take notice? This 6% reduction is
a no-brainer which can be achieved with no effort.

But sure, your attitude is typical. Take potential enhancements of 1 or
2% in a hundred different places, it all adds up. But each one on its
own seems pointless.

>> >> extensively. For example, every `0` constant is written as `(i64)0`.
>>
>> > First off, that is usually a silly idea.
>>
>> Integer constants in the source language are 64 bits and need to be so
>> in the C. So, how would /you/ do it? Remember that 0L and 0LL (and 0UL
>> and 0ULL) do not have precisely defined widths on their types.
>>
>
> Why do you think you need a precisely defined width here?

Because 1234 in the generated C is a 32-bit int type, but it represents
a 64-bit int type in the original source. It's unwise to leave it as the
wrong type.

In most cases it won't make a difference, as it will be coerced to the
right type thanks to neighbouring values, or as required for a function
call. Most expressions such as 1 << 33 will be reduced before they get
transpiled, but not all, so in those cases, 32-bit overflow can occur.

And suppose the generated C code looks like this first line:

printf("%lld\n", -335);
printf("%lld\n", (long long int)-335);

That first line outputs the wrong value. The second with the cast gets
it right.

On 01/08/2023 18:43, David Brown wrote:
> On 27/07/2023 17:03, Bart wrote:
>>
>> On 27/07/2023 15:07, Scott Lurndal wrote:
>> > David Brown <david.brown@hesbynett.no> writes:
>
>>
>> Is there no way of overriding the type in C? (Other than just using an
>> 8- or 16-bit type anyway as I do.)
>>
>
> C23 allows you to write
>
> enum colour : uint8_t { red, green, blue };
>
> You can specify any integer type as the underlying type. (C++ had this
> feature first, and it is good to see it added to C.)
>
> Most C compilers will also let you have bitfields of enumerated types.
>
>> Otherwise there is no real issue with space, not for standalone
>> variables. Bear in that registers and stacks will be 64 bits anyway.
>>
>
> As always - you are talking about 64-bit processors only. That's the
> standard for "big" systems, but not for embedded systems.

That makes no sense. Everyone is using 64-bit processors now in their
desktops, laptops, tablets and smartphones. Even the Raspberry Pi is 64
bits. They're hardly big systems anymore.

I'm talking about the default 'int' being 64 bits for those machines, in
the same way it was 32 bits for 32-bit machines, and 16 bits for 16-bit
ones.

That same default determines whether the constant 1234 has a 16-, 32- or
64-bit type.

So this doesn't stop an embedded system using a narrower int type, as
/already happens/ with 8-32-bit processors.

But for some reason C hasn't made the leap to a 64-bit int on 64-bit
platforms.

I've speculated that the reason is that too much software would not make
the transition, but you've said that was rubbish.

If so, they why /isn't/ a 64-bit 'int' type in C that common?

scott@slp53.sl.home (Scott Lurndal) writes:
> 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.

A C enum type is compatible with some implementation-defined integer
type. enum *constants* are of type int (for historical reasons), but
they're usually implicitly converted to some other type. Even if int is
64 bits, an enum type can be, for example, 8, 16, 32, or 64 bits.

[...]

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

Bart <bc@freeuk.com> writes:
>On 01/08/2023 18:43, David Brown wrote:
> > On 27/07/2023 17:03, Bart wrote:

>
>That makes no sense. Everyone is using 64-bit processors now in their
>desktops, laptops, tablets and smartphones. Even the Raspberry Pi is 64
>bits. They're hardly big systems anymore.
>
>I'm talking about the default 'int' being 64 bits for those machines, in
>the same way it was 32 bits for 32-bit machines, and 16 bits for 16-bit
>ones.

It will _NEVER_ happen. There is no compelling reason to change the
existing ABIs, and even if memory seems abundant today, why use more than
necessary?

On 01/08/2023 22:53, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 01/08/2023 18:43, David Brown wrote:
>>> On 27/07/2023 17:03, Bart wrote:
>
>>
>> That makes no sense. Everyone is using 64-bit processors now in their
>> desktops, laptops, tablets and smartphones. Even the Raspberry Pi is 64
>> bits. They're hardly big systems anymore.
>>
>> I'm talking about the default 'int' being 64 bits for those machines, in
>> the same way it was 32 bits for 32-bit machines, and 16 bits for 16-bit
>> ones.
>
> It will _NEVER_ happen. There is no compelling reason to change the
> existing ABIs, and even if memory seems abundant today, why use more than
> necessary?

In that case why bother even switching to 32-bit ints?

To reiterate, on a 64-bit machine, pointers are 64 bits anyway, and any
pushed arguments occupy 64-bit stack slots.

Remember that I'm talking about INDIVIDUAL variables: statics, locals
and parameters. Local and parameters will reuse the same stack frame
memory since only a few functions are active at any one time. (I'm sure
you know all this!)

So we're left with global 'int' objects.

Where is the memory being used? Even 10,000 global 64-bit int variables
will only use 40KB extra memory, compared with perhaps 8,000,000KB
machine capacity.

If you're talking about dynamic and static arrays and allocations of
large numbers of elements, then of course you will take care to use the
most efficient type if you don't need a 2**64 range. You'd do that
anyway if even 2**32 was too much.

But you still can't really get away from 64-bit pointers without a lot
of trouble.

So while it is easy to choose int32_t or smaller instead of int64_t or
64-bit 'int', you can't do anything about T* types.

That's what affects 64-bit applications, not the size of 'int'.

Bart <bc@freeuk.com> writes:
>On 01/08/2023 22:53, Scott Lurndal wrote:
> > Bart <bc@freeuk.com> writes:
> >> On 01/08/2023 18:43, David Brown wrote:
> >>> On 27/07/2023 17:03, Bart wrote:
> >
> >>
> >> That makes no sense. Everyone is using 64-bit processors now in their
> >> desktops, laptops, tablets and smartphones. Even the Raspberry Pi is 64
> >> bits. They're hardly big systems anymore.
> >>
> >> I'm talking about the default 'int' being 64 bits for those machines, in
> >> the same way it was 32 bits for 32-bit machines, and 16 bits for 16-bit
> >> ones.
> >
> > It will _NEVER_ happen. There is no compelling reason to change the
> > existing ABIs, and even if memory seems abundant today, why use more than
> > necessary?
>
>In that case why bother even switching to 32-bit ints?
>
>To reiterate, on a 64-bit machine, pointers are 64 bits anyway, and any
>pushed arguments occupy 64-bit stack slots.

The stack pointer is kept aligned on 8 (or 16)-byte boundaries. That doesn't mean
that data is stored on the stack in 8-byte cells. 32-bit data is stored in
4 bytes, e.g. automatic storage in a function. Function arguments are passed
in registers.

On 02/08/2023 02:54, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 01/08/2023 22:53, Scott Lurndal wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 01/08/2023 18:43, David Brown wrote:
>>>>> On 27/07/2023 17:03, Bart wrote:
>>>
>>>>
>>>> That makes no sense. Everyone is using 64-bit processors now in their
>>>> desktops, laptops, tablets and smartphones. Even the Raspberry Pi
is 64
>>>> bits. They're hardly big systems anymore.
>>>>
>>>> I'm talking about the default 'int' being 64 bits for those
machines, in
>>>> the same way it was 32 bits for 32-bit machines, and 16 bits for
16-bit
>>>> ones.
>>>
>>> It will _NEVER_ happen. There is no compelling reason to change the
>>> existing ABIs, and even if memory seems abundant today, why use
more than
>>> necessary?
>>
>> In that case why bother even switching to 32-bit ints?
>>
>> To reiterate, on a 64-bit machine, pointers are 64 bits anyway, and any
>> pushed arguments occupy 64-bit stack slots.
>
> The stack pointer is kept aligned on 8 (or 16)-byte boundaries. That
doesn't mean
> that data is stored on the stack in 8-byte cells. 32-bit data is
stored in
> 4 bytes, e.g. automatic storage in a function. Function arguments
are passed
> in registers.

This is ABI-specific. On Windows, parameter 5 and up are passed on the
stack. Each parameter occupies a 64-bit slot; they are not packed.

In any case, a 'shadow space' of 32 bytes is needed for the first 4
parameters. This is needed whether 'int' in the C language is 32 or 64 bits.

The only opportunity for packing smaller types into one 64-bit word
comes with local variables - those that don't just live in registers anyway.

But as I said, stack-frame space is usually reused, except where:

* There is very deep recursion
* Where large arrays are allocated on the stack, but these can be
exactly the same size as they are in a language with a 32-bit 'int'.

Because (you may not realise this) when you create an array, you can
/choose/ whether the elements are ints, or something smaller, or larger.

I've just done some tests on a few typical programs. Typical stack usage
range from 200 to 4000 slots, or 32KB of stack. The 4000-depth program
was a compiler compiling itself, a naturally recursive task.

A fraction of this will be your 'automatic storage', so sure, you might
use 10KB more, IF you choose to use 'int' for those variables.

So, do you have any actual evidence that a program written for a
64-bit-int will use significantly greater amounts of memory, given that
there is so much 64-bit stuff going on anyway?

Of course, it you have an existing program that uses this:

int A[100000000];

Compiled unchanged, this will occupy 800MB with a 64-bit int, compared
with 400MB with a 32-bit int, but then a 16-bit int would only have used
200MB.

So whatever increases are seen in typical programs, the same scale of
increase would have been seen during the 16 to 32-bit transition; why
weren't people up in arms about that? At that time, RAM really was limited.

On Tuesday, 1 August 2023 at 21:02:11 UTC+1, Bart wrote:
>
> Before you say that you shouldn't allow too much freedom, remember that
> C allows 'int', 'signed int', 'int signed', 'signed', 'int32_t', and,
> sometimes, 'long' (and 'signed long', 'long signed') for the same
> machine type.
>
Yes. Fundamentally we have simple reality. 8 bit, 16 bit, 32 bit or 64 bit
integers, signed or unsigned. But C has made a vastly complicated
pig's ear of it. You can add "size_t" to list of types which are often 32 bit.
Then there's exotica such as int_fast32 _t. Which is often what you really
want, but you seldom see it in real code.

On 02/08/2023 11:41, Malcolm McLean wrote:
> On Tuesday, 1 August 2023 at 21:02:11 UTC+1, Bart wrote:
>>
>> Before you say that you shouldn't allow too much freedom, remember that
>> C allows 'int', 'signed int', 'int signed', 'signed', 'int32_t', and,
>> sometimes, 'long' (and 'signed long', 'long signed') for the same
>> machine type.
>>
> Yes. Fundamentally we have simple reality. 8 bit, 16 bit, 32 bit or
64 bit
> integers, signed or unsigned. But C has made a vastly complicated
> pig's ear of it. You can add "size_t" to list of types which are
often 32 bit.
> Then there's exotica such as int_fast32 _t. Which is often what you
really
> want, but you seldom see it in real code.

Every time I try to even count the possibilities, I get a different
result. My latest attempt gives 35 C types for those 8 machine types:

11 classic C types
8 u/intN_t
8 u/intfastN_t (I don't know exactly where N goes; I don't care!)
8 u/intleastN_t

The 11 is due to the superfluous 'long' which has the same size as
either `int' or 'long long', and the third variety of 'char'.

Here, as far as I know, all 35 are technically distinct, incompatible
types, except that in reality, 'int32_t' may be defined on top of 'int',
for example. This comes up if you try and use _Generic.

I haven't counted the different combinations of those types which need
multiple tokens to specify. For example, 'unsigned long long [int]' I
/think/ can be written in 15 different ways.

Plus I haven't included the plethora of auxiliary types:

intptr_t
uintptr_t
size_t
ssize_t
clock_t
time_t
offset_t
....

I always won't get into the details of how you print any of these myriad
types, or create a literal (sorry, constant) value suitable to
initialise any of those.

It's a complete joke. Yet, people here will seriously defend it.