Bart <bc@freeuk.com> writes:
>On 26/07/2023 15:41, Malcolm McLean wrote:
> > On Monday, 24 July 2023 at 22:29:52 UTC+1, Keith Thompson wrote:
> >>
> >> Do you see some concrete bad consequence of requiring two's
> >> complement?
> >>
> > It means that if future technology means that two's complement is
> > no longer the engineering choice for chip designers, then either C
> > compilers will have to lose their closeness to the metal or that standard
> > will have to be revised and current programs will break.
>
>Come on, just making 'int' 64 bits instead of 32 will already break half
>the programs out there!

Cite, please.

>Why do think it seems to have stuck at 32 bits?

Because there is no need to change it.

On 26/07/2023 16:21, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 26/07/2023 15:41, Malcolm McLean wrote:
>>> On Monday, 24 July 2023 at 22:29:52 UTC+1, Keith Thompson wrote:
>>>>
>>>> Do you see some concrete bad consequence of requiring two's
>>>> complement?
>>>>
>>> It means that if future technology means that two's complement is
>>> no longer the engineering choice for chip designers, then either C
>>> compilers will have to lose their closeness to the metal or that
standard
>>> will have to be revised and current programs will break.
>>
>> Come on, just making 'int' 64 bits instead of 32 will already break half
>> the programs out there!
>
> Cite, please.

So, there is no software that you know of that relies on 'int' being 32
bits?

I deal a lot with APIs expressed as C headers, which I have to create
bindings for. There is a preponderance of int32 types there, which is
puzzling; why int32 in particular, given it all runs on 64-bit machines?

>> Why do think it seems to have stuck at 32 bits?
>
> Because there is no need to change it.
>

Who says? Changing it would have these advantages:

* 64-bit ints would kick the signed overflow can much further down the
road. 4 billion times further to be exact. Even unsigned overflows
would benefit, because no one really wants those either, despite many
here pretending that that kind of overflow is perfectly alright.

It is extraordinary how much software seems to have a built-in +/- 2
billion limit, when a +/- 9 billion billion limit is so easy. I wonder
how many are put off by needing to write `long long int` or 'int64_t`
everywhere, or maybe people don't consider this aspect at all, or are
just lazy.

(One interesting observation when you attempt to translate C code, is
that apart from the dominance of i32 types, so many functions and
variables are needlessly exported from a module, because people are
either too lazy to write 'static`, or are just ignorant.)

* There would be no 2-level integer type where:

* 1234 has type i32, but 1234LL is needed for i64 (with 1234L being
anyone's guess). So 1 << 35 will overflow.
* Some operations are done at 32 bits, some at 64 bits
* Casts are needed to force a 64-bit evaluation
* You have to choose between "%d %ld %lld" to print anything

With a 64-bit int, all integer literals - sorry, constants - would have
an i64 or (for 2**63+) u64 type.

* In the majority of cases, ints, doubles and object and function
pointers would all have the same width

* There'd be little need for those clock_t, time_t, offset_t and myriad
other types, since i64 has a big enough range for anything. Or at
least, they can all be defined on top of 'int'

* Enums and case labels could be bigger than i32 without it being
dependent on compiler extensions

That fact is that so much software simply uses 'int' without thinking,
that has all these limitations, that it would be a no-brainer to make it
64 bits and overcome them at a stroke.

Of course it's a bit late for current 64-bit platforms which have
already made the choice, and changing it now would be very difficult.

So C is stuck with a funny 32-bit primary integer type, when the world
has been 64 bits for a couple of decades. People new to the language
might well ask, why 32 bits and not 64, and if not 64, then why not 16?

Bart <bc@freeuk.com> writes:
>
>On 26/07/2023 16:21, Scott Lurndal wrote:
> > Bart <bc@freeuk.com> writes:
> >> On 26/07/2023 15:41, Malcolm McLean wrote:
> >>> On Monday, 24 July 2023 at 22:29:52 UTC+1, Keith Thompson wrote:
> >>>>
> >>>> Do you see some concrete bad consequence of requiring two's
> >>>> complement?
> >>>>
> >>> It means that if future technology means that two's complement is
> >>> no longer the engineering choice for chip designers, then either C
> >>> compilers will have to lose their closeness to the metal or that
>standard
> >>> will have to be revised and current programs will break.
> >>
> >> Come on, just making 'int' 64 bits instead of 32 will already break half
> >> the programs out there!
> >
> > Cite, please.
>
>So, there is no software that you know of that relies on 'int' being 32
>bits?

So, you don't have any supporting evidence for your assertion. Noted.

>
>I deal a lot with APIs expressed as C headers, which I have to create
>bindings for. There is a preponderance of int32 types there, which is
>puzzling; why int32 in particular, given it all runs on 64-bit machines?

I've never seen an 'int32' type in any C or C++ code I've worked
with (and it's in the millions of lines by now). int32_t, yes. uint32_t,
yes. Which are the proper types to use when the programmer needs
a type with the corresponding attributes (width, signedness, etc).

>
>
> >> Why do think it seems to have stuck at 32 bits?
> >
> > Because there is no need to change it.
> >
>
>Who says? Changing it would have these advantages:
>
>* 64-bit ints would kick the signed overflow can much further down the

I, personally, haven't experienced any issues with signed overflow;
primarily because I very seldom actually use 'int' types in C or C++
myself.

Granted, I mainly do systems programming, not financial programming,
but then I'd argue that C/C++ aren't designed as financial programming
languages in the first place - use the right tool for the job.

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

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

If you are going be so literal, you need to explain how "" (in C) is "of
letters". And, since you presumably consider "123" to be "of letters",
why calling 123 an "integer literal" would be wrong. Anyway, technical
uses of words like literal are almost always figurative!

--
Ben.

Spiros Bousbouras <spibou@gmail.com> writes:

> On Tue, 25 Jul 2023 16:41:30 +0100
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>
>> Maybe the problem is partly the words. For example, testing for
>> overflow at run time can be easier with a defined incorrect result.
>>
>> Another comes from the simplicity of defining the semantics of + (and -
>> and * and so on). Having a+b be the sum of a+b or "bottom" is messier
>> than having it be (a+b) mod 2^width. (It's not the usual mod, it's a
>> biased one, but that does not really complicate matters too much.)
>>
>> Finally, there are cases that just don't need much thought. In BCPL one
>> writes (wrote?)
>>
>> LET mid = (low + high) / 2
>>
>> and there's no need to worry about overflow.

Note this is, while not actually wrong (it's from real code), is
irrelevant as an example since all the quantities were being treated as
pointers.

> And in C one can write
> mid = low + (high-low)/2 ;
>
> and not worry about overflow either. I find the latter easier to reason
> about too.

That can overflow using signed ints. In truth it was a bad example
because BCPL pointer arithmetic is not really signed or unsigned -- it
just works. And in C one could use unsigned offsets and not worry about
overflow.

>> I used to hope that by the 21st century we'd all be using various high
>> level languages where programmers could declare sub-ranges with whatever
>> arithmetic and overflow semantics made sense for the application,
>> including unbounded integers is that's what was wanted. And along-side
>> those we'd have tools to help in verification of these type
>> restrictions.
>
> Doesn't Ada give you some of this ? You can certainly write code in Ada
> with a proof of correctness but it takes too much time so I don't think that
> people do it much in Ada either. But see
> https://www.adacore.com/academia/projects/ironsides-secure-dns-server .

Yes, it does. I've not used it in anger, so I don't know how helpful it
really is. I suspect the rigour is intimidating.

> Generally , writing a computer verifiable proof means writing out a huge
> number of annoying little details and on most occasions there is not enough
> incentive to do that , either in computer programming or mathematics.

Agreed. Part of my hope was that not only would this spread to other
languages, it would offer a degree of informality that would make is
more user-friendly. When I "reason" about code fragments, I often don't
want a formal proof; I just want some help with the symbology and some
of the checking.

> The
> only change I can see is if AIs become good enough to write such proofs
> and feed them to a non AI programme.

Interesting. I'd not thought of that. Generative AI might be very good
at filling in boilerplate details.

--
Ben.

Spiros Bousbouras <spibou@gmail.com> writes:

> But perhaps someone can explain why in BCPL you can write
>
> LET mid = (low + high) / 2
>
> without "much thought".

Ah, it was a dreadful example. I copied it from an old binary search
program that I used to use as an example for the care needed when
writing C. But it's been so long I had forgotten the context and the
context is that mid, low and high are pointers. BCPL just adds the
bits. Whether a pointer ever compares < 0 (i.e. if has the bit pattern
of a negative integer) makes no difference to the result in some
implementation, but in others it might.

So it's a bad example, and some thought is certainly needed to be sure
it's OK.

--
Ben.

On 26/07/2023 19:41, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:

#include <stdint.h>
typedef int32_t int32;

>> On 26/07/2023 16:21, Scott Lurndal wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 26/07/2023 15:41, Malcolm McLean wrote:
>>>>> On Monday, 24 July 2023 at 22:29:52 UTC+1, Keith Thompson wrote:
>>>>>>
>>>>>> Do you see some concrete bad consequence of requiring two's
>>>>>> complement?
>>>>>>
>>>>> It means that if future technology means that two's complement is
>>>>> no longer the engineering choice for chip designers, then either C
>>>>> compilers will have to lose their closeness to the metal or that
>> standard
>>>>> will have to be revised and current programs will break.
>>>>
>>>> Come on, just making 'int' 64 bits instead of 32 will already
break half
>>>> the programs out there!
>>>
>>> Cite, please.
>>
>> So, there is no software that you know of that relies on 'int' being 32
>> bits?
>
> So, you don't have any supporting evidence for your assertion. Noted.

So, *your* assertion is that you could simpy make `int` 64 bits
overnight, and most software could just be recompiled and still work
perfectly. Noted.

>> I deal a lot with APIs expressed as C headers, which I have to create
>> bindings for. There is a preponderance of int32 types there, which is
>> puzzling; why int32 in particular, given it all runs on 64-bit machines?
>
> I've never seen an 'int32' type in any C or C++ code I've worked
> with (and it's in the millions of lines by now).

You haven't looked much then. I've seen ANY NUMBER of variations based
around the `int32` and `i32` styles, created using typedefs, mainly
because people can't stand the built-in denotations of C, or wanted
something more stable.

So if someone talks about C and 'int32' at the same time, it really is
not hard to infer what the hell is is they're talking about.

You're turning into as much as a pedantic as the other guys. Usenet
articles are not source code, they're usually in English.

But if you genuinely have not got a clue, I've put a suitable typedef
for you at the top. Just don't try and compile this post, becase if is
not valid C code.

Jesus. Or is the intention here just to wind me up? Because it's worked!

>> * 64-bit ints would kick the signed overflow can much further down the
>
> I, personally, haven't experienced any issues with signed overflow;>
primarily because I very seldom actually use 'int' types in C or C++
> myself.

OK. Think about /why/ you avoid using 'int' types, then think about
those who do, which is going to be in the millions. All of those, of any
range of skill and experience, will of course have carefully weighed the
pros and cons of their decisions, and will have factored in the possible
switch of `int` to a 64-bit type in the future.

(I'd be curious as to what actual types you use where the problems of
overflow vanish, but never mind, it's going to be just another
belittling remark.)

On 26/07/2023 21:55, Ben Bacarisse wrote:
> Spiros Bousbouras <spibou@gmail.com> writes:
>
>> On Tue, 25 Jul 2023 16:41:30 +0100
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> Maybe the problem is partly the words. For example, testing for
>>> overflow at run time can be easier with a defined incorrect result.
>>>
>>> Another comes from the simplicity of defining the semantics of + (and -
>>> and * and so on). Having a+b be the sum of a+b or "bottom" is messier
>>> than having it be (a+b) mod 2^width. (It's not the usual mod, it's a
>>> biased one, but that does not really complicate matters too much.)
>>>
>>> Finally, there are cases that just don't need much thought. In
BCPL one
>>> writes (wrote?)
>>>
>>> LET mid = (low + high) / 2
>>>
>>> and there's no need to worry about overflow.
>
> Note this is, while not actually wrong (it's from real code), is
> irrelevant as an example since all the quantities were being treated as
> pointers.

Why can't pointer values overflow when added together?

>> And in C one can write
>> mid = low + (high-low)/2 ;
>>
>> and not worry about overflow either. I find the latter easier to reason
>> about too.
>
> That can overflow using signed ints. In truth it was a bad example
> because BCPL pointer arithmetic is not really signed or unsigned -- it
> just works. And in C one could use unsigned offsets and not worry about
> overflow.

I thought unsigned overflow in C was just well-defined in the language,
not that it was rendered impossible!

If I run this code:

#include <stdio.h>

int main(void) {
unsigned int low = 0xC0000000;
unsigned int high = 0xE0000000;
unsigned int mid = (low + high)/2;

printf("%X\n", mid);
}

I'd really expected `mid` here to have the value 0xD0000000, instead it
prints out 0x50000000.

So, that's nothing to worry about?

OK ....

BTW if I change the types to 'unsigned long long int` (phew, there's a
reason people write 'u64' for short!), then it magically gives the value
I expect. That's OK too when behaviour changes dramatically like that?

Nothing at all to do with overflow, because that's impossible of course...

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Wednesday, 26 July 2023 at 11:17:46 UTC+1, Bart wrote:
>> On 26/07/2023 08:21, Malcolm McLean wrote:
[...]
>> > The word "literal" means "of letters". So in this case C has it
>> > right, the other languages have it wrong.
>> Does it? I can't find that meaning anywhere.
>>
>> The main definition for the /noun/ literal is that it means a misprint,
>> or a wrong letter.
>>
> It's an unusual sense. Usually the word means "not figurative", as in
> "a literal velvet glove". But in the C standard, a "string literal" obviously
> means "a string composed of letters".

No, it very obviously does not.

> The stem "liter" means "letter",
> for the Latin "litera".

In non-technical English, "literal" is almost always an adjective,
meaning "non-figurative". There's also a meaning as a noun which is
fairly obscure (I wasn't aware of it until recently).

In programming, the noun "literal" very commonly refers to what C calls
a "constant", or to a "string literal". (You won't find that meaning in
most non-technical dictionaries.) The fact that it's a cognate of the
Latin word for "letter" is hardly relevant. Or would you argue that
"abc" is a literal and "123" isn't?

In common technical jargon, 123 is an integer literal, and that's the
standard-defined techical term for it in many languages. C calls
it an integer constant (and I therefore prefer to use that term
when discussing C).

--
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 25/07/2023 16:41, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> If overflow is fully defined behaviour, then it is part of the language.
>>> It is now normal behaviour in normal code, not an indication of an
>>> error.
>>
>> a[i + 1] is an error if i is 2 and the array and only three elements.
>> You are privileging one small kind of error as one we might want help
>> finding.
>
> That's the kind of UB which is genuinely undefined, as the result can be
> unpredictable: it may return garbage, or may give a memory error if outside
> an allocation. (It could also be well-defined, IMV at least, if the
> 3-element array is in the middle of a struct or union.)

If you were any other poster I would say that I think the word
"behaviour" in "undefined behaviour" has led you to misunderstand the
term. But I can't figure out how, after all these years, you don't know
what the term means. Are you deliberately misusing it just to get
people to chat (AKA trolling) or do you really no know?

--
Ben.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Monday, 24 July 2023 at 22:29:52 UTC+1, Keith Thompson wrote:
>> Do you see some concrete bad consequence of requiring two's
>> complement?
>>
> It means that if future technology means that two's complement is
> no longer the engineering choice for chip designers, then either C
> compilers will have to lose their closeness to the metal or that standard
> will have to be revised and current programs will break.

That's hypothetical, not concrete.

I see this a similar to the change (in C99, I think?) that added
a guarantee that all-bits-zero is a valid representation of 0 for
any integer type. The change (slightly) simplified the language
and was possible because all implementations already satisified
the guarantee.

Or to the change in C99 that eliminated all signed integer
representations other than sign and magnitude, two's complement,
and ones' complement (though C90 had requirements might already
have implicitly precluded any other reprsentation).

Apparently the editors of the standard felt that it was unlikely that
any future hardware would use something other than two's-complement.
Do you have any reason to think they were mistaken?

--
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:
[...]
> I thought unsigned overflow in C was just well-defined in the
> language, not that it was rendered impossible!

The way the C standard describes it is that unsigned operations cannot
overflow. Rather, if the mathematical result of an unsigned operation
is outside the range of the type, the result is reduced modulo MAX+1.

The actual wording is in N1570 6.2.5p9:

A computation involving unsigned operands can never overflow,
because a result that cannot be represented by the resulting
unsigned integer type is reduced modulo the number that is one
greater than the largest value that can be represented by the
resulting type.

The standard could equivalently have referred to this as "overflow" and
stated that the result of an unsigned overflow is well defined.

The fact that the standard chose one of two equivalent ways to describe
the same semantics is not, in my opinion, a big deal.

> If I run this code:
>
> #include <stdio.h>
>
> int main(void) {
> unsigned int low = 0xC0000000;
> unsigned int high = 0xE0000000;
> unsigned int mid = (low + high)/2;
>
> printf("%X\n", mid);
> }
>
> I'd really expected `mid` here to have the value 0xD0000000, instead
> it prints out 0x50000000.

If that's what you expected, (assuming 32-bit unsigned int), your
expectation was mistaken -- and it's based on an example that Ben
has already acknowledged was a bad one.

[...]

--
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 26/07/2023 21:55, Ben Bacarisse wrote:
>> Spiros Bousbouras <spibou@gmail.com> writes:
>>
>>> On Tue, 25 Jul 2023 16:41:30 +0100
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> Maybe the problem is partly the words. For example, testing for
>>>> overflow at run time can be easier with a defined incorrect result.
>>>>
>>>> Another comes from the simplicity of defining the semantics of + (and -
>>>> and * and so on). Having a+b be the sum of a+b or "bottom" is messier
>>>> than having it be (a+b) mod 2^width. (It's not the usual mod, it's a
>>>> biased one, but that does not really complicate matters too much.)
>>>>
>>>> Finally, there are cases that just don't need much thought. In BCPL
> one
>>>> writes (wrote?)
>>>>
>>>> LET mid = (low + high) / 2
>>>>
>>>> and there's no need to worry about overflow.
>>
>> Note this is, while not actually wrong (it's from real code), is
>> irrelevant as an example since all the quantities were being treated as
>> pointers.
>
> Why can't pointer values overflow when added together?

BCPL defines the bit pattern that results from adding them, dividing
etc. There's no overflow in that sense. The resulting address may not
make sense so you still have to take care. That's why it was crap
example.

>>> And in C one can write
>>> mid = low + (high-low)/2 ;
>>>
>>> and not worry about overflow either. I find the latter easier to reason
>>> about too.
>>
>> That can overflow using signed ints. In truth it was a bad example
>> because BCPL pointer arithmetic is not really signed or unsigned -- it
>> just works. And in C one could use unsigned offsets and not worry about
>> overflow.
>
> I thought unsigned overflow in C was just well-defined in the language, not
> that it was rendered impossible!

Yes, it's impossible in C. But that's C using the word very narrowly --
overflow is an exception condition that only happens with signed
arithmetic. But one could, in a conversation in the pub, say that
"unsigned arithmetic overflow is defined to wrap". (You could say that
here as well, because the sentence makes it pretty clear how the words
are bring used.)

> If I run this code:
>
> #include <stdio.h>
>
> int main(void) {
> unsigned int low = 0xC0000000;
> unsigned int high = 0xE0000000;
> unsigned int mid = (low + high)/2;
>
> printf("%X\n", mid);
> }
>
> I'd really expected `mid` here to have the value 0xD0000000, instead it
> prints out 0x50000000.
>
> So, that's nothing to worry about?

Overflow is nothing to worry about, by the values wrap (technically, the
result is reduced modulo UINT_MAX+1). With unsigned offsets, low +
(high-low)/2 is fine.

--
Ben.

On 2023-07-26, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On Wednesday, 26 July 2023 at 11:17:46 UTC+1, Bart wrote:
>>> On 26/07/2023 08:21, Malcolm McLean wrote:
> [...]
>>> > The word "literal" means "of letters". So in this case C has it
>>> > right, the other languages have it wrong.
>>> Does it? I can't find that meaning anywhere.
>>>
>>> The main definition for the /noun/ literal is that it means a misprint,
>>> or a wrong letter.
>>>
>> It's an unusual sense. Usually the word means "not figurative", as in
>> "a literal velvet glove". But in the C standard, a "string literal" obviously
>> means "a string composed of letters".
>
> No, it very obviously does not.
>
>> The stem "liter" means "letter",
>> for the Latin "litera".
>
> In non-technical English, "literal" is almost always an adjective,
> meaning "non-figurative". There's also a meaning as a noun which is
> fairly obscure (I wasn't aware of it until recently).

In ordinary English, there is a process by which adjectives
are used as nouns.

This seems to happen quite a bit with "ible"/"able" adjectives, but
others too.

One way it happens is that in some context, a certain noun occurs
with a certain adjective, and that noun can be understood:

E.g. "deliverable goods" become "deliverables"; "perishable goods"
"perishables"; "dirigible balloon" becomes "dirigible"; "submersible
vessel" becomes "submersible"; "convertible roof car" becomes
"convertible"; people Hilary Clinton doesn't like become "deplorable".

Classes of thing are referred by adjectives: the rich, the poor,
the wretched.

Certain expressions: "The long and the short of it is ...",
"through thick and thin".

"I'm with stupid."

English-speaking computer scientists simply followed this process in
dropping the word "constant" from "literal constant".

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

On 27/07/2023 01:06, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 25/07/2023 16:41, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> If overflow is fully defined behaviour, then it is part of the
language.
>>>> It is now normal behaviour in normal code, not an indication of an
>>>> error.
>>>
>>> a[i + 1] is an error if i is 2 and the array and only three elements.
>>> You are privileging one small kind of error as one we might want help
>>> finding.
>>
>> That's the kind of UB which is genuinely undefined, as the result can be
>> unpredictable: it may return garbage, or may give a memory error if
outside
>> an allocation. (It could also be well-defined, IMV at least, if the
>> 3-element array is in the middle of a struct or union.)
>
> If you were any other poster I would say that I think the word
> "behaviour" in "undefined behaviour" has led you to misunderstand the
> term. But I can't figure out how, after all these years, you don't know
> what the term means. Are you deliberately misusing it just to get
> people to chat (AKA trolling) or do you really no know?
>

I genuinely don't know what you're getting at here.

But I acknowledge I'm not a 'standards-head', as most here seem to be.
Is that now a prerequisite to giving an opinion here?

I use the language for practical reasons, and I think most people who
use it who have probably never delved into the standards document either.

But I also, because I've spent a LOT of time using alternates that I
have devised, like to look at it from a different perspective and with
less reverence that most.

As for trolling, people pretending they don't have a clue what is meant
by 'i32' or 'int32', or don't know what is meant by 'integer literal',
might fall better into that category.

To get back to my point, I will reassert that I think that:

*(int*)1234567

is what I would call 'undefined behaviour', since I couldn't tell you
what would happen if executed.

But evaluating:

INT_MAX+1

is NOT what I would call 'undefined behaviour'; whatever unexpected
things you might observe in such programs, is the deliberate intention
of the compiler. Since actual hardware UB on signed overflow is rare.

Bart <bc@freeuk.com> writes:
[...]
> To get back to my point, I will reassert that I think that:
>
> *(int*)1234567
>
> is what I would call 'undefined behaviour', since I couldn't tell you
> what would happen if executed.
>
> But evaluating:
>
> INT_MAX+1
>
> is NOT what I would call 'undefined behaviour'; whatever unexpected
> things you might observe in such programs, is the deliberate intention
> of the compiler. Since actual hardware UB on signed overflow is rare.

Would you consider using a term other than "undefined behavio[u]r" for
whatever it is you're referring to?

If not, is it because you're being intentionally difficult?

(These are both serious questions.)

--
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 27/07/2023 01:06, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 25/07/2023 16:41, Ben Bacarisse wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>> If overflow is fully defined behaviour, then it is part of the
> language.
>>>>> It is now normal behaviour in normal code, not an indication of an
>>>>> error.
>>>>
>>>> a[i + 1] is an error if i is 2 and the array and only three elements.
>>>> You are privileging one small kind of error as one we might want help
>>>> finding.
>>>
>>> That's the kind of UB which is genuinely undefined, as the result can be
>>> unpredictable: it may return garbage, or may give a memory error if
> outside
>>> an allocation. (It could also be well-defined, IMV at least, if the
>>> 3-element array is in the middle of a struct or union.)
>>
>> If you were any other poster I would say that I think the word
>> "behaviour" in "undefined behaviour" has led you to misunderstand the
>> term. But I can't figure out how, after all these years, you don't know
>> what the term means. Are you deliberately misusing it just to get
>> people to chat (AKA trolling) or do you really no know?
>
> I genuinely don't know what you're getting at here.

Do you know what undefined behaviour, in the context of the C language
means? It's not a trick question. I assumed you must know, but maybe
you don't.

> To get back to my point, I will reassert that I think that:
>
> *(int*)1234567
>
> is what I would call 'undefined behaviour', since I couldn't tell you what
> would happen if executed.

It would be absurd if the term depended on what you can tell about what
would happen. So you must know that this can't be what it means in the
context of the C language.

--
Ben.

On 2023-07-25, Bart <bc@freeuk.com> wrote:
> On 25/07/2023 16:41, Ben Bacarisse wrote:
> > David Brown <david.brown@hesbynett.no> writes:
> >> If overflow is fully defined behaviour, then it is part of the language.
> >> It is now normal behaviour in normal code, not an indication of an
> >> error.
> >
> > a[i + 1] is an error if i is 2 and the array and only three elements.
> > You are privileging one small kind of error as one we might want help
> > finding.
>
> That's the kind of UB which is genuinely undefined, as the result can be
> unpredictable: it may return garbage, or may give a memory error if
> outside an allocation. (It could also be well-defined, IMV at least, if
> the 3-element array is in the middle of a struct or union.)

Undefined in the context of the C language means "ISO-C-undefined".

It refers to situations in C programs for which ISO C doesn't specify
requirements.

Negative defined categories have a diverse membership, and the members
don't necessarily have a lot in common.

Consider the set of non-bicycle entities. Among them are fish, as well
as communism.

Undefined behavior is like this.

When you say "genuinely undefined", you probably mean something like
behavior for which no requirements are given by anone: not ISO C,
not the compiler vendor, not the hardware, nobody.

Then we are not using the term "undefined" as "ISO-C-Undefined".

If you do that, you have to be clear: not defined according to whom?

If we include the header <unistd.h> and call a function
read(STDIN_FILENO, buf, sizeof buf), that is undefined behavior
(ISO-C-Undefined behavior). However, it is defined behavior according
to POSIX (POSIX-C-Defined-Behavior).

Would that be an example of "not genuinely undefined"?

> But any UB due to integer overflow would be largely caused by a compiler
> deliberately invoking a certain behaviour because the UB tag gives it
> the licence to do so.

ISO-C-Undefined-behavior on integer overflow is caused by exactly one
thing: ISO C not defining the behavior.

If Foo-C compiler behaves in some documented way on integer overflow, then
the behavior is ISO-C-Undefined, but Foo-C-Defined.

If the Foo-C compiler has no documentation about what happens on integer
overflow, but you have the source code and are able to reverse
engineer what happens, and it makes some consistent sense, and you write
a document about it, then that can be BartC-Foo-C-Defined-Behavior
(with respect to those versions of the code you studied).

Similarly if you don't have source, but can reverse engineer the
Foo-C executable.

In this reverse engineering role, your definition has limited authority.
You don't know whether every installation of that compiler claiming
to be a certain version really is the same as the deliverables you
are working with.

Anyway, if we pin down who it is who is providing the definition of
behavior, and what is their role in assuring it, it becomes very clear.

It's usually best to look for positive confirmation of defined behavior.
If we can't find it, then we can conclude that the behavior is
undefined (in the sense of not defined by anyone; perhaps what you
are calling "genuinely").

I'm doing such and such in my program. What is the basis in my belief
that it ought to work? If it's required by ISO C, then that's it.
What if it isn't? Maybe it's defined by the compiler, or host
environment (such as POSIX).

If it's not defined by the compiler, why is it working anyway? Maybe due
to the way I know the technology works, there is no possible way the
compiler can prevent it from working.

For instance, if I know that a compiler works with translation units
in complete isolation and performs no optimizataions in linking,
then it has no way of telling that I'm referring to the same object
using two different structure types in different translation units,
which happen to be binary compatible. So my definition of behavior
can come from belief in the argument that it's impossible for the
program to break. I document for future maintainers that the code
depends on that assumption.

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

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

But in this case, the C standard gets the accepted meaning of the word right.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> C source is human-readable. So in a sense, everything in the source
> code is "literal". So in the statement int x = 123; we can say that
> "123" is a "literal" if we want. But only if we also accept that
> "int", "x" and "=" are also "literals". Alos we'd have to say that in
> the statement char *filename = 0; filename is a "literal" and has a
> "literal' value.
> That's not particularly helpful.

No argument with that last sentence.

> So we can say that when we say "of letters", we don't mean the source,
> but the executable. A string literal is a string (of letters, embedded
> in the executable). int x = 123 will store that value 123 somewhere in
> the executable, but not in a representation "of letters". The core
> language C doesn't understand that 123 and "123" refer to the same
> value (of course the standard library does have functions which make
> this conversion).
> So char *str = "123"; is a string literal, int x = 123; is an integer
> constant, not an "integer literal". In fact str is a "literal integer"
> (an integer composed of letters), though the term isn't in common use.
>
> But in this case, the C standard gets the accepted meaning of the word right.

What the what??

First off, C's use of the word "literal" has nothing to do with letters.
(Yes, I acknowledge that the English words are cognates.) C has two
kinds of literals: string literals and compound literals. Nothing else
in C is called a "literal" (though, as we've discussed to death, numeric
constants are commonly and informally called "literals" as well).

Second, I'm getting the impression that you're using the word
"letter" in some (deliberately?) misleading sense. In C, there are
26 uppercase letters and 26 lowercase letters; nothing else is a
"letter" as defined by the standard. (Read N1570 5.2.1 if you don't
believe me.) What you wrote above could only approach making sense
if you're using "letter" to refer to something else.

Are we going to have to add a "Malcolm-" prefix to every term you use?

--
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-07-27, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On Wednesday, 26 July 2023 at 21:19:55 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> > The word "literal" means "of letters". So in this case C has it right, the
>> > other languages have it wrong.
>> If you are going be so literal, you need to explain how "" (in C) is "of
>> letters". And, since you presumably consider "123" to be "of letters",
>> why calling 123 an "integer literal" would be wrong. Anyway, technical
>> uses of words like literal are almost always figurative!
>>
> C source is human-readable. So in a sense, everything in the source code
> is "literal". So in the statement int x = 123; we can say that "123" is a "literal"
> if we want. But only if we also accept that "int", "x" and "=" are also "literals".
> Alos we'd have to say that in the statement char *filename = 0; filename is a
> "literal" and has a "literal' value.

A literal is a piece of the program text which specifies data that is available
to the program. If a piece of program text doesn't specify a datum that is
available to the program, it's almost certainly not a literal.

The Lisp family of languages, particularly traditional Lisps, any the
program syntax can be turned into a literal by making it the argument of
the quote operator (where the quote operator syntax appears in a context
where it is evaluated as an expression).

E.g (defun add (x y) (+ x y)) is the syntax for a function definition
in Common Lisp, but (quote (defun add (x y) (+ x y))) is not a function
definition at all; provides access to the literal data (defun add (x y)
(+ x y)), This can be written '(defun add (x y) (+ x y)).

In Common Lisp, and some other dialects, the behavior is undefined
if you modify a literal, e.g (rplacd '(a . b) 3). This is similar
to "ab"[1] = 3 in C being undefined behavior. It is self-modifying
code, since the literal is part of the program's image: a piece of
itself.

So, yes, if C had a quote feature, then x = 123 could be a literal.

To a C compiler, "x = 123" is just data; characters, then tokens, then
part of a syntax tree. It's not a literal to that compiler because it's
not a piece of the compiler image. C doesn't have a quote feature for
code, so "x = 123" is never turned into a literal in the compiled
program. It's translated into code in which there is no equal sign, and
possibly no x either.

We can see concretely in a Lisp what is a literal and what isn't.

We compile the top-level expression

(defun f (x)
(append '(1 2 3) x '(4 5 6)))

which, if executed, defines a function.

This is the TXR Lisp interactive listener of TXR 289.
Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
If unwanted side effects persist, discontinue imperative programming.
1> (compile-toplevel
'(defun f (x)
(append '(1 2 3) x '(4 5 6))))
#<sys:vm-desc: 8d28a70>
2> (disassemble *1)
data:
0: f
1: (1 2 3)
2: (4 5 6)
syms:
0: sys:rt-defun
1: append
code:
0: 8C000009 close t4 0 4 9 1 1 nil t2
1: 00000004
2: 00010001
3: 00000004
4: 00000002
5: 20030003 gcall t3 1 d1 t2 d2
6: 04010001
7: 04020002
8: 10000003 end t3
9: 20020002 gcall t2 0 d0 t4
10: 04000000
11: 00000004
12: 10000002 end t2
instruction count:
5
#<sys:vm-desc: 8d28a70>

In the compiled image (a "VM descriptor" object which we can disassemble) we
see there are three literal registers. There are three literals: f, (1 2 3)
and (4 5 6). Thewse are found in the original expression, but not everything
in the orginal expression is a literal. For instance the (append ...)
expression does not appear as a literal.

The reason the symbol f appears as a literal is that it is needed for
defining the function. The instruction gcall t2 0 d0 t4 calls sys:rt-defun
(entry 0 in the symbol table), passing it d0 (which holds f) and t4,
which holds the lexical closure object from the close instruction.

The f function is instruction words 4-8.

So, we can see that only those parts of the syntax become literals
which are required to be available that way, due to being quoted
somehow, explicitly or implicitly (as in the case of f).

The other parts of the function definition are semantically analyzed and turn
into a different representation; like (append ...) becomes a gcall t3 1 d1 t2
d2 instruction, from which the original code is not available as a literal;
the append symbol doesn't appear anywhere in the translated image.

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

On Thursday, 27 July 2023 at 05:50:00 UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> [...]
> > C source is human-readable. So in a sense, everything in the source
> > code is "literal". So in the statement int x = 123; we can say that
> > "123" is a "literal" if we want. But only if we also accept that
> > "int", "x" and "=" are also "literals". Alos we'd have to say that in
> > the statement char *filename = 0; filename is a "literal" and has a
> > "literal' value.
> > That's not particularly helpful.
> No argument with that last sentence.
> > So we can say that when we say "of letters", we don't mean the source,
> > but the executable. A string literal is a string (of letters, embedded
> > in the executable). int x = 123 will store that value 123 somewhere in
> > the executable, but not in a representation "of letters". The core
> > language C doesn't understand that 123 and "123" refer to the same
> > value (of course the standard library does have functions which make
> > this conversion).
> > So char *str = "123"; is a string literal, int x = 123; is an integer
> > constant, not an "integer literal". In fact str is a "literal integer"
> > (an integer composed of letters), though the term isn't in common use.
> >
> > But in this case, the C standard gets the accepted meaning of the word right.
> What the what??
>
> First off, C's use of the word "literal" has nothing to do with letters.
> (Yes, I acknowledge that the English words are cognates.) C has two
> kinds of literals: string literals and compound literals. Nothing else
> in C is called a "literal" (though, as we've discussed to death, numeric
> constants are commonly and informally called "literals" as well).
>
> Second, I'm getting the impression that you're using the word
> "letter" in some (deliberately?) misleading sense. In C, there are
> 26 uppercase letters and 26 lowercase letters; nothing else is a
> "letter" as defined by the standard. (Read N1570 5.2.1 if you don't
> believe me.) What you wrote above could only approach making sense
> if you're using "letter" to refer to something else.
>
> Are we going to have to add a "Malcolm-" prefix to every term you use?
>
You can argue that char *str = "123" is not a string of letters because digits
are not letters, and if you were using the term normally then that's what you
might mean. But I'm using "of letters" as a drop-in for "literal", to show you
that that's what it means. "Litera", Latin "letter" so "literal", "of letters".

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Thursday, 27 July 2023 at 05:50:00 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> [...]
>> > C source is human-readable. So in a sense, everything in the source
>> > code is "literal". So in the statement int x = 123; we can say that
>> > "123" is a "literal" if we want. But only if we also accept that
>> > "int", "x" and "=" are also "literals". Alos we'd have to say that in
>> > the statement char *filename = 0; filename is a "literal" and has a
>> > "literal' value.
>> > That's not particularly helpful.
>> No argument with that last sentence.
>> > So we can say that when we say "of letters", we don't mean the source,
>> > but the executable. A string literal is a string (of letters, embedded
>> > in the executable). int x = 123 will store that value 123 somewhere in
>> > the executable, but not in a representation "of letters". The core
>> > language C doesn't understand that 123 and "123" refer to the same
>> > value (of course the standard library does have functions which make
>> > this conversion).
>> > So char *str = "123"; is a string literal, int x = 123; is an integer
>> > constant, not an "integer literal". In fact str is a "literal integer"
>> > (an integer composed of letters), though the term isn't in common use.
>> >
>> > But in this case, the C standard gets the accepted meaning of the word right.
>> What the what??
>>
>> First off, C's use of the word "literal" has nothing to do with letters.
>> (Yes, I acknowledge that the English words are cognates.) C has two
>> kinds of literals: string literals and compound literals. Nothing else
>> in C is called a "literal" (though, as we've discussed to death, numeric
>> constants are commonly and informally called "literals" as well).
>>
>> Second, I'm getting the impression that you're using the word
>> "letter" in some (deliberately?) misleading sense. In C, there are
>> 26 uppercase letters and 26 lowercase letters; nothing else is a
>> "letter" as defined by the standard. (Read N1570 5.2.1 if you don't
>> believe me.) What you wrote above could only approach making sense
>> if you're using "letter" to refer to something else.
>>
>> Are we going to have to add a "Malcolm-" prefix to every term you use?
>>
> You can argue that char *str = "123" is not a string of letters because digits
> are not letters, and if you were using the term normally then that's what you
> might mean. But I'm using "of letters" as a drop-in for "literal", to show you
> that that's what it means. "Litera", Latin "letter" so "literal", "of letters".

If you're not going to address anything I wrote, it would save time if
you just said so.

If you're trying to let me know something, you've failed. I'm ok with
that if you are.

--
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 27/07/2023 03:17, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>

>> I genuinely don't know what you're getting at here.
>
> Do you know what undefined behaviour, in the context of the C language
> means? It's not a trick question. I assumed you must know, but maybe
> you don't.

AIUI it means that C chooses not to define some behaviour. You can leave
it there, or you can be more critical (or pragmatic), and ask questions
about why something is UB rather than implementation-defined, or why it
is UB at all, since it could be for historical reasons that no longer
apply, or for very unusual machines.

Most here will just take what the C standard says at face value. But if
you're an implementer (and actually, I'm one too!) then you have to make
a decision about what to do about things the standard says is undefined.

One UB I know about very well is signed integer overflow, which I
normally implement as wrapping. Another might be strict aliasing, which
doesn't really affect how I generate code.

In both cases compilers may seize on UB to allow them to omit
instructions in an attempt to generate slightly faster code (even though
my experiment with -fwrapv showed UB-based to be slower!).

This now puts the onus on users to pay more heed to UB, and be aware of
gotchas where the code no longer does what might seem obvious, since a
compiler might do something unexpected. And now you have to refactor
your code to work around that possible behaviour of the compiler.

To me that is undesirable. (How about taking code that appears to do an
obvious thing, and ensuring that that's exactly what it does?)

BTW, by users, I also have in mind the many languages that use C as an
intermediate language. There, there might be a source language where
some feature that is UB in C, is well-defined, and where it is known to
be well-defined on the desired target.

However, in between the two you have to go through C! Now such UB is a
nuisance.

>> To get back to my point, I will reassert that I think that:
>>
>> *(int*)1234567
>>
>> is what I would call 'undefined behaviour', since I couldn't tell
you what
>> would happen if executed.
>
> It would be absurd if the term depended on what you can tell about what
> would happen.

Why is it absurd? Because I use actual observation and reasoning rather
than just decreeing within a standards document that something is UB
because it just is? /That's/ absurd!

(Is there a Rationale document explaining the reasons behind all the
UB's of C?)

On 26/07/2023 23:07, Bart wrote:
> On 26/07/2023 19:41, Scott Lurndal wrote:
> > Bart <bc@freeuk.com> writes:
>
> #include <stdint.h>
> typedef int32_t int32;
>
> >> On 26/07/2023 16:21, Scott Lurndal wrote:
> >>> Bart <bc@freeuk.com> writes:
> >>>> On 26/07/2023 15:41, Malcolm McLean wrote:
> >>>>> On Monday, 24 July 2023 at 22:29:52 UTC+1, Keith Thompson wrote:
> >>>>>>
> >>>>>> Do you see some concrete bad consequence of requiring two's
> >>>>>> complement?
> >>>>>>
> >>>>> It means that if future technology means that two's complement is
> >>>>> no longer the engineering choice for chip designers, then either C
> >>>>> compilers will have to lose their closeness to the metal or that
> >> standard
> >>>>> will have to be revised and current programs will break.
> >>>>
> >>>> Come on, just making 'int' 64 bits instead of 32 will already
> break half
> >>>> the programs out there!
> >>>
> >>> Cite, please.
> >>
> >> So, there is no software that you know of that relies on 'int' being 32
> >> bits?
> >
> > So, you don't have any supporting evidence for your assertion.  Noted.
>
> So, *your* assertion is that you could simpy make `int` 64 bits
> overnight, and most software could just be recompiled and still work
> perfectly. Noted.
>

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

>
> >> I deal a lot with APIs expressed as C headers, which I have to create
> >> bindings for. There is a preponderance of int32 types there, which is
> >> puzzling; why int32 in particular, given it all runs on 64-bit
> machines?
> >
> > I've never seen an 'int32' type in any C or C++ code I've worked
> > with (and it's in the millions of lines by now).
>
> You haven't looked much then. I've seen ANY NUMBER of variations based
> around the `int32` and `i32` styles, created using typedefs, mainly
> because people can't stand the built-in denotations of C, or wanted
> something more stable.
>

I think most C programmers have come across variants and alternatives to
"int32_t" that have much the same meaning. But these alternatives
typically come from either:

1. Code with a history from before C99 and the <stdint.h> types.
2. Code written to work with pre-C99 toolchains.
3. Newer code referring to or using type 1 or 2 code.
4. Code that uses different names to distinguish types for different
purposes, perhaps using more advanced linters to check usage in a
stronger manner than C compilers typically support.

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

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

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

I can't answer for Scott, but for me it could be int16_t, int32_t or
int64_t, depending on the context - I make sure I use appropriate types
for the calculations I need, balanced with the efficiency requirements
on the particular target.