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

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.

This is to provide some alleged benefit, but it means the same program,
on the same hardware, perhaps even with the same compiler with slightly
different options, could give different, unpredictable results. Not
because hardware gives you garbage, but on purpose.

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.

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.

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

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. The
only change I can see is if AIs become good enough to write such proofs
and feed them to a non AI programme.

> > I want to reason about my code with /no/ overflows. Any behaviour on
> > overflow is hypothetical.
>
> Eh? You never convince yourself that there are no overflows?

I think David means that he reasons about his code with no overflows by
convincing himself that no overflows are possible.

Am 25.07.2023 um 18:43 schrieb Spiros Bousbouras:
> 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.
>
> And in C one can write
> mid = low + (high-low)/2 ;

What if both values are signed and high - low exceed the signed value
range ?

>
> and not worry about overflow either. I find the latter easier to reason
> about too.
>
>> 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 .
>
> 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. The
> only change I can see is if AIs become good enough to write such proofs
> and feed them to a non AI programme.
>
>>> I want to reason about my code with /no/ overflows. Any behaviour on
>>> overflow is hypothetical.
>>
>> Eh? You never convince yourself that there are no overflows?
>
> I think David means that he reasons about his code with no overflows by
> convincing himself that no overflows are possible.

On 2023-07-25, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> 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.

How can that work, unless low and high are promoted to a wider type?
(Or else we are dealing with positive, signed inputs, and division
does something silly with negatives?)

Clive D. Feather's notes on BCPL claim that arithmetic overflow
in addition is undefined in BCPL.

Were there BCPL compilers which recognized the (E0 + E1)/2 pattern
and transformed it to avoid overflow?

It looks like there is a MULDIV(x, y, z) operator in BCPL which
evaluates x * y / z without overflow, if just the resulting value is
representable.

> Can you give an example where UB overflows leads to some simplification
> for the programmer. I can only think of counter-examples (I showed a
> couple above).

Yes; this occurs when the implementation uses the UB status to
assiduously diagnose all overflows by terminating the program with
a diagnostic, either at translation time, when possible/feasible,
or else run-time.

This is simpler than the programmer inserting overflow handling
everywhere in the program to achieve the same thing.

On 25/07/2023 18:15, Bonita Montero wrote:
> Am 25.07.2023 um 18:43 schrieb Spiros Bousbouras:
>> 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.

(Why not? Is is not possible to have objects that big given that the one
type must be able to address all of memory?)

>> And in C one can write
>> mid = low + (high-low)/2 ;
>
> What if both values are signed and high - low exceed the signed value
> range ?

You mean, for example, if the initial bounds were low = -128 and high =
+127, where arithmetic was done using signed 8-bit aritmetic?

In this case, you'd need to consider that either `high - low` or `low +
must be representable in the number type that you have chosen to do the
calculation.

So you either have to limit the range to suit the type, or change the
type to accommodate the range.

Use of an i64 type will put paid to most such issues. But if you're
stuck with i16 or even 32, you need to take extra care. Maybe use
unsigned even if indices will always be positive, to give extra range.

On 25/07/2023 17:41, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> (I'm off on a few weeks holiday soon, which will greatly limit how much I
>> can read and post to Usenet. So if I don't answer you or other posters in
>> the near future, it is not through lack of interest.)
>>
>>
>>
>> On 25/07/2023 03:42, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 23/07/2023 23:10, Ben Bacarisse wrote:
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>
>>
>> <snip>
>>
>>>>>>> Two's complement numbers form a commutative ring. What's wrong with
>>>>>>> that?
>>>>>>
>>>>>> Nothing - but equally, it has no benefit. It gives nothing particularly
>>>>>> useful.
>>>>> There's nothing wrong with it but relies on a screwed up idea of
>>>>> numbers?
>>>>
>>>> If you don't overflow your calculations, there's nothing wrong with two's
>>>> complement wrapping.
>>> If your calculation don't overflow, it's OK for them to do something
>>> they won't do (wrap) because they don't overflow?
>>>
>>
>> Yes. If your calculations don't overflow, it doesn't matter what would
>> hypothetically happen if they had overflowed.
>
> I know that is what you said, but you, apparently, don't see why I think
> that saying "it's screwed up" and then "there's nothing wrong with it"
> and explaining that with "there's nothing wrong with it if it never
> happens" leaves me confused. All I can conclude is that you /do/ think
> it's screwed up because there's only nothing wrong with it if it doesn't
> happen. Could you not just have stuck with the "it's screwed up" and
> left out the intermediate "there's nothing wrong with it"?
>

I was trying to say that if a programmer thinks that wrapping gives the
/correct/ value on overflow, then their idea of numbers is "screwed up".
It is not the behaviour itself that is a problem, it is the idea that
this behaviour gives the right answer that is wrong. Does that make it
clearer, or am I just stirring the muddy waters?

>> That is how gcc (and a
>> number of other compilers) interpret undefined behaviour, and use it for
>> optimisation to give more efficient code on the assumption that the
>> calculations don't overflow.
>>
>> My position is that overflowing calculations, on the whole, only occur as a
>> result of errors in the code.
>
> That's true in C. But in a language with defined wrapping of integer
> arithmetic, such overflows might simply result from after the fact
> tests. In C one writes
>
> if (this will overflow) {
> report error or whatever
> }
> else do calculation
>
> With wrapping one can sometimes write
>
> do calculation
> if (it overflowed) {
> report error or whatever
> }
>
> Here, overflow is "not correct" but it's not a programming error in the
> sense you mean.
>

If overflow behaviour is defined in a way that lets you get useful
information like this, then yes, you can get something helpful - the
overflow indicator could be correct even if the calculated value is not.

(I think functions akin to gcc's "__builtin_add_overflow" extensions are
useful here, and can work in a wider range of circumstances than testing
based on the result after a wrapping calculation.)

>> I want two things from my compiler - help
>> finding errors, and the most efficient code practically possible on the
>> assumption that the source code is correct. (I also like to be able to
>> change the balance between these using compiler flags.) UB on overflow is
>> a positive thing for both of these.
>
> That seems to be all one has, even toady. In the 80s, I looked forward
> to a world where a programmer's workbench would include tools to help
> verify all sorts of program properties.

I remember reading magazine articles in the 80's about how most software
would be generated automatically without needing programmers. And I
still don't see flying cars!

>
> How do you use a compiler to help find overflow errors? Just compile
> with something like -fsanitize=undefined and do lots of testing? If so,
> there's no reason a compiler for a language with wrapping arithmetic
> could not be just as helpful by do something similar for overflow,
> despite it not being defined. In fact I've wanted to have an unsigned
> version of gcc's -ftrapv more than once.

Yes, those are the tools I use. (To be honest, it's very rare that I
need to check for such bugs - integer overflow is not a common mistake
in my coding.)

I have also occasionally made C++ classes that work mostly like normal
integer types, but do something special on overflow - but that's for a
different newsgroup!

I have also thought that different overflow behaviour for unsigned
integers would be helpful sometimes.

>
> As for optimising, I don't know enough to know how much UB helps C. man
> gcc says, for example, that -fwrapv "enables some optimizations and
> disables others" so it's not as simple as you make out.
>

It does say that - but it has said that for some 20 years or so, since
the option was introduced. I really can't think what optimisations it
could perform, and have not been able to find out. (Any ideas would be
appreciated.) Of course, if you have -fwrap enabled, you can write your
code in a different way which may be more efficient. For example, you
can do "postmortem" identification of overflow (in the way you described
earlier), rather than "look before you leap" avoidance of undefined
behaviour. But that involves changes to the source code.

>> I can't see the point in a feature that - given a bug in my code leading to
>> overflow, goes out of its way to guarantee a particular type of garbage out
>> when it gets garbage in. By the time the program flow reaches a point
>> where two's complement wrapping is specifically generated (rather than just
>> by coincidence as the most efficient code for arithmetic without wrapping
>> semantics), the wrapping only applies if the values were wrong from before.
>>
>>>> But for most use of integer calculations, if you
>>>> overflow, something has gone wrong. Believing that a wrapped value is
>>>> somehow "correct" is - in most cases - a screwed up idea of numbers.
>>> But I did not say that wrapped values should be believed to be correct.
>>> You seemed to be saying that simply defining it to happen was a screwed
>>> up notion of numbers.
>>>
>>
>> Fair point.
>>
>> So your position here is that it is advantageous to have a definition of
>> the overflow behaviour, without any requirement for the result to be
>> "correct" in any sense?
>>
>> Would you be equally happy (assuming the code performance was unchanged)
>> with different defined overflow behaviour? Options include a trap or
>> exception of some sort, a "non-signalling NaN" value, saturation, or an
>> unspecified value (that is, a valid member of the type, but with no
>> information about what value).
>
> To be honest, that's hard to say. I've not used languages with enough
> of those options to make an informed comment.
>

Fair enough. I haven't used such features either, except perhaps
explicitly in C coding.

>>>> My point is that having a neat mathematical description or certain
>>>> functionalities does not necessarily make a particular model for fixed-size
>>>> integers better than alternatives. Giving a mathematical name to the model
>>>> does not aid programmers or make incorrect code correct - defined incorrect
>>>> results are still wrong.
>>>
>>> But there are advantages to having defined incorrect answers over
>>> undefined incorrect answers.
>>
>> What are they?
>>
>> This is something people often say, yet are rarely able to justify.
>
> 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.
>

Spiros Bousbouras <spibou@gmail.com> writes:
> On Tue, 25 Jul 2023 16:41:30 +0100
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
[...]
>> 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.
>
> 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.

(high-low) can overflow if the values are signed.

[...]

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

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> David Brown <david.brown@hesbynett.no> writes:
[...]
> Your peacefulness score example is a counter-example. What's wanted
> there (presumably) is saturating integer arithmetic. Do I want signed
> integers for string and array lengths? What about shoe sizes? In C,
> numbers are often used simply to get n distinct, easily tested, value
> (like an enum) but where any arithmetic should be considered an error.
> I would guess that there are far fewer "ordinary integers" in
> programming that you think there are.

Restoring context, David Brown wrote:
A famous example of the consequences of integer overflow is found in
the original Civilisation game, with the AI leader Ghandi. The AI
leaders have, amongst their other characteristics, a "peacefulness"
score from 0 (psychotic) to 255 (at one with the universe). Ghandi
starts at maximum peacefulness, and never attacks others. But once
atomic weapons are developed in the game, every leader gets a bit
more cautious about starting a war, and their peacefulness score is
increased by 2. Due to wrapping of an 8-bit number, Ghandi is now
at 1 and immediately declares nuclear war on everyone else.

It's not clear that saturating arithmetic is the answer. It would
mean that incrementing and then decrementing Gandhi's peacefulness
would change its value. That's not as bad as starting a nuclear war,
but it's still semantically incorrect.

The problem is that the range of representable values was 0 to 255,
and Gandhi's peacefulness was set to 255, exactly where the values
stop behaving like mathematical integers. Either using a 16-bit
type or setting Gandhi's initial peacefulness to, say, 200 would
have avoided the nukes. (A character with an initial peacefulness
close to 0 could have caused related problems.)

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

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Bart <bc@freeuk.com> writes:
>
>> On 24/07/2023 08:50, David Brown wrote:
>>
>>> Integer constants (since that is the correct term - "literal" is
>>> only used for "string literal" in C)
>>
>> You're right, the C standard only uses that for string literals
>> and compound literals. But in the wider world, 'integer literal'
>> is commonly used to mean 'integer constant', including in this
>> C++ reference:
>>
>> https://en.cppreference.com/w/cpp/language/integer_literal
>
> 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.

> It's hard to see what confusion would result from using literal in
> this way for C as well -- except that you can't search for it in
> the C standard.

Given a choice between the level of confusion seen in the C++
standard and the level of confusion seen in the C standard ("integer
constant" and "integer constant expression" is confusing? really?)
I'm happy to be on the side of C's choice any day of the week and
twice on Sunday. Please cast my vote to continue using the terms
"constant" and "literal" as they are used in the C standard.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> I prefer C++'s usage, since "integer constant" can be so easily
> confused for "integer constant expression".

P.S. It might help to remember that "integer constant expression"
is parsed as "integer (constant expression)", because if it were the
other way then it would be written "integer-constant expression".

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Ben Bacarisse <ben.usenet@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.

[...]

> Given a choice between the level of confusion seen in the C++
> standard and the level of confusion seen in the C standard ("integer
> constant" and "integer constant expression" is confusing? really?)
> I'm happy to be on the side of C's choice any day of the week and
> twice on Sunday. Please cast my vote to continue using the terms
> "constant" and "literal" as they are used in the C standard.

I use those terms simply because that's how they're used in the C
standard.

--
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 Tue, 25 Jul 2023 15:03:02 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Spiros Bousbouras <spibou@gmail.com> writes:
> > On Tue, 25 Jul 2023 16:41:30 +0100
> > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> [...]
> >> 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.
> >
> > 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.
>
> (high-low) can overflow if the values are signed.

I was assuming that 0 <= low < high .With the assumption that
low < high , a more general solution is

if (low < 0 && 0 <= high) mid = (low + high)/2 ;
else mid = low + (high-low)/2 ;

Or

mid = low/2 + high/2 ;

But perhaps someone can explain why in BCPL you can write

LET mid = (low + high) / 2

without "much thought".

Spiros Bousbouras <spibou@gmail.com> writes:
> On Tue, 25 Jul 2023 15:03:02 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Spiros Bousbouras <spibou@gmail.com> writes:
>> > On Tue, 25 Jul 2023 16:41:30 +0100
>> > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> [...]
>> >> 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.
>> >
>> > 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.
>>
>> (high-low) can overflow if the values are signed.
>
> I was assuming that 0 <= low < high .With the assumption that
> low < high , a more general solution is
>
> if (low < 0 && 0 <= high) mid = (low + high)/2 ;
> else mid = low + (high-low)/2 ;
>
> Or
>
> mid = low/2 + high/2 ;
>
> But perhaps someone can explain why in BCPL you can write
>
> LET mid = (low + high) / 2
>
> without "much thought".

Perhaps a mistake on Ben's part? Even assuming consistent
two's-complement wraparound, if low and high are both positive,
(low + high) can overflow and yield a negative value, and mid will
be negative.

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

Bart <bc@freeuk.com> writes:

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

This statement is wrong. Compilers don't cause undefined behavior.
"Undefined behavior" is simply a specification; the specification
doesn't change regardless of what a compiler might or might not do
in response to it.

On 26/07/2023 05:09, Keith Thompson wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Ben Bacarisse <ben.usenet@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.

Interesting. Usually bringing in other languages to justify the use of
an informal term is what I'm driven to do when challenged. 'This is a C
language group, there are no other languages!'.

On 26/07/2023 08:21, Malcolm McLean wrote:
> 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.

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.

(Chambers 1988 among others.)

In any case, none relevant to computing. Otherwise there is this meaning
from Wikipedia, for computer programming:

https://en.wikipedia.org/wiki/Literal_(computer_programming)

"In computer science, a literal is a notation for representing a fixed
value in source code."

Basically, the people behind the C standard decided to fix on a
particular set of terms to consistently refer to the same concepts.

But articles in this newsgroup don't need to need to be exactingly
written in such legalese, even though many would prefer just that.

On 26/07/2023 10:40, Tim Rentsch wrote:
> Bart <bc@freeuk.com> writes:
>
>> 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.
>
> This statement is wrong. Compilers don't cause undefined behavior.
> "Undefined behavior" is simply a specification; the specification
> doesn't change regardless of what a compiler might or might not do
> in response to it.

That's the 'if (n+1 > n)' example that someone posted a few days ago,
when 'n' had the value INT_MAX.

It gave different results on the same hardware DEPENDING ON compiler.
That is the unpredictable, undefined behaviour I'm refering to.

So it is purely up to the compiler, not the language. A dumb compiler
doing a mechanical translation to code running on a typical two's
complement machine, where signed integer overflow has documented
behaviour, would give the expected results consistently.

A 'clever' compiler such as gcc would give unexpected results IN SOME
CASES (which is where the problem lies). And it uses the UB within the
language as an excuse to do that, with the justification that it can
skimp on some code.

'In Some Cases' means where, when compiling 'if (a+1 > b)' the compiler
somehow knows that integer overflow will occur (because `a` is infered
to have the value INT_MAX for example).

On Wednesday, 26 July 2023 at 11:17:46 UTC+1, Bart wrote:
> On 26/07/2023 08:21, Malcolm McLean wrote:
> > 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.
> 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". The stem "liter" means "letter",
for the Latin "litera".

Bart <bc@freeuk.com> writes:
> On 26/07/2023 05:09, Keith Thompson wrote:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Ben Bacarisse <ben.usenet@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.
>
> Interesting. Usually bringing in other languages to justify the use of
> an informal term is what I'm driven to do when challenged.

I was responding to Tim's excessive (in my opinion) reaction to the use
of "literal" to refer to what C calls a constant. I do prefer, when
writing here, to use the terms defined by the C standard, but "integer
literal" is clear enough that I'm not likely to go out of my way to
object to it.

> 'This is a
> C language group, there are no other languages!'.

Literally nobody said that.

--
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 10:40, Tim Rentsch wrote:
>
>> Bart <bc@freeuk.com> writes:
>>
>>> 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.
>>
>> This statement is wrong. Compilers don't cause undefined behavior.
>> "Undefined behavior" is simply a specification; the specification
>> doesn't change regardless of what a compiler might or might not do
>> in response to it.
>
> That's the 'if (n+1 > n)' example that someone posted a few days ago,
> when 'n' had the value INT_MAX.
>
> It gave different results on the same hardware DEPENDING ON
> compiler. That is the unpredictable, undefined behaviour I'm refering
> to. [...]

I understand. You are misusing the term "undefined behavior".
I responded to point out the misuse.

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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
> [...]
>
>> My own view is that C would be improved if overflow were taken out
>> of the realm of just plain undefined behavior, but that limiting
>> the set of choices to just two's complement wrapping would be too
>> restrictive. It's very disappointing that the current C23 draft
>> has needlessly removed allowing representations other than two's
>> complement.
>
> I have the opposite reaction.

That's not surprising.

> There are, as far as I know, exactly
> zero conforming C implementations that don't use two's complement,
> and I don't believe that's likely to change. (There are perhaps
> a handful of implementations that only conform to C90 or so; those
> can continue to work as C90 implementations.) The standard already
> imposes some restrictions on signed integer representations: they
> must be binary, corresponding signed and unsigned types must use
> the same representation for common values, and all-bits-zero must
> be a representation for 0. I don't see that continued support
> for sign and magnitude or ones' complement is any more useful than
> hypothetical support for trinary or excess notation.

Leaving it in costs almost nothing. Taking it out sends a bad
message. I would like to see the non-two's-complement hardware
C90 implementations be brought forward to C99 or C11 (or later
C standards). Disallowing non-two's-complement representation
in the next C standard virtually guarantees that they will not
be. That is real cost.

(Incidentally, the preferred form is ternary.)

> Do you see some concrete bad consequence of requiring two's
> complement?

It's wrong on principle. One of C's greatest strengths is
stability. You can bet that if this aspect is restricted in the
next C standard then other allowances in the C standard will be
also be removed (and indeed some of those are already evident),
in the interest of "modernization", changing things for the sake
of change and not because they bring any significant value. The
trend is unmistakable, and once started, irreversible. It's a
sad day for the C language.

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.

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! Why do think it seems to have stuck at 32 bits?

> then either C
> compilers will have to lose their closeness to the metal

It never has been that close to the metal, due to its desire to be
non-partisan regarding types sizes or representations.

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

Consider and optical computer where the signals are not binary or
tri-state, but rather due to the properties of light and color
are decimal. tens-complement would be natural.

(There was a cover article in Scientific American in the mid 80's suggesting
something similar).