On Wednesday, 2 August 2023 at 12:09:16 UTC+1, Bart wrote:
> 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.
>
I don't use any of them in the Baby X resource compiler. Audio samples are
saved as "short", UTF-16 values as "unsigned short". If short isn't 16 bits, it
might or might not work, but the chances it will work are good. If I used
int16_t, it would break if short isn't 16 bits. And it would break if stdint.h
isn't available. So that was an easy decision to make.

On 01/08/2023 22:01, Bart wrote:
> 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.

I don't believe I have written many real C programs in which the name of
the final executable matched the name of any of the C files that went
into it. Having "gcc prog.c" result in "prog" (or "prog.exe" for
Windows) is as useless to me as having it result in "a.out". Other
people will have different ideas and needs - but that's the real point.
gcc is made for lots of people, and cannot possibly suit everyone with
its defaults. Just because one person, such as yourself, imagines that
their preferences are somehow near universal, does not make them so.

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

Yes, as I said - I only know of C-related languages that use "int32_t"
form. But it also shows a huge range of other forms used by many other
languages - "int32" (or worse, "i32") is not even close to as common as
you imagine.

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

Look again. There are all sorts of languages with all sorts of names
for fixed size integers - and for many languages, these only exist for
interaction with external code or data formats.

And while that page only has some languages, I am sure it would not be
hard to find dozens more that do not fit your ideas.

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

You can read it on that link.

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

A compromise on the worst of both worlds, making sure everything is
inconsistent?

The C world would have been much better off if the <stdint.h> types had
existed from the earliest days, so that everyone used the same name for
size-specific types. Repeating that mistake by having different options
in a new language is daft. It is even sillier given that your language
only has one user, with one preference!

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

I'm not a fan of that - I would have preferred clearer types with less
options for the basic types. (And I would have preferred more types
with different characteristics for specialist usage.) Don't mistake an
understanding of how C works, how it is defined, and why it is defined
as it is, with an unmitigated like of those design decisions.

> (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 most languages have /not/ made "snappier" choices says a lot -
including that you are unable to look at references.

I don't disagree that for new non-C languages, having a "_t" on the end
of types is unnecessary and unhelpful. In making a new language,
"int32_t" is not better than "int32" (but both /are/ better than "i32"
for most languages - minimalist is not good, and few languages that aim
for minimum length of identifiers are successful).

I do, however, disagree that "int32" is /significantly/ "tidier" or
"snappier" than "int32_t". I really don't think it matters. I can't
imagine anyone, other than you, complaining about "int32_t". It's a
storm in a teacup. It really does not matter, and no one but you cares
at all.

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

That was already common in C and POSIX programming. This was in the
days before syntax highlighting, and there were no namespaces, and fewer
scopes in C. When everything goes in one namespace, it is helpful to
have some distinguishing features or conventions.

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

As I have said before, "int32" style makes sense in a new language.
"i32" style never makes sense, and is rarely a choice made by languages
(Rust is an exception here). I am quite happy with "int32_t" in C, and
I believe almost all C programmers are also happy to use it when they
need such types, assuming they know about them (a depressingly large
proportion of C programmers seem to think reading K&R teaches them all
they need to know). Does that make things clearer for you?

And no, this was /not/ a matter of opinion - my question, which you have
failed to answer so often that I am giving up (as is so often the case),
was if you had any justification for your claims that lots of other
people found the "int32_t" style so ugly and long-winded that they made
their own alternatives when programming C. It was not about other
languages, or about people who used different styles for pre-C99 C, or
people who used different names for different purposes. It was about
people who knew about the <stdint.h> names, had them easily available,
but specifically choose to define their own alternatives because
"int32_t" style was too ugly or long-winded for them to bear using them.

If you have no justification for that claim, say so. No one is arguing
against you holding your own opinions.

> No number of contemporary languages that have made more pleasing choices
> will convince you.

Well, no. Those don't answer the question.

> In fact you have to dredge up examples from ancient
> history to show that sometimes other languages have terrible syntax too!
>

Languages like Ada, Java, D, Scala, Haskell, Eiffel, SQL ? These are
everyday languages - you can easily get a job working with any of these.

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

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

> On Wednesday, 2 August 2023 at 12:09:16 UTC+1, Bart wrote:
>> On 02/08/2023 11:41, Malcolm McLean wrote:

>> > Then there's exotica such as int_fast32 _t. Which is often what you
>> > really want, but you seldom see it in real code.

> I don't use any of them in the Baby X resource compiler. Audio samples
> are saved as "short", UTF-16 values as "unsigned short". If short
> isn't 16 bits, it might or might not work, but the chances it will
> work are good. If I used int16_t, it would break if short isn't 16
> bits.

int16_t "breaks" if there is no such type, but I think such a type can
exist even if short is not 16 bits.

> And it would break if stdint.h isn't available. So that was an easy
> decision to make.

That rules out the type you probably want -- one of the types you say is
often what is really wanted (int_least16_t). No wonder they are rarely
seen in "real code" if people won't use them even after nearly a quarter
of a century. Are you really limiting yourself to writing C90?

--
Ben.

On Wednesday, 2 August 2023 at 17:05:14 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Wednesday, 2 August 2023 at 12:09:16 UTC+1, Bart wrote:
> >> On 02/08/2023 11:41, Malcolm McLean wrote:
>
> >> > Then there's exotica such as int_fast32 _t. Which is often what you
> >> > really want, but you seldom see it in real code.
> > I don't use any of them in the Baby X resource compiler. Audio samples
> > are saved as "short", UTF-16 values as "unsigned short". If short
> > isn't 16 bits, it might or might not work, but the chances it will
> > work are good. If I used int16_t, it would break if short isn't 16
> > bits.
> int16_t "breaks" if there is no such type, but I think such a type can
> exist even if short is not 16 bits.
>
CHAR_BIT would have to be sixteen.
> > And it would break if stdint.h isn't available. So that was an easy
> > decision to make.
> That rules out the type you probably want -- one of the types you say is
> often what is really wanted (int_least16_t). No wonder they are rarely
> seen in "real code" if people won't use them even after nearly a quarter
> of a century. Are you really limiting yourself to writing C90?
>
It's best to restrict yourself to the conservative subset of C unless there is
really a pressing reason to do otherwise. The Baby X resource compiler
is designed for use with Baby X, but it might also find a niche in the
toolchains of people writing for small embedded systems. Which
might come with old or restricted C compilers.

On 01/08/2023 23:16, Bart wrote:
> 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.
>

Everyone is /not/ using 64-bit processors now. The great majority of
processors in use and in production are /not/ 64-bit. And while there
are some 64-bit embedded systems, they are a tiny proportion (as yet).

The majority of programmers these days are targeting 64-bit devices -
but the great majority of programmers are not using C. Remember, C has
been a specialist minority language on "big" machines for a long time
now - it is used for low-level stuff, high efficiency coding, and some
kinds of high portability code. To a steadily increasing extent, C
programming means small systems embedded, or Linux/BSD OS work,
low-level utilities or key libraries - or maintenance of old code.

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

The topic here was, I believe, the underlying type for enumerations.

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

(For the record - I am not entirely keen on the way C handles integer
constant types. I think Ada has a neat way, adapting the type according
to use.)

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

It is, I believe, primarily a matter of space taken. 32-bit types are
big enough for the vast majority of integer usage, and avoiding wasting
cache space makes a large difference to performance.

(I do agree with you that 64-bit int would have had its advantages.)

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

I've said you had no evidence or justification for claiming that, and
you certainly haven't presented any.

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

See above (though my speculations should not be taken as definitive
answers).

On 02/08/2023 12:14, Bart wrote:
>
> 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.
>

This was, IMHO, an idiotic design decision from MS. It makes variadic
functions (like printf) significantly easier to implement, but seriously
slows down all other function calls. (Of course, within a program,
generated code does not have to follow the ABI strictly - I don't know
if any C compilers avoid throwing away a lump of cache for every
function call.) MS's poor calling convention is a reason why the move
to 64-bit did not give as much performance gain on Windows as it did on
other platforms (since all other x86-64 use the same smarter ABI).

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

It is also possible when passing structs into and out of functions.
Remember also that only a small proportion of code on PC's is in C - for
other languages, structs or classes are passed around a great deal.
Smaller structs go in registers, and bigger ones go on the stack -
32-bit (and smaller) types are packed tightly.

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

Lots of numbers are bigger than 32K. Very few are bigger than 2G.
Making int 32 bits made a lot of code much more convenient (and
magically fixed some people's overflow bugs). Making int 64 bits would
have helped very little in proportion to the costs in ram space.
(Though I agree with you that the cost in ram space is perhaps not
/that/ dramatic.)

On 02/08/2023 17:23, David Brown wrote:
> On 02/08/2023 12:14, Bart wrote:
>> 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.
>>
>
> This was, IMHO, an idiotic design decision from MS. It makes variadic
> functions (like printf) significantly easier to implement, but seriously
> slows down all other function calls.

In what way does it slow it down?

In my generated code, between 99% and 99.5% of calls do not need to
allocate that shadow space, because it is just done once at the start of
the function, with the same instruction that allocates the stack-frame,
which needs to be 32 bytes bigger.

It's needed only in more complex calls (nested etc).

(The figures refer to the number of static instances in the code, not
the actual number of dynamic calls, but I've no reason to suppose that
most calls are limited to the sub-1% that need their own shadow space.)

Similar, the difference between passing only 4 arguments in registers on
Windows, versus 6 on SYS V: in my code, some 99% of function calls
(still static instances) do not have more than 4 parameters. It benefits
only 0.5% of calls, but a cost of 2 more volatile registers.

> (Of course, within a program,
> generated code does not have to follow the ABI strictly - I don't know
> if any C compilers avoid throwing away a lump of cache for every
> function call.) MS's poor calling convention is a reason why the move
> to 64-bit did not give as much performance gain on Windows as it did on
> other platforms (since all other x86-64 use the same smarter ABI).

I never noticed that MY move from my own API, which pushed ALL
arguments, to the Win ABI made anything much slower. It may even have
improved matters.

What did cost though was switching from a 32-bit pointer on x64, to a
full 64-bit pointer, which on my interpreter slowed it down by 5%
because data structures were bigger and took more memory.

>> 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.
>>
>
> It is also possible when passing structs into and out of functions.
> Remember also that only a small proportion of code on PC's is in C - for
> other languages, structs or classes are passed around a great deal.
> Smaller structs go in registers, and bigger ones go on the stack -
> 32-bit (and smaller) types are packed tightly.
>
>>
>> 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.
>>
>
> Lots of numbers are bigger than 32K. Very few are bigger than 2G.
> Making int 32 bits made a lot of code much more convenient (and
> magically fixed some people's overflow bugs).

64-bits would doubtless fix a few more.

But it's true that the vast majority of 'don't care' integer values will
be much smaller.

I've done a survey on one application (here I'm using an interpreter for
my static language where I can easily add these checks), which only
looks at positive numbers, and there, 99.7% of values stored to i64
memory slots would fit into a i32 range.

But, then, 52% would fit into 16 bits, and 49% into 8 bits. So 32 bits
is also too much in half the cases!

On a different application, 88% would fit into 16 bits, and 62% into 8 bits.

(I'm imagine lots of the latter values are zeros. Actually, I don't need
to imagine: it's 40% and 20% for the two programs, where ints store zeros.)

However: these measurements don't cover spread, they are dynamic
assignments, most could be to the same few variables. They don't look at
intermediate values, or unsigned integers.

They don't measure temporal spread: maybe an int holds small values 99%
of the time, but then there is the odd large value that must be
accommodated.

So my survey was rough and ready (and my apps are probably not too
challenging; you need people who write code that allocate huge arrays).

But what 64 bits buys you is more piece of mind, and also simplicity:
every default scalar type is the same size: signed, unsigned, double,
pointer.

I also used to think that using 64 bits was mostly wasteful (especially
with pointers), but then, having split-level 32/64-bit types is also a
nuisance.

Since the actual costs of int64 (not 64-bit pointers) can be
insignificant, I've stopped worrying.

On 2023-08-02, David Brown <david.brown@hesbynett.no> wrote:
> On 01/08/2023 22:01, Bart wrote:
>> 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.
>
> I don't believe I have written many real C programs in which the name of
> the final executable matched the name of any of the C files that went
> into it. Having "gcc prog.c" result in "prog" (or "prog.exe" for
> Windows) is as useless to me as having it result in "a.out". Other
> people will have different ideas and needs - but that's the real point.
> gcc is made for lots of people, and cannot possibly suit everyone with
> its defaults. Just because one person, such as yourself, imagines that
> their preferences are somehow near universal, does not make them so.

If, for whatever reason, it becomes a crucial requirement to be able to
iterate, in a shell, on "gcc -o prog prog.c" with the fewest number of
keystrokes, the second most intelligent thing is to do this:

alias g='gcc -o prog prog.c'

Then you just do this:

$ g

which is two keystrokes.

I say it's the second most intelligent solution because the optimal
solution is one keystroke. That can be achieved by using a terminal
emulator (or hardware terminal) with programmable keyboard macro keys.

So we make, say the <F1> function key (or whatever) output
the sequence "gcc -o prog prog.c^M".

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

On 02/08/2023 16:58, David Brown wrote:
> On 01/08/2023 22:01, Bart wrote:
>> 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.
>
> I don't believe I have written many real C programs in which the name of
> the final executable matched the name of any of the C files that went
> into it. Having "gcc prog.c" result in "prog" (or "prog.exe" for
> Windows) is as useless to me as having it result in "a.out". Other
> people will have different ideas and needs - but that's the real point.
> gcc is made for lots of people, and cannot possibly suit everyone with
> its defaults. Just because one person, such as yourself, imagines that
> their preferences are somehow near universal, does not make them so.

It is a very common requirement for a command line application to read
in one file with extension .X, and write out another file /of the same
name/ but with extension .Y.

And it is commonly done without having to specify the names of both files:

convert2y file.x # like this
convert2y file.x file.y # not like this
convert2y file.x -o file.y # or like this

You want examples? Well, even gcc does that when it suits! For example:

gcc -S prog.c # writes prog.s
gcc -c prog.c # writes prog.o
gcc -c prog.s # writes prog.o

Now these do one file at a time. Writing an executable is slightly
different as there can be multiple input files and one output file; what
to do in that case?

This is how gcc deals with all possibilities:

gcc one.c # writes a.exe
gcc two.c three.c four.c # writes a.exe
gcc -shared five.c # writes a.exe (not even a.dll)

Notice how, in each case, it overwrites the a.exe that was generated by
the last invocation of gcc. This is on a par with writing a function
like this::

char* i64tostr(long long int a) {
static char str[100];
sprintf(str, "%lld", a);
return str;
}

This only works if the result is consumed immediately before any
subsequent calls.

You can argue that my middle example has some ambiguity: what should the
output name be? But that is not the case with the others, so why is it
still being so obstuse and unhelpful?

This is how my product deals with the same inputs:

bcc one # writes one.exe
bcc two three four # writes two.exe
bcc -dll five # writes five.dll

In each case, the compiler lists the input files, and the name of the
output file, for example:

c:\c>bcc one
Compiling one.c to one.exe

Compare with what gcc does; which do you believe is more useful, more
helpful, more sensible?

>> That chart confirms what I said. It's only C, C++ and OK, Objective C
>> that use that form.
>>
>
> Yes, as I said - I only know of C-related languages that use "int32_t"
> form. But it also shows a huge range of other forms used by many other
> languages - "int32" (or worse, "i32") is not even close to as common as
> you imagine.
>
>> 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.
>>
>
> Look again. There are all sorts of languages with all sorts of names
> for fixed size integers - and for many languages, these only exist for
> interaction with external code or data formats.

I compare more contemporary languages, and include only those that have
a full set of fixed-width integer types. They can be summarised like
this showing the representations for 32-bit signed integers:

C int32_t
C++ int32_t
Obj C int32_t

C# int
D int
F# int32
Go int32
Haskell Int32
Java int
Julia Int32
Nim int32
Odin i32
Raku int32
Rust i32
Scala Int
Swift Int32
Zig i32

I'd previously said that most of those others used some variation of
'int32', 'i32' or 'int' with a hard-coded, guaranteed size. And that is
exactly the case.

I don't include ones that are too ancient or too odd-ball, or which
don't actually have fixed width types (Python?!), or which are too variable:

Ada
COBOL
Fortran
Scheme
Pascal
Visual Basic
Python

For example, when I used Fortran, I used INTEGER*4 to denote a 32-bit
integer; that is not reflected in the chart.

You might still want to delude yourself that C is not alone in having
ugly type denotations. But the fact is, it is C's types that I come
across all the time, not COBOL or VB.NET. And most newer languages are
getting it right.

On 02/08/2023 18:04, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Wednesday, 2 August 2023 at 12:09:16 UTC+1, Bart wrote:
>>> On 02/08/2023 11:41, Malcolm McLean wrote:
>
>>>> Then there's exotica such as int_fast32 _t. Which is often what you
>>>> really want, but you seldom see it in real code.
>
>> I don't use any of them in the Baby X resource compiler. Audio samples
>> are saved as "short", UTF-16 values as "unsigned short". If short
>> isn't 16 bits, it might or might not work, but the chances it will
>> work are good. If I used int16_t, it would break if short isn't 16
>> bits.
>
> int16_t "breaks" if there is no such type, but I think such a type can
> exist even if short is not 16 bits.

On smaller systems with 16-bit int, int16_t might be "int" even though
"short" is also 16 bit. (It's common on 32-bit systems for "int32_t" to
be "long", rather than "int". I don't know why.

>
>> And it would break if stdint.h isn't available. So that was an easy
>> decision to make.

<stdint.h> is available on any system where Baby X might be remotely useful.

>
> That rules out the type you probably want -- one of the types you say is
> often what is really wanted (int_least16_t). No wonder they are rarely
> seen in "real code" if people won't use them even after nearly a quarter
> of a century. Are you really limiting yourself to writing C90?
>

Some people have bizarre ideas about how to make code "portable". It is
really annoying, because they write such horrible code as a result of
their mistaken beliefs about C90 being common.

On 02/08/2023 18:10, Malcolm McLean wrote:
> On Wednesday, 2 August 2023 at 17:05:14 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> On Wednesday, 2 August 2023 at 12:09:16 UTC+1, Bart wrote:
>>>> On 02/08/2023 11:41, Malcolm McLean wrote:
>>
>>>>> Then there's exotica such as int_fast32 _t. Which is often what you
>>>>> really want, but you seldom see it in real code.
>>> I don't use any of them in the Baby X resource compiler. Audio samples
>>> are saved as "short", UTF-16 values as "unsigned short". If short
>>> isn't 16 bits, it might or might not work, but the chances it will
>>> work are good. If I used int16_t, it would break if short isn't 16
>>> bits.
>> int16_t "breaks" if there is no such type, but I think such a type can
>> exist even if short is not 16 bits.
>>
> CHAR_BIT would have to be sixteen.

No, compilers can have extended integer types.

>>> And it would break if stdint.h isn't available. So that was an easy
>>> decision to make.
>> That rules out the type you probably want -- one of the types you say is
>> often what is really wanted (int_least16_t). No wonder they are rarely
>> seen in "real code" if people won't use them even after nearly a quarter
>> of a century. Are you really limiting yourself to writing C90?
>>
> It's best to restrict yourself to the conservative subset of C unless there is
> really a pressing reason to do otherwise.

Utter drivel.

It's best to use the C version, and subset thereof, that is suitable for
writing good, clean code that gives efficient results and is likely to
work fine for all platforms for which the code is realistically going to
be of interest. That pretty much /never/ means C90. All you do by
choosing C90 is give worse quality source code, poorer efficiency in the
generated code, and home-made half-arsed solutions for problems that
were solved 25 years ago.

> The Baby X resource compiler
> is designed for use with Baby X, but it might also find a niche in the
> toolchains of people writing for small embedded systems. Which
> might come with old or restricted C compilers.
>

It will /never/ happen. So don't worry about it.

And if you were /really/ interested in obscure and outdated embedded
tools (and some of these are still in use), you might have tried to
learn a little about them - or ask someone who knows. They'd have
explained the difference between compilers for code running on the
target devices, and compilers for code running on host systems.

On Wednesday, 2 August 2023 at 22:48:49 UTC+1, David Brown wrote:
> On 02/08/2023 18:10, Malcolm McLean wrote:
> > On Wednesday, 2 August 2023 at 17:05:14 UTC+1, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>
> >>> On Wednesday, 2 August 2023 at 12:09:16 UTC+1, Bart wrote:
> >>>> On 02/08/2023 11:41, Malcolm McLean wrote:
> >>
> >>>>> Then there's exotica such as int_fast32 _t. Which is often what you
> >>>>> really want, but you seldom see it in real code.
> >>> I don't use any of them in the Baby X resource compiler. Audio samples
> >>> are saved as "short", UTF-16 values as "unsigned short". If short
> >>> isn't 16 bits, it might or might not work, but the chances it will
> >>> work are good. If I used int16_t, it would break if short isn't 16
> >>> bits.
> >> int16_t "breaks" if there is no such type, but I think such a type can
> >> exist even if short is not 16 bits.
> >>
> > CHAR_BIT would have to be sixteen.
> No, compilers can have extended integer types.
> >>> And it would break if stdint.h isn't available. So that was an easy
> >>> decision to make.
> >> That rules out the type you probably want -- one of the types you say is
> >> often what is really wanted (int_least16_t). No wonder they are rarely
> >> seen in "real code" if people won't use them even after nearly a quarter
> >> of a century. Are you really limiting yourself to writing C90?
> >>
> > It's best to restrict yourself to the conservative subset of C unless there is
> > really a pressing reason to do otherwise.
> Utter drivel.
>
> It's best to use the C version, and subset thereof, that is suitable for
> writing good, clean code that gives efficient results and is likely to
> work fine for all platforms for which the code is realistically going to
> be of interest. That pretty much /never/ means C90. All you do by
> choosing C90 is give worse quality source code, poorer efficiency in the
> generated code, and home-made half-arsed solutions for problems that
> were solved 25 years ago.
>
Efficiency in the resource compiler itself hardly matters. I tested the string
tag on a 100,000 word novel, and it came back instantly. The string also
compiled and printed out. Efficiency in the output code matters, but the vast
majority of it is static data.
> > The Baby X resource compiler
> > is designed for use with Baby X, but it might also find a niche in the
> > toolchains of people writing for small embedded systems. Which
> > might come with old or restricted C compilers.
> >
> It will /never/ happen. So don't worry about it.
>
> And if you were /really/ interested in obscure and outdated embedded
> tools (and some of these are still in use), you might have tried to
> learn a little about them - or ask someone who knows. They'd have
> explained the difference between compilers for code running on the
> target devices, and compilers for code running on host systems.
>
The Baby X resource compiler, as the name implies, is primarily intended
for use with Baby X. Baby X uses int to represent integral values,
double to represent real values, unsigned char to represent arbitrary
binary data, and char * to represent strings. There's no advantage in
using other types, except that now I'm adding audio, the PCM data will
be represented by a short.

However I took the decision to separate the resource compiler from Baby X
so it could be used as an independent program by non-Baby X users.
Who those would be I don't know. The big platforms come with monolithic
buold systems which include resource compilers, and for various reasons
it's not easy to avoid the use of the resource compiler. So I'm guessing
small embedded systems. But I can't exactly take a job doing embedded
programming just to get more experience for building the resource
compiler. The output files from the Baby X resource compiler should
compile under pretty much any C compiler out there, however.

The Baby X resource compiler itself should also compile cleanly and easily
under any hosted system. That's also an important goal.

On 02/08/2023 16:58, David Brown wrote:
> On 01/08/2023 22:01, Bart wrote:

[Type denotations]

> The C world would have been much better off if the <stdint.h> types had
> existed from the earliest days, so that everyone used the same name for
> size-specific types.  Repeating that mistake by having different options
> in a new language is daft.

Having single-token aliases for the basic types is mild compared with
what C actually allows:

int long static unsigned typedef long A;

BTW in your link, a few languages have aliases for the same type. That
includes 'int = int32_t' for Objective C.

Under the column 'Word size' (I hadn't scrolled that far before!) under
C (variable width) it has 'int', which is not correct; on most 64-bit
platforms, 'int' is not the same size as a word. It also has 'long' as
32 bits, which is not always the case.

> I do, however, disagree that "int32" is /significantly/ "tidier" or
> "snappier" than "int32_t".  I really don't think it matters.

There is a pile of things wrong with 'int32_t', 'uint64_t' and so on as
used in C. I've listed these before. Those types have simply been bolted
on and are poorly integrated with the rest of the language, with lots of
aliases across the multitude of types that shouldn't really exist.

And that _t is just hard to type, with that shifted underscore, I also
keep doing int_32t instead.

> That was already common in C and POSIX programming.  This was in the
> days before syntax highlighting, and there were no namespaces, and fewer
> scopes in C.  When everything goes in one namespace, it is helpful to
> have some distinguishing features or conventions.

And yet, in every example I've found where people create their own suite
of fixed-width integers, which you claim is because they predate C99,
I've yet to see one use a _t suffix.

> Languages like Ada, Java, D, Scala, Haskell, Eiffel, SQL ?  These are
> everyday languages - you can easily get a job working with any of these.

Java, D, Scala and Haskell were in my list of 14 languages that had got
it right. SQL wasn't listed in your link.

> You have yet to provide any evidence to suggest that there is anyone,
> other than yourself, who would "go so far".

What's the point? You will discard any examples as being just some guy
on the internet.

So what, do you need, the say-so of a huge corporation?

(A bit like Google backing Go which chose 'int32', and Mozilla backing
Rust which chose 'i32'. Or Microsoft choosing 'int32' for F#.)

>> 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.
>
> OK, so you /don't/ need a precisely defined width here, you just think
> you do.

Why do you think that? I want 1234 and 3000000000 to have a 64-bit type
so I don't have any surprises when interacting with other terms.

In C, 1234 will have type 'int', and 3000000000 will have type 'unsigned
int', both 32 bits.

You really think my generated C code should leave them unadorned, while
I just cross my fingers and hope it works?

> I wouldn't expect generated C code to contain printf calls like that -
> printf has a lot of weaknesses, and I would hope the newer language has
> better formatting facilities.

For a while I relied on sprintf. But my language allows FFI calls to
functions in 10,000 libraries that may have variadic parameters; this
can come up.

I tell you what: when you write your own C transpiler, you can do what
you like. Mine will keep in the casts to guarantee my literals have
exactly the type I expect.

Bart <bc@freeuk.com> writes:

> Having single-token aliases for the basic types is mild compared with what
> C actually allows:
>
> int long static unsigned typedef long A;

C does not allow that.

> In C, 1234 will have type 'int',

Yes.

> and 3000000000 will have type 'unsigned int',

No. It might have type int; it might have type long.

> both 32 bits.

Not always.

--
Ben.

Bart <bc@freeuk.com> writes:
[...]
> Having single-token aliases for the basic types is mild compared with
> what C actually allows:
>
> int long static unsigned typedef long A;

No, C does not allow that. Having both static and typedef in a
declaration is a constraint violation. See N1570 6.7.1.

Dropping the "static", the above would be equivalent to the much
clearer:

typedef unsigned long long A;

Perhaps the fact that you can write the keywords in a different
order is inconvenient for you for some reason, or perhaps you're
more interested in convincing people that C Is Bad than in helping
anyone understand it.

[...]

> Why do you think that? I want 1234 and 3000000000 to have a 64-bit
> type so I don't have any surprises when interacting with other terms.
>
> In C, 1234 will have type 'int', and 3000000000 will have type
> 'unsigned int', both 32 bits.

No, 3000000000 will never have type unsigned int. (It might have
in C90, depending on the characteristics of the implementation,
but I'm not going to take the time to look up the C90 rules).
An unadorned decimal constant is always of type int, long int,
or long long int. See N1570 6.4.4.1.

> You really think my generated C code should leave them unadorned,
> while I just cross my fingers and hope it works?

Not necessarily. Did someone suggest that you should?

You can emit 1234LL and 3000000000LL if you want them to be of type long
long, or you can cast them to long long, or you can cast them to int64_t
(or whatever alias you've defined for it), depending on your
requirements.

But I wonder why you care about the size of an integer constant like
1234. In most contexts, it will be implicitly converted to some type.
If int is 32 bits and the target type is 64 bits, a compiler will very
likely generate a 64-bit constant anyway, even though the constant 1234
is 32 bits in the abstract machine.

If you're passing it as an argument to a variadic function, you might
need to cast it to the target type. (Likewise for functions with
old-style declarations, but I can't think of any good reason to use
those in generated code.)

[...]

--
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 2023-08-03, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> Having single-token aliases for the basic types is mild compared with
>> what C actually allows:
>>
>> int long static unsigned typedef long A;
>
> No, C does not allow that. Having both static and typedef in a
> declaration is a constraint violation. See N1570 6.7.1.
>
> Dropping the "static", the above would be equivalent to the much
> clearer:
>
> typedef unsigned long long A;
>
> Perhaps the fact that you can write the keywords in a different
> order is inconvenient for you for some reason, or perhaps you're
> more interested in convincing people that C Is Bad than in helping
> anyone understand it.

There should be one fixed order to the declaration specifiers and
qualifiers.

In the olden days, C allowed all these:

+=
+ =
= +
=+

Making it just += was a good thing. What is all the proliferation good
for, if its variations have no semantic significance?

Being able to write "int unsigned" as well as "unsigned int"
adds absolutely nothing to the expressiveness of the language;
it only complicates the specification.

There is an explosion of possible phrases to parse, so what is
standardized instead is a silly over-parse that admits
nonsensical combinations, which then have to be subject to
exclusion checks.

A fixed order would make it more practical for a small number
of phrase structure rules alone to handle the valid forms.

If orders like "int unsigned const" had been deprecated decades
ago; so we would be well on the way toward their elimination.

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

Kaz Kylheku <864-117-4973@kylheku.com> writes:
[...]
> There should be one fixed order to the declaration specifiers and
> qualifiers.

I suppose so. If backward compatibility weren't an issue, requiring a
fixed order would make sense. So would mandating just one of "unsigned
int" or "unsigned" et al.

The standard already says:

The placement of a storage-class specifier other than at the
beginning of the declaration specifiers in a declaration is an
obsolescent feature.

Then again, that's in every edition and draft from C90 to N3096, so I'm
not holding my breath.

In any case, I'm not too bothered about it.

[...]

--
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 02/08/2023 20:02, Bart wrote:
> On 02/08/2023 17:23, David Brown wrote:
> > On 02/08/2023 12:14, Bart wrote:
> >> 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.
> >>
> >
> > This was, IMHO, an idiotic design decision from MS.  It makes variadic
> > functions (like printf) significantly easier to implement, but seriously
> > slows down all other function calls.
>
> In what way does it slow it down?
>

It is unnecessary stack operations and a waste of cache space. How
could that be anything other than a slowdown? But if you can avoid it
on many calls, then that is very good.

>
> I never noticed that MY move from my own API, which pushed ALL
> arguments, to the Win ABI made anything much slower. It may even have
> improved matters.

x86 processors have always had a lot of extra hardware to speed up
access to the top parts of the stack. x86 compilers have often been
very poor (I don't mean yours) and the lack of registers has always been
a bottleneck, so the processor designers have excelled at making poorly
optimised code run efficiently by all sorts of hardware re-arrangements.
Sometimes code techniques that look like they should be better are
worse, and vice versa. And one critical cache miss can cost more time
than a hundred instructions would take. This is one reason why
optimisations in compilers often makes less of a difference in the x86
world than it does for ARM or other RISC designs.

>
> What did cost though was switching from a 32-bit pointer on x64, to a
> full 64-bit pointer, which on my interpreter slowed it down by 5%
> because data structures were bigger and took more memory.
>

In Linux, there was an additional ABI for a while called x32 (IIRC)
which used the bigger register and instruction set of 64-bit mode, but
had 32-bit pointers. For some kinds of code, it made quite a
significant difference (for precisely the reasons you suggest).
Overall, however, it has been judged not worth the effort to maintain
another set of binaries and libraries and it has fallen out of favour.
And of course you lose some of the extra possibilities that 64-bit
pointers provide, such as memory access sanitization and tracking
malloc/free libraries.

>
> >> 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.
> >>
> >
> > It is also possible when passing structs into and out of functions.
> > Remember also that only a small proportion of code on PC's is in C - for
> > other languages, structs or classes are passed around a great deal.
> > Smaller structs go in registers, and bigger ones go on the stack -
> > 32-bit (and smaller) types are packed tightly.
> >
> >>
> >> 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.
> >>
> >
> > Lots of numbers are bigger than 32K.  Very few are bigger than 2G.
> > Making int 32 bits made a lot of code much more convenient (and
> > magically fixed some people's overflow bugs).
>
> 64-bits would doubtless fix a few more.

A few, yes, but only a very few compared to the move to 32 bits.

>
> But it's true that the vast majority of 'don't care' integer values will
> be much smaller.
>

Yes.

> I've done a survey on one application (here I'm using an interpreter for
> my static language where I can easily add these checks),  which only
> looks at positive numbers, and there, 99.7% of values stored to i64
> memory slots would fit into a i32 range.
>
> But, then, 52% would fit into 16 bits, and 49% into 8 bits. So 32 bits
> is also too much in half the cases!
>

Still, wasting 16 bits in half the cases is a lot lower cost than
wasting 32 bits in 99.7% of the cases.

Of course, this doesn't matter if the numbers are local variables in
registers.

> On a different application, 88% would fit into 16 bits, and 62% into 8
> bits.
>
> (I'm imagine lots of the latter values are zeros. Actually, I don't need
> to imagine: it's 40% and 20% for the two programs, where ints store zeros.)
>
> However: these measurements don't cover spread, they are dynamic
> assignments, most could be to the same few variables. They don't look at
> intermediate values, or unsigned integers.
>
> They don't measure temporal spread: maybe an int holds small values 99%
> of the time, but then there is the odd large value that must be
> accommodated.
>
> So my survey was rough and ready (and my apps are probably not too
> challenging; you need people who write code that allocate huge arrays).
>
> But what 64 bits buys you is more piece of mind, and also simplicity:
> every default scalar type is the same size: signed, unsigned, double,
> pointer.
>

I think there is a lot in that - it is good for a programming language
not to force the programmer to think too much about small details. Very
often, the programmer just wants to store a number (usually they know if
it is floating point or an integer), and would much prefer not to worry
about sizes at all. It's only when storing data in structures or
matching existing structures that size really matters other than "big
enough not to overflow, small enough to be efficient". Ideally, the
language should figure that out. (C can't, but more modern and advanced
languages perhaps could.)

> I also used to think that using 64 bits was mostly wasteful (especially
> with pointers), but then, having split-level 32/64-bit types is also a
> nuisance.
>
> Since the actual costs of int64 (not 64-bit pointers) can be
> insignificant, I've stopped worrying.
>
>

Anything that makes us worry less is a good idea!

On 03/08/2023 00:25, Malcolm McLean wrote:
> On Wednesday, 2 August 2023 at 22:48:49 UTC+1, David Brown wrote:
>> On 02/08/2023 18:10, Malcolm McLean wrote:
>>> On Wednesday, 2 August 2023 at 17:05:14 UTC+1, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> On Wednesday, 2 August 2023 at 12:09:16 UTC+1, Bart wrote:
>>>>>> On 02/08/2023 11:41, Malcolm McLean wrote:
>>>>
>>>>>>> Then there's exotica such as int_fast32 _t. Which is often what you
>>>>>>> really want, but you seldom see it in real code.
>>>>> I don't use any of them in the Baby X resource compiler. Audio samples
>>>>> are saved as "short", UTF-16 values as "unsigned short". If short
>>>>> isn't 16 bits, it might or might not work, but the chances it will
>>>>> work are good. If I used int16_t, it would break if short isn't 16
>>>>> bits.
>>>> int16_t "breaks" if there is no such type, but I think such a type can
>>>> exist even if short is not 16 bits.
>>>>
>>> CHAR_BIT would have to be sixteen.
>> No, compilers can have extended integer types.
>>>>> And it would break if stdint.h isn't available. So that was an easy
>>>>> decision to make.
>>>> That rules out the type you probably want -- one of the types you say is
>>>> often what is really wanted (int_least16_t). No wonder they are rarely
>>>> seen in "real code" if people won't use them even after nearly a quarter
>>>> of a century. Are you really limiting yourself to writing C90?
>>>>
>>> It's best to restrict yourself to the conservative subset of C unless there is
>>> really a pressing reason to do otherwise.
>> Utter drivel.
>>
>> It's best to use the C version, and subset thereof, that is suitable for
>> writing good, clean code that gives efficient results and is likely to
>> work fine for all platforms for which the code is realistically going to
>> be of interest. That pretty much /never/ means C90. All you do by
>> choosing C90 is give worse quality source code, poorer efficiency in the
>> generated code, and home-made half-arsed solutions for problems that
>> were solved 25 years ago.
>>
> Efficiency in the resource compiler itself hardly matters. I tested the string
> tag on a 100,000 word novel, and it came back instantly. The string also
> compiled and printed out. Efficiency in the output code matters, but the vast
> majority of it is static data.

Quality of source code /always/ matters, unless this is a small
throw-away program.

>>> The Baby X resource compiler
>>> is designed for use with Baby X, but it might also find a niche in the
>>> toolchains of people writing for small embedded systems. Which
>>> might come with old or restricted C compilers.
>>>
>> It will /never/ happen. So don't worry about it.
>>
>> And if you were /really/ interested in obscure and outdated embedded
>> tools (and some of these are still in use), you might have tried to
>> learn a little about them - or ask someone who knows. They'd have
>> explained the difference between compilers for code running on the
>> target devices, and compilers for code running on host systems.
>>
> The Baby X resource compiler, as the name implies, is primarily intended
> for use with Baby X. Baby X uses int to represent integral values,
> double to represent real values, unsigned char to represent arbitrary
> binary data, and char * to represent strings. There's no advantage in
> using other types, except that now I'm adding audio, the PCM data will
> be represented by a short.
>

None of this will ever be of the slightest use on a platform that does
not have a good C99 compiler.

> However I took the decision to separate the resource compiler from Baby X
> so it could be used as an independent program by non-Baby X users.
> Who those would be I don't know. The big platforms come with monolithic
> buold systems which include resource compilers, and for various reasons
> it's not easy to avoid the use of the resource compiler. So I'm guessing
> small embedded systems. But I can't exactly take a job doing embedded
> programming just to get more experience for building the resource
> compiler. The output files from the Baby X resource compiler should
> compile under pretty much any C compiler out there, however.
>

Don't base important design decisions on random guesses about things you
are completely ignorant about. (Ignorance itself is not a problem -
none of us know about all kinds of programming situations. It's basing
decisions on ignorance that is the problem.)

If you are running a shoe shop, you keep all your stock in pairs. You
don't keep them in singles just in case one customer is missing a leg.

> The Baby X resource compiler itself should also compile cleanly and easily
> under any hosted system. That's also an important goal.
>

That is a completely pointless attitude.

First, is there any indication that anyone has actually used the
program? Does anyone who wants to use it, want to compile it? When I
am looking for software, if I find a possible option and see it is
written in ANSI C90, I assume it is some ancient and outdated tool. It
/might/ still be useful, but I start with a big negative bias. (I am
also biased against fad languages or obscure ones.)

In reality, people are only ever going to use a "resource compiler" on
two platforms - modern Linux, and modern Windows. And practically
everyone who wants to use it would want a binary, not the source code
(though having the source code available is also good). ".exe" format
is more important to users than ANSI C format.

On 03/08/2023 02:34, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> Having single-token aliases for the basic types is mild compared
with what
>> C actually allows:
>>
>> int long static unsigned typedef long A;
>
> C does not allow that.
>
>> In C, 1234 will have type 'int',
>
> Yes.
>
>> and 3000000000 will have type 'unsigned int',
>
> No. It might have type int; it might have type long.

You're right. Forgive me for assuming that C would actually do something
sensible here. If I run the C program below, the output is:

int for 1234
long for 3000000000
long for 9000000000000000000
other for 18000000000000000000

On Windows, long is a 32-bit signed type.

Yet if I try and print those 'long' values with "%ld", I get the wrong
results.

With the last, gcc warns it is unsigned, but shows the type as 'other'.
Since I appear to have covered all the bases concerning type, I'm
curious as to what type gcc (10.x) thinks it actually has.

If I change the _Generic macro to use u/intN_t types (see that extra
block below), the output is:

int32_t
int64_t
int64_t
other

That's now confusing, because 'int64_t' for this compiler is defined on
top of 'long long' according to stdint.h. How can that 3000000000
constant now suddenly match 'int64_t/long long' and not 'long'?

(Using Zig cc gives similar results except that 'other' is 'unsigned
long long' and 'int64_t' in the two tests. Yeah, in one it's unsigned,
in the other it's signed!)

To summarise, C assigns a type to '3000000000' which cannot accurately
represent its value (and gcc doesn't warn about it); all the more reason
why my generated C code needs those casts! DB assured me they weren't
needed.

(Yep; this language runs the world...)

>> both 32 bits.
>
> Not always.

Are we back to this again? Everyone in the world can assume that 'int'
in C is going to be 32 bits wide in pretty much every situation, but not
in this newsgroup?

You can't even take account of my posting history over 20+ years to
assume that I'm not talking about 16-bit machines or any exotic hardware?

---------------

#include <stdio.h>

#define typestr(x) \
_Generic(x, \
int:"int", \
unsigned int:"unsigned int", \
long:"long", \
unsigned long:"unsigned long", \
long long:"long", \
unsigned long long:"unsigned long long", \
short:"short", \
unsigned short:"unsigned short", \
char:"char", \
signed char:"signed char", \
unsigned char:"unsigned char", \
float:"float", \
double:"double", \
default:"other")

#include <stdint.h>
int main(void) {

puts(typestr(1234));
puts(typestr(3000000000));
puts(typestr(9000000000000000000));
puts(typestr(18000000000000000000));

printf("%ld\n", 3000000000);
printf("%ld\n", 3000000000);
printf("%ld\n", 9000000000000000000);

}

--------------------
(Needs stdint.h)

#define typestr(x) \
_Generic(x, \
int8_t:"int8_t", \
int16_t:"int16_t", \
int32_t:"int32_t", \
int64_t:"int64_t", \
uint8_t:"uint8_t", \
uint16_t:"uint16_t", \
uint32_t:"uint32_t", \
uint64_t:"int64_t", \
long:"long", \
unsigned long:"unsigned long", \
default:"other")

---------------

The following is a similar program in a language with fewer surprises
and gotchas:

println (1234).typestr
println (3'000_000'000).typestr
println (9_000'000_000'000_000'000).typestr
println (18_000'000_000'000_000'000).typestr

println 3_000_000'000
println 9_000'000_000'000_000'000
println 18_000'000_000'000_000'000

The output is:

i64
i64
i64
u64
3000000000
9000000000000000000
18000000000000000000

On 03/08/2023 10:28, David Brown wrote:
> On 02/08/2023 20:02, Bart wrote:
>> 64-bits would doubtless fix a few more.
>
> A few, yes, but only a very few compared to the move to 32 bits.
For a while I supported i128/u128 types in my language (a much better
treatment than provided by gcc's __int128_t).

While it was cool to have, I eventually dropped it for simplicity.

Because there was only one real use-case: supporting 128-bit types in
the compiler!

In C, there a schism between 32- and 64-bit integers: you have to choose
to evaluate using one or the other.

Supporting 64- and 128-bit integers, you get the same schism (or would
do if there was more demand for the bigger type), so dropping it made
that part of it simpler too.

On 03/08/2023 11:39, Bart wrote:
> On 03/08/2023 02:34, Ben Bacarisse wrote:
> > Bart <bc@freeuk.com> writes:
> >
> >> Having single-token aliases for the basic types is mild compared
> with what
> >> C actually allows:
> >>
> >> int long static unsigned typedef long A;
> >
> > C does not allow that.
> >
> >> In C, 1234 will have type 'int',
> >
> > Yes.
> >
> >> and 3000000000 will have type 'unsigned int',
> >
> > No. It might have type int; it might have type long.
>
> You're right. Forgive me for assuming that C would actually do something
> sensible here. If I run the C program below, the output is:
>
> int for 1234
> long for 3000000000
> long for 9000000000000000000
> other for 18000000000000000000
>
> On Windows, long is a 32-bit signed type.

There was a mistake in my test program:

> long long:"long", \

The string should have been "long long".

So effectively, values between 2**31 and 2**63-1 inclusive have type
int64_t, and there was no conflict when using stdint.h. (This is more
sensible, but I would have expected a uint32_t type for values in [2**31
... 2**32).)

Your comment about long however would only be correct on systems where
'long' is 64 bits.

The "other" type for the 18e18 integer constant is still shown, and
there is still a conflict about its type when using 'zig cc'.

Bart <bc@freeuk.com> writes:

> On 03/08/2023 02:34, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> Having single-token aliases for the basic types is mild compared with
> what
>>> C actually allows:
>>>
>>> int long static unsigned typedef long A;
>>
>> C does not allow that.
>>
>>> In C, 1234 will have type 'int',
>>
>> Yes.
>>
>>> and 3000000000 will have type 'unsigned int',
>>
>> No. It might have type int; it might have type long.
>
> You're right. Forgive me for assuming that C would actually do something
> sensible here.

It would annoy you more if you had been right. Using an unsigned type
would have meant that 3000000000 - 3000000001 was 4294967295 and you'd
be moaning about that.

> If I run the C program below, the output is:
>
> int for 1234
> long for 3000000000
> long for 9000000000000000000
> other for 18000000000000000000
>
> On Windows, long is a 32-bit signed type.
>
> Yet if I try and print those 'long' values with "%ld", I get the wrong
> results.

No, as you say in another reply, your test program was simply wrong.

> I see you've worked out that your program was wrong.
> To summarise, C assigns a type to '3000000000' which cannot accurately
> represent its value

Of course it doesn't!

> (and gcc doesn't warn about it); all the more reason
> why my generated C code needs those casts! DB assured me they weren't
> needed.

I don't know what you were trying to achieve, but I would not use a cast
on an integer constant. If you want the constant to have an unsigned
integer type, append a 'u'.

>>> both 32 bits.
>>
>> Not always.
>
> Are we back to this again? Everyone in the world can assume that
> 'int' in C is going to be 32 bits wide in pretty much every situation,
> but not in this newsgroup?
>
> You can't even take account of my posting history over 20+ years to
> assume that I'm not talking about 16-bit machines or any exotic
> hardware?

It was just a two word reminder to other reader to take care.

You do like to misrepresent C as often as you can, so I think a quick
reminder is in order.

--
Ben.

Bart <bc@freeuk.com> writes:

> There was a mistake in my test program:
>
>> long long:"long", \
>
> The string should have been "long long".
>
> So effectively, values between 2**31 and 2**63-1 inclusive have type
> int64_t, and there was no conflict when using stdint.h. (This is more
> sensible, but I would have expected a uint32_t type for values in [2**31
> .. 2**32).)

That's an odd expectation, but then you do hope that C is as bad as you
can imagine!

> Your comment about long however would only be correct on systems where
> 'long' is 64 bits.

Indeed. Like the one I'm using to write this.

> The "other" type for the 18e18 integer constant is still shown, and there
> is still a conflict about its type when using 'zig cc'.

I don't know what zic cc is, but gcc's treatment of 18000000000000000000
is interesting. It says

warning: integer constant is so large that it is unsigned
8 | 18000000000000000000;
| ^~~~~~~~~~~~~~~~~~~~

This warning about is good. Also, the fact that it's type does not
match any in your list is also good since the standard says the constant
should have no type. But those two together surprise me a bit -- no
type, but it's unsigned.

--
Ben.