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

> On 19/07/2023 18:22, Bart wrote:
>> On 19/07/2023 15:27, David Brown wrote:
>> > On 19/07/2023 13:07, Bart wrote:
>> > For the language definition, it is about what makes sense in the code. C
>> > is a typed language.  It does not make it very hard to mess around with
>> > types, and it does not have good support for making your own types that
>> > are convenient to use, but it /is/ a typed language.  A float is a float
>> > - it is not an int, and it does not make sense to use it as an int.
>> Isn't that how BCPL (an ancestor of C) worked? You just had chunks of
>> memory and defined what they represented by the operations you chose.

Yes. a * b multiplies the integer values of two words. a #* b
multiplies the same words but interprets them as floating point. Being
word based, this aspect was very clumsy as you'd need another set of
operators to handle double precision floats. Indeed you'd need new
operators if you wanted to handle more than one size of integer.

Years ago I sketch out a design for a "modern" BCPL where the width of
objects could be stated. It was not very successful or I might have
tried to implement it.

> BCPL is before my time. But I think you are correct. C was intended to
> have stronger typing than BCPL.

You must be a youngster (for Usenet)! BCPL was still actively used for
R&D in Cambridge in the 1980s. My UG dissertation (1982) used BCPL.

I really used to like BCPL (I've not used for a while so I might not get
on with it anymore). It was surprisingly easy to use while remaining
very close to the metal. I looked at it's modern successor MCPL a while
back and I thought that looked interesting too.

--
Ben.

On 19/07/2023 20:47, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 19/07/2023 18:22, Bart wrote:
>>> On 19/07/2023 15:27, David Brown wrote:
>>> > On 19/07/2023 13:07, Bart wrote:
>>> > For the language definition, it is about what makes sense in the code. C
>>> > is a typed language.  It does not make it very hard to mess around with
>>> > types, and it does not have good support for making your own types that
>>> > are convenient to use, but it /is/ a typed language.  A float is a float
>>> > - it is not an int, and it does not make sense to use it as an int.
>>> Isn't that how BCPL (an ancestor of C) worked? You just had chunks of
>>> memory and defined what they represented by the operations you chose.
>
> Yes. a * b multiplies the integer values of two words. a #* b
> multiplies the same words but interprets them as floating point. Being
> word based, this aspect was very clumsy as you'd need another set of
> operators to handle double precision floats.

OCaml uses different operators too. * for integer multiply, *. for float.

I think that is to help with its type inference.

On Wednesday, 19 July 2023 at 17:31:51 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Wednesday, 19 July 2023 at 14:38:36 UTC+1, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>
> >> > On Wednesday, 19 July 2023 at 03:31:43 UTC+1, Ben Bacarisse wrote:
> >> >> Bart <b...@freeuk.com> writes:
> >> >>
> >> >> > On 18/07/2023 03:25, Ben Bacarisse wrote:
> >> >> >> Bart <b...@freeuk.com> writes:
> >> >> >>>
> >> >> You /are/ allowed to use it. The fact that it is undefined simply means
> >> >> that the definition of the language does not say what the code means.
> >> >> >> I really don't know what you hope to gain by saying obvious things like
> >> >> >> this other than to (incorrectly) imply that C -- the language -- is not
> >> >> >> defined by it's defining documents -- the ISO standards -- but by
> >> >> >> compiler options.
> >> >> >
> >> >> > I've given examples in the past where the same C program either:
> >> >> >
> >> >> > * Passed with 0 lines of errors or warnings
> >> >> >
> >> >> > * Passed with 28,000 lines of warnings and notes (on a 40Kloc input)
> >> >> So you are still trying to imply that C -- the language -- is not
> >> >> defined by it's defining documents -- the ISO standards -- but by
> >> >> compiler options. You are still wrong.
> >> >>
> >> > For someone implementing a compiler, the language is defined by the
> >> > standards document. But for someone who is not implementing a
> >> > compiler, the language is ultimatelt defined by the behaviour of
> >> > compilers.
> >> Your use of the definite article is permitting a confusion to go
> >> unnoticed. I would say that you are talking about two languages here:
> >> there is the C language (defined by the standards) and the language
> >> implemented by the compiler. We usually hope that they are very
> >> similar.
> >>
> >> The language implemented by the compiler is obviously very important in
> >> practice, but it's almost impossible to talk about it because it
> >> includes everything from bugs to misunderstandings of the standards.
> >>
> > It's also because the standard has to include every extant
> > architecture,
> I'm not sure what "it" refers to here so I'll leave this bit alone...
> > and maybe some which don't exist but theoretically could exist, like
> > Fibonacci representation machines. Whilst in fact you can probably
> > rely on features like CHAR_BIT being exactly eight. The standard
> > doesn't guarantee it, but the vast majority of achitectures make it
> > natural, and on big mainframes that don't allow 8 bit memory access,
> > in fact C compilers put the program through ANDs and ORs to create 8
> > bit chars, because otherwise too much code breaks. Only digital
> > signals processing chips have wider chars, and they can't run general
> > purpose programs anyway.
> >>
> >> In that sense, this second language is defined only by the compiler
> >> source code -- it's still not defined by the options. Bart wants to
> >> spread confusion by suggesting that C is a language defined by compiler
> >> options.
> >>
> > It is a bit of an odd situation. If we write a program which branches
> > if a char is negative, it will produce one output if we use the
> > "signed chars" option and another if we use the "unsigned chars"
> > option. So two executables with the same source and written in the
> > same language produce different output.
> Yes, but I am surprised you think that's odd. Maybe I think about the
> meaning of programs in very different terms to you. In formal
> semantics, there's no problem stating that there is more than one
> possible output, and when being informal you just need to adjust the
> words a bit. The "meaning" of this program:
>
> #include <stdio.h>
>
> int main(void) { printf("%u\n", -1u); }
>
> is "print the decimal representation of the largest unsigned int". It's
> not "print 4294967295" or "print 65535" (or any of the other
> possibilities).
>
The intention of the programmer might be to print the largest unsigned int,
or it might be to print 65535. If it's the first, then it's a type of meta program,
examining the characteristics of the program itself. And whilst it's possible that
an option could toggle between 32 bit and 16 bit ints, it's unlikely, because
you create too many problems for the linker. On different machines the same
program might have different results, but that's to be expected. If two machines
have different floating point hardware, then you'd expect slightly different output
from well-written programs, and it's posible to have radically different output
from badly-written programs.
On the other hand, consider this.

int ch = fgetc(fp);

/* quick hack, if we run out of input use commandline */
if (ch == EOF)
ch = argv[1][0];

if (ch < 32)
/* control character, process here */

The quick hack has of course broken the code. Unless the "signed char" option
is turned off. I do find this odd behaviour and difficult to accept.
>
> > So you can argue that in fact
> > the language can't be the same. Or you can argue, as you have done,
> > that computer languages allow for a sort of ambiguity which we don't
> > see in natural languages.
> I am not arguing that. For one thing, I don't consider "print the
> decimal representation of the largest unsigned int" to be ambiguous, but
> even if you do consider it so, it is ambiguous in a very particular
> sense, quite unlike most ambiguities in natural language.
>
In natural language your ambiguity is "does this mean the largest unsigned int
in existence, which is probably 2^128 -1, or the largest unsigned int on the
partiuclar machine we are discussing?" You need context to know the answer,
and of course in this case, you mean the second. The computer code is
ambiguous because we can't tell what the output will be from examining
the source code.Whilst "out of memory" is a special case which has to exist for
fundamental technical reasons, otherwise we normally expect to be able to
determine output from a combination of source code, input, and knowledge of
the language.

David Brown <david.brown@hesbynett.no> writes:
[...]
> Virtually all current implementations use two's complement
> representation for signed integers. Up until C23, C allowed ones'
> complement and sign-magnitude as alternative representations - these
> are no long allowed in C23. However, integer types can still have
> padding bits in C23.
>
> I agree that it is reasonable to assume two's complement
> representation for signed integers, unless you are writing code with
> extreme portability.

Agreed, but I'm not entirely sure how it could be useful to write
code that assumes two's complement. In the vast majority of cases,
the code I'd write if I were assured that the implementation uses
two's complement and the code I'd write if I were told that the
target might use some other representation would be identical. A
signed integer type lets me store and manipulate integer values over
a specified range; I rarely care how those values are represented.
If I want to do bit manipulation, I'll use unsigned types.

I could certainly contrive some code that would behave differently
depending on how signed integers are represented, and I have no
doubt there are some cases where it makes sense to write such code
deliberately, but I think such code is rare.

> However, when people talk about two's complement signed integers, they
> are sometimes talking about signed arithmetic overflows. This is a
> very different matter from the representation of the types. And while
> almost all current processors will use two's complement wrapping in
> their signed arithmetic instructions, C (including C23) does /not/
> guarantee any behaviour for overflows, and C compilers do not, as a
> rule, guarantee any behaviour for overflows. Many optimising
> compilers will optimise code on the assumption that signed integer
> arithmetic does not overflow. This is not new - I first saw it nearly
> 30 years ago. It is not just gcc or clang - MSVC also does such
> optimisations. The only compilers I know about for which you can rely
> on wrapping behaviour are gcc and clang with the "-fwrapv" flag
> enabled.

Agreed. Here's an example:

#include <stdio.h>
#include <limits.h>
int main(void) {
int n = INT_MAX;
if (n + 1 > n) {
printf("%d > %d\n", n + 1, n);
}
else {
printf("%d <= %d\n", n + 1, n);
}
}

With gcc (without -fwrapv), this program prints (at all optimization
levels):

-2147483648 > 2147483647

(This applies only to the quick experiment I just did, and could vary
with the phase of the moon.)

The bottom line is that the "+" operator in that code does **not** mean
"apply the x86_64 addl instruction to the operands". It means "add the
operands in accordance with the semantics given in the C standard".

[...]

> The fact is that C++ compilers are C++ compilers, and C compilers are
> C compilers. They might share some common parts - I have never heard
> of a C++ compiler that did not have a companion C compiler, other than
> MSVC having an extremely limited companion C compiler. (I believe
> they finally implemented C99, some 20 years late.)

And I've never heard of a C and C++ compiler that share the same front
end. The C and C++ grammars have a lot of similarity, but it would be
insanely awkward to implement a single parser that can handle either
language.

[...]

--
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, 19 July 2023 at 23:13:17 UTC+1, Keith Thompson wrote:
> David Brown <david...@hesbynett.no> writes:
> [...]
> > Virtually all current implementations use two's complement
> > representation for signed integers. Up until C23, C allowed ones'
> > complement and sign-magnitude as alternative representations - these
> > are no long allowed in C23. However, integer types can still have
> > padding bits in C23.
> >
> > I agree that it is reasonable to assume two's complement
> > representation for signed integers, unless you are writing code with
> > extreme portability.
>
> Agreed, but I'm not entirely sure how it could be useful to write
> code that assumes two's complement. In the vast majority of cases,
> the code I'd write if I were assured that the implementation uses
> two's complement and the code I'd write if I were told that the
> target might use some other representation would be identical. A
> signed integer type lets me store and manipulate integer values over
> a specified range; I rarely care how those values are represented.
> If I want to do bit manipulation, I'll use unsigned types.
>
> I could certainly contrive some code that would behave differently
> depending on how signed integers are represented, and I have no
> doubt there are some cases where it makes sense to write such code
> deliberately, but I think such code is rare.
>
> > However, when people talk about two's complement signed integers, they
> > are sometimes talking about signed arithmetic overflows. This is a
> > very different matter from the representation of the types. And while
> > almost all current processors will use two's complement wrapping in
> > their signed arithmetic instructions, C (including C23) does /not/
> > guarantee any behaviour for overflows, and C compilers do not, as a
> > rule, guarantee any behaviour for overflows. Many optimising
> > compilers will optimise code on the assumption that signed integer
> > arithmetic does not overflow. This is not new - I first saw it nearly
> > 30 years ago. It is not just gcc or clang - MSVC also does such
> > optimisations. The only compilers I know about for which you can rely
> > on wrapping behaviour are gcc and clang with the "-fwrapv" flag
> > enabled.
>
> Agreed. Here's an example:
>
> #include <stdio.h>
> #include <limits.h>
> int main(void) {
> int n = INT_MAX;
> if (n + 1 > n) {
> printf("%d > %d\n", n + 1, n);
> }
> else {
> printf("%d <= %d\n", n + 1, n);
> }
> }
>
> With gcc (without -fwrapv), this program prints (at all optimization
> levels):
>
> -2147483648 > 2147483647
>
I get the output

-2147483648 <= 2147483647
Adnittedly I'm using a Mac and the command "gcc" actually invokes clang.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> 6.2.6.1 p5 says (in part)
>
> "Certain object representations need not represent a value of the
> object type. If such a representation is read by an lvalue expression
> that does not have character type, the behavior is undefined."

Yes, but that's not why reading an uninitialized int object has
undefined behavior.

If we know that, for example, CHAR_BIT==8, sizeof(int)==4,
INT_MAX==2147483647, and INT_MIN==-INT_MAX-1, then we can rigorously
infer that int has no padding bits, and no trap representations.

> Elsewhere we can find wording to say that uninitialised local variables
> and newly allocated storage contain indeterminate representations. This
> includes the possibility of non-value representations.

Yes, but even if the memory happens to contain a valid representation
for type int, the representation is still indeterminate. Indeterminacy
is not defined by the bits making up the representation.

An indeterminate value is by definition "either an unspecified value or
a trap representation". Annex J lists "The value of an object with
automatic storage duration is used while it is indeterminate" as an
example of undefined behavior.

[...]

--
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-19, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> Virtually all current implementations use two's complement
>> representation for signed integers. Up until C23, C allowed ones'
>> complement and sign-magnitude as alternative representations - these
>> are no long allowed in C23. However, integer types can still have
>> padding bits in C23.
>>
>> I agree that it is reasonable to assume two's complement
>> representation for signed integers, unless you are writing code with
>> extreme portability.
>
> Agreed, but I'm not entirely sure how it could be useful to write
> code that assumes two's complement.

Here is one: most signed integers that appear in network packets
or files, and are not in textual decimal form, are in two's
complement.

If you assume your machine is two's complement, then the code
for decoding and encoding is simpler.

Under two's complement you can also assume that:

- value conversion between signed and unsigned of equal width preserves
the bits; e.g (uint32_t) int32 is a hardware-level noop.

- conversion from wider to narrower simply truncates; if the
value fits, it is preserved.

- widening conversion sign-extends.

Say we have a 24 bit PCM audio sample in an integer that is 32 or
more bits, like an unsigned long. To write it out as a 24 bit big
endian sample, assuming 8 bit bytes, we can just do this:

put_byte(stream, sample >> 16);
put_byte(stream, sample >> 8);
put_byte(stream, sample);

We know that a two's complement 32 bit value, if it fits into 24
bits, can just be truncated to the lower 24 bits, and we're done.

We also know that narrowing conversions truncate; like when
we call put_byte(stream, sample), when sample is converted to
(unsigned char), that implementation-defined conversion preserves the
least significant 8 bits.

To recover the value we might do:

(long) get_byte(stream) << 16 |
(long) get_byte(stream) << 8 |
get_byte(stream) << 8 |

Then we test for the sign bit, and sign extend:

if ((sample & 0x800000) != 0)
sample |= 0xFF000000;

That's bad because it assumes 32 bits. I think could do this without
assuming how wide long is, like this:

if ((sample & 0x800000) != 0)
sample |= -0x1000000L;

Or, express that constant as a left shift:

if ((sample & 0x800000) != 0)
sample |= (-1L << 24);

In these kinds of situations, assuming two's complement and
certain conversion semantics simplifies the code a bit, and
possibly makes it faster.

I mean, we could extract the value as an unsigned;
say we have a ulong typedef:

(ulong) get_byte(stream) << 16 |
(ulong) get_byte(stream) << 8 |
get_byte(stream) << 8 |

Then we know that our bottom 24 bits are either a positive
value (we are almost done) or a two's complement negative
value, where we take the two's complement to get the
additive inverse positive value, cast to the signed
type and negate it:

if ((usample & 0x8000000) != 0)
sample = - (long) ((usample ^ 0xFFFFFF) + 1)
else
sample = usample;

The code doesn't look bad, but it's more operations:
XOR, add 1, negate. Under the two's complement
assumption, we just OR in a sign extension mask
and we are done.

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

On 7/19/23 12:07, Bonita Montero wrote:
> Am 18.07.2023 um 12:37 schrieb Blue-Maned_Hawk:
>> On 7/17/23 12:26, Bonita Montero wrote:
>>> Am 13.07.2023 um 07:37 schrieb Blue-Maned_Hawk:
>>>>
>>>> ​Ain't nothing gonna dethrone C until a total revolution of the
>>>> modern computing ecosystem; in other words, replacing C would
>>>> require replacing everything else all at once.
>>>
>>> C has already been dethroned many times.
>>
>> ​I think you and i have different definitions of "dethrone" here.
>
> This statement is based on the language features. There are now
> some languages that are also system-related and also allow almost
> optimal performance, but are much more comfortable to program.
> F.e. Rust and C++.
>
​Languages do not exist in a vacuum; whether or not a language is
hypothetically better than C matters not for its practicality in the
face of C's pervasiveness.
--
⚗︎ | /blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr.
bluemanedhawk.github.io
Bitches stole my whole ass ␔🭖᷿᪳𝼗᷍⏧𒒫𐻾ࣛ↉�⃣ quoted-printable, can't
have shit in Thunderbird 😩

On 2023-07-19, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>> 6.2.6.1 p5 says (in part)
>>
>> "Certain object representations need not represent a value of the
>> object type. If such a representation is read by an lvalue expression
>> that does not have character type, the behavior is undefined."
>
> Yes, but that's not why reading an uninitialized int object has
> undefined behavior.
>
> If we know that, for example, CHAR_BIT==8, sizeof(int)==4,
> INT_MAX==2147483647, and INT_MIN==-INT_MAX-1, then we can rigorously
> infer that int has no padding bits, and no trap representations.
>
>> Elsewhere we can find wording to say that uninitialised local variables
>> and newly allocated storage contain indeterminate representations. This
>> includes the possibility of non-value representations.
>
> Yes, but even if the memory happens to contain a valid representation
> for type int, the representation is still indeterminate. Indeterminacy
> is not defined by the bits making up the representation.
>
> An indeterminate value is by definition "either an unspecified value or
> a trap representation". Annex J lists "The value of an object with
> automatic storage duration is used while it is indeterminate" as an
> example of undefined behavior.

Ah, but we can produce an unspecified value without accessing
an uninitialized object!

Order of evaluation is unspecified, thus:

int global = 1;

int operand(void) { return ++global; }

// ...

{
int val = operand() * operand() + operand();

}

Here, val could be

2 * 3 + 4 = 10
2 * 4 + 3 = 11
3 * 2 + 4 = 10
3 * 4 + 2 = 14
4 * 3 + 2 = 14
4 * 2 + 3 = 11

So val has an unspecified value which could be 10, 11 or 14.

Since an unspecified value is indeterminate, does it mean that
using val is undefined behavior?

No; the reason that using an unspecified value is undefined behavior
is that on some implementations, an unspecified value could be
a trap representation.

If we know that the implementation has no trap representation
in the type int, then an uninitialized value is in the same
category as val above: it's an unspecified value. Behavior
which depends on it is unspecified behavior.

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

On Thursday, 20 July 2023 at 00:01:19 UTC+1, Kaz Kylheku wrote:
>
> Or, express that constant as a left shift:
>
> if ((sample & 0x800000) != 0)
> sample |= (-1L << 24);
>
I've got exactly that code in the Baby X resource compiler.
gcc is giving me a warning about it when I use the "-pedantic-errors" flag.
(Thanks to Keith Thompson for pointing out these problems in the code).

On 7/18/2023 5:05 AM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>
>> Fun times! Storing meta data in a pointer, then masking it off before we
>> actually use the pointer. Undefined behavior for sure, but can it work and
>> be used in highly beneficial ways, yup.
>
> This can be done without any undefined behaviour. It's not "portable"
> but that's not the same as UB.
>

I concur. Convert pointer to uintptr_t, (optional aside for a moment),
perform bit operations that change the value. Before any use (deference)
of this mutated pointer value we mask off any changes; convert it back
from uintptr_t to a pointer, and deference it if its not null. This
works well for some interesting algorithms. We can also artificially
offset memory and store a reference/version count in the pointer values
to get around the ABA problem. Its an interesting method, trick. We can
also use the reference count as an important part of atomic differential
reference counting. Many things...

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

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>> 6.2.6.1 p5 says (in part)
>>
>> "Certain object representations need not represent a value of the
>> object type. If such a representation is read by an lvalue expression
>> that does not have character type, the behavior is undefined."
>
> Yes, but that's not why reading an uninitialized int object has
> undefined behavior.
>
> If we know that, for example, CHAR_BIT==8, sizeof(int)==4,
> INT_MAX==2147483647, and INT_MIN==-INT_MAX-1, then we can rigorously
> infer that int has no padding bits, and no trap representations.
>
>> Elsewhere we can find wording to say that uninitialised local variables
>> and newly allocated storage contain indeterminate representations. This
>> includes the possibility of non-value representations.
>
> Yes, but even if the memory happens to contain a valid representation
> for type int, the representation is still indeterminate. Indeterminacy
> is not defined by the bits making up the representation.

I know that indeterminacy is not defined by the bits, but I could not
find any normative text that could lead one to conclude that accessing
such an object is undefined from the indeterminacy itself. Where is it?

> An indeterminate value is by definition "either an unspecified value or
> a trap representation". Annex J lists "The value of an object with
> automatic storage duration is used while it is indeterminate" as an
> example of undefined behavior.

Annex J is not normative text. And if we take Annex J as accurately
conveying the intent, then the actual case being discussed (an allocated
object with indeterminate representation) is, in fact, not undefined
behaviour! Is that what was intended?

--
Ben.

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-07-19, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> [...]
>>> 6.2.6.1 p5 says (in part)
>>>
>>> "Certain object representations need not represent a value of the
>>> object type. If such a representation is read by an lvalue expression
>>> that does not have character type, the behavior is undefined."
>>
>> Yes, but that's not why reading an uninitialized int object has
>> undefined behavior.
>>
>> If we know that, for example, CHAR_BIT==8, sizeof(int)==4,
>> INT_MAX==2147483647, and INT_MIN==-INT_MAX-1, then we can rigorously
>> infer that int has no padding bits, and no trap representations.
>>
>>> Elsewhere we can find wording to say that uninitialised local variables
>>> and newly allocated storage contain indeterminate representations. This
>>> includes the possibility of non-value representations.
>>
>> Yes, but even if the memory happens to contain a valid representation
>> for type int, the representation is still indeterminate. Indeterminacy
>> is not defined by the bits making up the representation.
>>
>> An indeterminate value is by definition "either an unspecified value or
>> a trap representation". Annex J lists "The value of an object with
>> automatic storage duration is used while it is indeterminate" as an
>> example of undefined behavior.
>
> Ah, but we can produce an unspecified value without accessing
> an uninitialized object!
>
> Order of evaluation is unspecified, thus:
>
> int global = 1;
>
> int operand(void) { return ++global; }
>
> // ...
>
> {
> int val = operand() * operand() + operand();
>
> }
>
>
> Here, val could be
>
> 2 * 3 + 4 = 10
> 2 * 4 + 3 = 11
> 3 * 2 + 4 = 10
> 3 * 4 + 2 = 14
> 4 * 3 + 2 = 14
> 4 * 2 + 3 = 11
>
> So val has an unspecified value which could be 10, 11 or 14.
>
> Since an unspecified value is indeterminate, does it mean that
> using val is undefined behavior?
>
> No; the reason that using an unspecified value is undefined behavior
> is that on some implementations, an unspecified value could be
> a trap representation.
>
> If we know that the implementation has no trap representation
> in the type int, then an uninitialized value is in the same
> category as val above: it's an unspecified value. Behavior
> which depends on it is unspecified behavior.

That makes sense.

The problem is that (referring to N1570, and I don't see any relevant
changes in the latest public C23 draft, N3096), Annex J says gives

The value of an object with automatic storage duration is used
while it is indeterminate (6.2.4, 6.7.9, 6.8).

as an example of undefined behavior.

If that is accurate, then this program:

#include <limits.h>
int main(void) {
int foo;
if (sizeof (int) == 4 &&
CHAR_BIT == 8 &&
INT_MAX == 2147483647 &&
INT_MIN == -INT_MAX-1)
{
int bar = foo;
}
}

has undefined behavior on an implementation where the condition is true.
(Of course that UB is likely to manifest as quietly doing nothing.)

Annex J is non-normative, and depends on normative statements
elsewhere in the standard. Following the section numbers given in
Annex J and searching for occurrences of "indeterminate value",
I have so far been unable to confirm that the statement in Annex
J is correct.

Either Annex J is incorrect, or accessing an uninitalized
automatic object is UB even if the object cannot possibly hold a
trap representation. (I'd be satisfied either way; I'd like the
standard to be internally consistent.)

Perhaps someone else can find something in the standard that I've
missed.

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

On 20/07/2023 00:12, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> Virtually all current implementations use two's complement
>> representation for signed integers. Up until C23, C allowed ones'
>> complement and sign-magnitude as alternative representations - these
>> are no long allowed in C23. However, integer types can still have
>> padding bits in C23.
>>
>> I agree that it is reasonable to assume two's complement
>> representation for signed integers, unless you are writing code with
>> extreme portability.
>
> Agreed, but I'm not entirely sure how it could be useful to write
> code that assumes two's complement.

I said it was reasonable, not that it was useful!

> In the vast majority of cases,
> the code I'd write if I were assured that the implementation uses
> two's complement and the code I'd write if I were told that the
> target might use some other representation would be identical. A
> signed integer type lets me store and manipulate integer values over
> a specified range; I rarely care how those values are represented.

I think the one situation where it could be important is in connection
with external data. If you want to read or write a file, or send a
network packet, and the format of that file or packet requires two's
complement signed integers then it is definitely very convenient to be
able to assume that your integers are already in that format. Combine
it with an assumption (usually valid, and easily checked at
compile-time) that your unsigned char's are 8 bit, and it makes your
code very much simpler.

> If I want to do bit manipulation, I'll use unsigned types.
>

Agreed. Bit manipulation on signed types is just /wrong/ !

> I could certainly contrive some code that would behave differently
> depending on how signed integers are represented, and I have no
> doubt there are some cases where it makes sense to write such code
> deliberately, but I think such code is rare.
>
>> However, when people talk about two's complement signed integers, they
>> are sometimes talking about signed arithmetic overflows. This is a
>> very different matter from the representation of the types. And while
>> almost all current processors will use two's complement wrapping in
>> their signed arithmetic instructions, C (including C23) does /not/
>> guarantee any behaviour for overflows, and C compilers do not, as a
>> rule, guarantee any behaviour for overflows. Many optimising
>> compilers will optimise code on the assumption that signed integer
>> arithmetic does not overflow. This is not new - I first saw it nearly
>> 30 years ago. It is not just gcc or clang - MSVC also does such
>> optimisations. The only compilers I know about for which you can rely
>> on wrapping behaviour are gcc and clang with the "-fwrapv" flag
>> enabled.
>
> Agreed. Here's an example:
>
> #include <stdio.h>
> #include <limits.h>
> int main(void) {
> int n = INT_MAX;
> if (n + 1 > n) {
> printf("%d > %d\n", n + 1, n);
> }
> else {
> printf("%d <= %d\n", n + 1, n);
> }
> }
>
> With gcc (without -fwrapv), this program prints (at all optimization
> levels):
>
> -2147483648 > 2147483647
>
> (This applies only to the quick experiment I just did, and could vary
> with the phase of the moon.)
>
> The bottom line is that the "+" operator in that code does **not** mean
> "apply the x86_64 addl instruction to the operands". It means "add the
> operands in accordance with the semantics given in the C standard".
>

Exactly.

> [...]
>
>> The fact is that C++ compilers are C++ compilers, and C compilers are
>> C compilers. They might share some common parts - I have never heard
>> of a C++ compiler that did not have a companion C compiler, other than
>> MSVC having an extremely limited companion C compiler. (I believe
>> they finally implemented C99, some 20 years late.)
>
> And I've never heard of a C and C++ compiler that share the same front
> end. The C and C++ grammars have a lot of similarity, but it would be
> insanely awkward to implement a single parser that can handle either
> language.
>

I can't say if it (sharing a front-end for C and C++) is done or not - I
don't know the details of all toolchains! I think it is conceivable
that C could be parsed as a variation of a subset of C++, especially if
the compiler did not support all features of C. (There are many
embedded compilers that have outdated or limited support for standards.)
Maybe some of the slightly bizarre optional features added to later C
standards - such as making VLAs and complex numbers optional in C11 -
were requested by groups making common C and C++ front-ends? I have no
evidence or references here, it's merely a vague idea.

I think it is a more common for compilers to have different front-ends
for C and C++ (and perhaps other languages - gcc and llvm support many),
but share a common middle-end, then have back-ends that are language
independent and target-dependent.

But to be safe and general, I referred to "companion compilers" -
usually when you install a C++ compiler of any sort, you also get a C
compiler with the toolchain.

On 20/07/2023 00:23, Malcolm McLean wrote:
> On Wednesday, 19 July 2023 at 23:13:17 UTC+1, Keith Thompson wrote:
>> David Brown <david...@hesbynett.no> writes:
>> [...]
>>> Virtually all current implementations use two's complement
>>> representation for signed integers. Up until C23, C allowed ones'
>>> complement and sign-magnitude as alternative representations - these
>>> are no long allowed in C23. However, integer types can still have
>>> padding bits in C23.
>>>
>>> I agree that it is reasonable to assume two's complement
>>> representation for signed integers, unless you are writing code with
>>> extreme portability.
>>
>> Agreed, but I'm not entirely sure how it could be useful to write
>> code that assumes two's complement. In the vast majority of cases,
>> the code I'd write if I were assured that the implementation uses
>> two's complement and the code I'd write if I were told that the
>> target might use some other representation would be identical. A
>> signed integer type lets me store and manipulate integer values over
>> a specified range; I rarely care how those values are represented.
>> If I want to do bit manipulation, I'll use unsigned types.
>>
>> I could certainly contrive some code that would behave differently
>> depending on how signed integers are represented, and I have no
>> doubt there are some cases where it makes sense to write such code
>> deliberately, but I think such code is rare.
>>
>>> However, when people talk about two's complement signed integers, they
>>> are sometimes talking about signed arithmetic overflows. This is a
>>> very different matter from the representation of the types. And while
>>> almost all current processors will use two's complement wrapping in
>>> their signed arithmetic instructions, C (including C23) does /not/
>>> guarantee any behaviour for overflows, and C compilers do not, as a
>>> rule, guarantee any behaviour for overflows. Many optimising
>>> compilers will optimise code on the assumption that signed integer
>>> arithmetic does not overflow. This is not new - I first saw it nearly
>>> 30 years ago. It is not just gcc or clang - MSVC also does such
>>> optimisations. The only compilers I know about for which you can rely
>>> on wrapping behaviour are gcc and clang with the "-fwrapv" flag
>>> enabled.
>>
>> Agreed. Here's an example:
>>
>> #include <stdio.h>
>> #include <limits.h>
>> int main(void) {
>> int n = INT_MAX;
>> if (n + 1 > n) {
>> printf("%d > %d\n", n + 1, n);
>> }
>> else {
>> printf("%d <= %d\n", n + 1, n);
>> }
>> }
>>
>> With gcc (without -fwrapv), this program prints (at all optimization
>> levels):
>>
>> -2147483648 > 2147483647
>>
> I get the output
>
> -2147483648 <= 2147483647
> Adnittedly I'm using a Mac and the command "gcc" actually invokes clang.

The moon is in a different phase where you are.

But you are demonstrating Keith's point - signed integer overflow is UB,
and there is no way to predict the outcome. It will vary by compiler,
flags, details of the code, and of course, by the phase of the moon.

On Thursday, 20 July 2023 at 02:54:03 UTC+1, Keith Thompson wrote:
> Kaz Kylheku <864-11...@kylheku.com> writes:
> > On 2023-07-19, Keith Thompson <Keith.S.T...@gmail.com> wrote:
> >> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> >> [...]
> >>> 6.2.6.1 p5 says (in part)
> >>>
> >>> "Certain object representations need not represent a value of the
> >>> object type. If such a representation is read by an lvalue expression
> >>> that does not have character type, the behavior is undefined."
> >>
> >> Yes, but that's not why reading an uninitialized int object has
> >> undefined behavior.
> >>
> >> If we know that, for example, CHAR_BIT==8, sizeof(int)==4,
> >> INT_MAX==2147483647, and INT_MIN==-INT_MAX-1, then we can rigorously
> >> infer that int has no padding bits, and no trap representations.
> >>
> >>> Elsewhere we can find wording to say that uninitialised local variables
> >>> and newly allocated storage contain indeterminate representations. This
> >>> includes the possibility of non-value representations.
> >>
> >> Yes, but even if the memory happens to contain a valid representation
> >> for type int, the representation is still indeterminate. Indeterminacy
> >> is not defined by the bits making up the representation.
> >>
> >> An indeterminate value is by definition "either an unspecified value or
> >> a trap representation". Annex J lists "The value of an object with
> >> automatic storage duration is used while it is indeterminate" as an
> >> example of undefined behavior.
> >
> > Ah, but we can produce an unspecified value without accessing
> > an uninitialized object!
> >
> > Order of evaluation is unspecified, thus:
> >
> > int global = 1;
> >
> > int operand(void) { return ++global; }
> >
> > // ...
> >
> > {
> > int val = operand() * operand() + operand();
> >
> > }
> >
> >
> > Here, val could be
> >
> > 2 * 3 + 4 = 10
> > 2 * 4 + 3 = 11
> > 3 * 2 + 4 = 10
> > 3 * 4 + 2 = 14
> > 4 * 3 + 2 = 14
> > 4 * 2 + 3 = 11
> >
> > So val has an unspecified value which could be 10, 11 or 14.
> >
> > Since an unspecified value is indeterminate, does it mean that
> > using val is undefined behavior?
> >
> > No; the reason that using an unspecified value is undefined behavior
> > is that on some implementations, an unspecified value could be
> > a trap representation.
> >
> > If we know that the implementation has no trap representation
> > in the type int, then an uninitialized value is in the same
> > category as val above: it's an unspecified value. Behavior
> > which depends on it is unspecified behavior.
> That makes sense.
>
> The problem is that (referring to N1570, and I don't see any relevant
> changes in the latest public C23 draft, N3096), Annex J says gives
> The value of an object with automatic storage duration is used
> while it is indeterminate (6.2.4, 6.7.9, 6.8).
> as an example of undefined behavior.
> If that is accurate, then this program:
>
> #include <limits.h>
> int main(void) {
> int foo;
> if (sizeof (int) == 4 &&
> CHAR_BIT == 8 &&
> INT_MAX == 2147483647 &&
> INT_MIN == -INT_MAX-1)
> {
> int bar = foo;
> }
> }
>
> has undefined behavior on an implementation where the condition is true.
> (Of course that UB is likely to manifest as quietly doing nothing.)
>
> Annex J is non-normative, and depends on normative statements
> elsewhere in the standard. Following the section numbers given in
> Annex J and searching for occurrences of "indeterminate value",
> I have so far been unable to confirm that the statement in Annex
> J is correct.
>
> Either Annex J is incorrect, or accessing an uninitalized
> automatic object is UB even if the object cannot possibly hold a
> trap representation. (I'd be satisfied either way; I'd like the
> standard to be internally consistent.)
>
> Perhaps someone else can find something in the standard that I've
> missed.
>
One machine I worked on (the Nintendo 64) had nine bits per byte. However
the C compiler and most assembly instructions only used 8 bits.The 9th
bit was used by the GPU and you could access it using special machine
instructions.
It wasn't used for trap representations of course. But 32 logical bits doesn't necessarily
means 32 physical bits.

On 19/07/2023 23:54, Malcolm McLean wrote:
> On Wednesday, 19 July 2023 at 17:31:51 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> On Wednesday, 19 July 2023 at 14:38:36 UTC+1, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>

>>> It is a bit of an odd situation. If we write a program which branches
>>> if a char is negative, it will produce one output if we use the
>>> "signed chars" option and another if we use the "unsigned chars"
>>> option. So two executables with the same source and written in the
>>> same language produce different output.
>> Yes, but I am surprised you think that's odd. Maybe I think about the
>> meaning of programs in very different terms to you. In formal
>> semantics, there's no problem stating that there is more than one
>> possible output, and when being informal you just need to adjust the
>> words a bit. The "meaning" of this program:
>>
>> #include <stdio.h>
>>
>> int main(void) { printf("%u\n", -1u); }
>>
>> is "print the decimal representation of the largest unsigned int". It's
>> not "print 4294967295" or "print 65535" (or any of the other
>> possibilities).
>>
> The intention of the programmer might be to print the largest unsigned int,
> or it might be to print 65535. If it's the first, then it's a type of meta program,
> examining the characteristics of the program itself.

Ben has told you the meaning of the program. If the programmer intended
to write code to print 65535, then he/she did a rather poor job of it.

> And whilst it's possible that
> an option could toggle between 32 bit and 16 bit ints, it's unlikely, because
> you create too many problems for the linker.

It is an option for the m68k target for gcc. (Early 68000 processors
had 16-bit ALUs and datapaths, but 32-bit registers and support for
32-bit operations. Thus they handled 16-bit operations significantly
faster than 32-bit, but were future-compatible.) The AVR target for gcc
supports a flag for 8-bit ints, which is non-standard but can be very
useful for small AVR programs.

> On different machines the same
> program might have different results, but that's to be expected. If two machines
> have different floating point hardware, then you'd expect slightly different output
> from well-written programs, and it's posible to have radically different output
> from badly-written programs.
> On the other hand, consider this.
>
> int ch = fgetc(fp);
>
> /* quick hack, if we run out of input use commandline */
> if (ch == EOF)
> ch = argv[1][0];
>
> if (ch < 32)
> /* control character, process here */
>
> The quick hack has of course broken the code. Unless the "signed char" option
> is turned off. I do find this odd behaviour and difficult to accept.

You find it odd and difficult to accept that code which you call a
"quick hack" might be broken? Why not just write correct code and be happy?

Am 19.07.2023 um 18:17 schrieb fir:
> środa, 19 lipca 2023 o 18:08:12 UTC+2 Bonita Montero napisał(a):
>> Am 18.07.2023 um 12:37 schrieb Blue-Maned_Hawk:
>>> On 7/17/23 12:26, Bonita Montero wrote:
>>>> Am 13.07.2023 um 07:37 schrieb Blue-Maned_Hawk:
>>>>>
>>>>> ​Ain't nothing gonna dethrone C until a total revolution of the
>>>>> modern computing ecosystem; in other words, replacing C would require
>>>>> replacing everything else all at once.
>>>>
>>>> C has already been dethroned many times.
>>>
>>> ​I think you and i have different definitions of "dethrone" here.
>>
>> This statement is based on the language features. There are now
>> some languages that are also system-related and also allow almost
>> optimal performance, but are much more comfortable to program.
>> F.e. Rust and C++.
>
> i asked for rust somewhat becouse there are people who say it should detrone c though
> i recently found an opinion it uis rather to 'dethrone' c++, your favourite pony

It might dethrone both. It's recently begun to be incorporated into
the Linux kernel, and the Linux kernel unfortunately never had any
C++ code.

>
> so what with that you will bite that rust?

On 19/07/2023 21:21, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 19/07/2023 18:06, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 19/07/2023 13:07, Bart wrote:
> <cut>
>>>>> For example (assume both are 32 bits):
>>>>>      float* p = malloc(sizeof(float));
>>>>>      int* q = (void*)(p);
>>>>>      *q;        // is it this?
>>>>> In this case, space for 4 bytes has been allocated. malloc doesn't know
>>>>> if that space is for floats, ints, or anything else. I genuinely can't
>>>>> see the problem.
>>>>
>>>> Please read section 6.5 of the standards, paragraphs 6 and 7. The details
>>>> are more complicated for allocated space than for declared objects.
>>>>
>>>> The line "*q;" is, I believe, undefined behaviour - it is attempting to
>>>> read an "int" object when no such object exists at that address. You would
>>>> have the same problem evaluating "*p;" as no float object exists at that
>>>> address either.
>>>
>>> I think you are right about *q being UB, but I don't think "no such
>>> object exists" is a useful way to put it. I've not studied the details
>>> of the new standard, but accessing an object with an indeterminate value
>>> is probably still UB, but there's surely an object there if malloc
>>> succeeds.
>>
>> By "no such object exists", I mean "no object of type int exists at that
>> address". There is an object with size, but no declared or effective
>> type.
>>
>> To be honest, I couldn't find a clear rule here. Attempting to use the
>> value of an automatic storage variable while it is indeterminate is
>> explicitly UB, but I saw no obvious paragraph in the standards (C17 or
>> C23) about it.
>
> I find that phrasing odd. It's "explicitly UB" but you could not find
> where this was made explicit?

It all sounded clear in my head when I wrote it, but I see my phrasing
was not clear.

For automatic storage variables, using the value while it is
indeterminate is explicitly UB - from J.2 (a list of undefined behaviours):

"""
The value of an object with automatic storage duration is used while it
is indeterminate (6.2.4, 6.7.9, 6.8).
"""

For allocated objects from malloc, I could not find any rules that say
accessing the memory before something is stored in it is UB. I believe
it is UB - and of course, something can be UB simply because there is no
definition of its behaviour in the standards. But until I can see a
clear rule, I would not call it "explicitly UB". And I believe the
intention of J.2 is to summarise such "explicit UB" - if there were a
clear rule here, it would probably be listed in J.2.

>
> 6.2.6.1 p5 says (in part)
>
> "Certain object representations need not represent a value of the
> object type. If such a representation is read by an lvalue expression
> that does not have character type, the behavior is undefined."
>
> Elsewhere we can find wording to say that uninitialised local variables
> and newly allocated storage contain indeterminate representations. This
> includes the possibility of non-value representations.

Using indeterminate values in uninitialised local variables is UB,
regardless of whether or not there could be non-value representations
supported by the hardware.

>
> Thus it's tempting to consider *q as being "almost always well-defined"
> but since my view is that the semantics of a construct should include
> all the possibilities, the only meaning we can put on "int p;
> printf("%d\n", p);" is "none".
>

"No meaning" is, of course, just another way of saying "UB". But it's
important, I think, to note that it is UB even on systems where
non-value representations are not possible for ints. (i.e., almost
every real-world system.)

> We could say it means "print any int value or do anything at all when
> int can have non-value representations" but the latter part trumps the
> former in formal terms.
>

Yes. "Print any int value" would be right for an unspecified value, but
not for an indeterminate value.

Am 20.07.2023 um 01:16 schrieb Blue-Maned_Hawk:
> On 7/19/23 12:07, Bonita Montero wrote:
>> Am 18.07.2023 um 12:37 schrieb Blue-Maned_Hawk:
>>> On 7/17/23 12:26, Bonita Montero wrote:
>>>> Am 13.07.2023 um 07:37 schrieb Blue-Maned_Hawk:
>>>>>
>>>>> ​Ain't nothing gonna dethrone C until a total revolution of the
>>>>> modern computing ecosystem; in other words, replacing C would
>>>>> require replacing everything else all at once.
>>>>
>>>> C has already been dethroned many times.
>>>
>>> ​I think you and i have different definitions of "dethrone" here.
>>
>> This statement is based on the language features. There are now
>> some languages that are also system-related and also allow almost
>> optimal performance, but are much more comfortable to program.
>> F.e. Rust and C++.
>>
>
> ​Languages do not exist in a vacuum; whether or not a language is
> hypothetically better than C matters not for its practicality in
> the face of C's pervasiveness.

Rust and C++ can replace C equally well given the
tools and the languages.

On 20/07/2023 03:53, Keith Thompson wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> On 2023-07-19, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> [...]
>>>> 6.2.6.1 p5 says (in part)
>>>>
>>>> "Certain object representations need not represent a value of the
>>>> object type. If such a representation is read by an lvalue expression
>>>> that does not have character type, the behavior is undefined."
>>>
>>> Yes, but that's not why reading an uninitialized int object has
>>> undefined behavior.
>>>
>>> If we know that, for example, CHAR_BIT==8, sizeof(int)==4,
>>> INT_MAX==2147483647, and INT_MIN==-INT_MAX-1, then we can rigorously
>>> infer that int has no padding bits, and no trap representations.
>>>
>>>> Elsewhere we can find wording to say that uninitialised local variables
>>>> and newly allocated storage contain indeterminate representations. This
>>>> includes the possibility of non-value representations.
>>>
>>> Yes, but even if the memory happens to contain a valid representation
>>> for type int, the representation is still indeterminate. Indeterminacy
>>> is not defined by the bits making up the representation.
>>>
>>> An indeterminate value is by definition "either an unspecified value or
>>> a trap representation". Annex J lists "The value of an object with
>>> automatic storage duration is used while it is indeterminate" as an
>>> example of undefined behavior.
>>
>> Ah, but we can produce an unspecified value without accessing
>> an uninitialized object!
>>
>> Order of evaluation is unspecified, thus:
>>
>> int global = 1;
>>
>> int operand(void) { return ++global; }
>>
>> // ...
>>
>> {
>> int val = operand() * operand() + operand();
>>
>> }
>>
>>
>> Here, val could be
>>
>> 2 * 3 + 4 = 10
>> 2 * 4 + 3 = 11
>> 3 * 2 + 4 = 10
>> 3 * 4 + 2 = 14
>> 4 * 3 + 2 = 14
>> 4 * 2 + 3 = 11
>>
>> So val has an unspecified value which could be 10, 11 or 14.
>>
>> Since an unspecified value is indeterminate, does it mean that
>> using val is undefined behavior?
>>
>> No; the reason that using an unspecified value is undefined behavior
>> is that on some implementations, an unspecified value could be
>> a trap representation.
>>
>> If we know that the implementation has no trap representation
>> in the type int, then an uninitialized value is in the same
>> category as val above: it's an unspecified value. Behavior
>> which depends on it is unspecified behavior.
>
> That makes sense.
>
> The problem is that (referring to N1570, and I don't see any relevant
> changes in the latest public C23 draft, N3096), Annex J says gives
>
> The value of an object with automatic storage duration is used
> while it is indeterminate (6.2.4, 6.7.9, 6.8).
>
> as an example of undefined behavior.
>
> If that is accurate, then this program:
>
> #include <limits.h>
> int main(void) {
> int foo;
> if (sizeof (int) == 4 &&
> CHAR_BIT == 8 &&
> INT_MAX == 2147483647 &&
> INT_MIN == -INT_MAX-1)
> {
> int bar = foo;
> }
> }
>
> has undefined behavior on an implementation where the condition is true.
> (Of course that UB is likely to manifest as quietly doing nothing.)
>
> Annex J is non-normative, and depends on normative statements
> elsewhere in the standard. Following the section numbers given in
> Annex J and searching for occurrences of "indeterminate value",
> I have so far been unable to confirm that the statement in Annex
> J is correct.
>
> Either Annex J is incorrect, or accessing an uninitalized
> automatic object is UB even if the object cannot possibly hold a
> trap representation. (I'd be satisfied either way; I'd like the
> standard to be internally consistent.)
>
> Perhaps someone else can find something in the standard that I've
> missed.
>

I can add something, but I don't know if you missed it - and it is not
at all conclusive.

6.7.9p10 says:

"""
If an object that has automatic storage duration is not initialized
explicitly, its value is indeterminate.
"""

I'm trying to find references to indicate that use of indeterminate
values is UB (and also what "use" means in this context). I see in
6.5.2.5p16 (this is in N2346, draft of C18) there is a note suggesting
that any use of an indeterminate value is UB, but I can't see it as
normative. It refers to Example 8 for compound literals (and note that
the variables involved are all locals) :

"""
16 Note that if an iteration statement were used instead of an explicit
goto and a labeled statement, the lifetime of the unnamed object would
be the body of the loop only, and on entry next time around p would have
an indeterminate value, which would result in undefined behavior.
"""

Other than that, an "indeterminate value" is either a trap or an
"unspecified value". Unspecified values can be used safely - they are
valid values of their type, even though you have no idea what the value
might be.

So it would seem to me that if your implementation does not have any
trap values for the type in question, using indeterminate
(uninitialised) values is only UB for local (automatic storage)
variables. (Note that _Bool's will have trap values on pretty much any
platform.)

On 19/07/2023 21:47, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 19/07/2023 18:22, Bart wrote:
>>> On 19/07/2023 15:27, David Brown wrote:
>>> > On 19/07/2023 13:07, Bart wrote:
>>> > For the language definition, it is about what makes sense in the code. C
>>> > is a typed language.  It does not make it very hard to mess around with
>>> > types, and it does not have good support for making your own types that
>>> > are convenient to use, but it /is/ a typed language.  A float is a float
>>> > - it is not an int, and it does not make sense to use it as an int.
>>> Isn't that how BCPL (an ancestor of C) worked? You just had chunks of
>>> memory and defined what they represented by the operations you chose.
>
> Yes. a * b multiplies the integer values of two words. a #* b
> multiplies the same words but interprets them as floating point. Being
> word based, this aspect was very clumsy as you'd need another set of
> operators to handle double precision floats. Indeed you'd need new
> operators if you wanted to handle more than one size of integer.

I haven't used BCPL, but Forth is very similar in this aspect. "+" adds
two words (16-bit integers by tradition, but 32-bit on some systems),
"F+" adds two floating point numbers, "D+" adds two double-precision
integers, etc. You can define whatever new operators you like.

>
> Years ago I sketch out a design for a "modern" BCPL where the width of
> objects could be stated. It was not very successful or I might have
> tried to implement it.
>
>> BCPL is before my time. But I think you are correct. C was intended to
>> have stronger typing than BCPL.
>
> You must be a youngster (for Usenet)! BCPL was still actively used for
> R&D in Cambridge in the 1980s. My UG dissertation (1982) used BCPL.

In 1982 I was 10 years old. I was familiar with BASIC on at least two
different machines, but I didn't look at other languages for another
couple of years. BCPL passed me by, as did Fortran and Algol.

>
> I really used to like BCPL (I've not used for a while so I might not get
> on with it anymore). It was surprisingly easy to use while remaining
> very close to the metal. I looked at it's modern successor MCPL a while
> back and I thought that looked interesting too.
>

On 19/07/2023 22:49, Bart wrote:
> On 19/07/2023 20:47, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 19/07/2023 18:22, Bart wrote:
>>>> On 19/07/2023 15:27, David Brown wrote:
>>>>   > On 19/07/2023 13:07, Bart wrote:
>>>>   > For the language definition, it is about what makes sense in the
>>>> code. C
>>>>   > is a typed language.  It does not make it very hard to mess
>>>> around with
>>>>   > types, and it does not have good support for making your own
>>>> types that
>>>>   > are convenient to use, but it /is/ a typed language.  A float is
>>>> a float
>>>>   > - it is not an int, and it does not make sense to use it as an int.
>>>> Isn't that how BCPL (an ancestor of C) worked? You just had chunks of
>>>> memory and defined what they represented by the operations you chose.
>>
>> Yes.  a * b multiplies the integer values of two words.  a #* b
>> multiplies the same words but interprets them as floating point.  Being
>> word based, this aspect was very clumsy as you'd need another set of
>> operators to handle double precision floats.
>
> OCaml uses different operators too. * for integer multiply, *. for float.

That's interesting. Usually stronger typed languages are able to use
overloading to let you re-use the same operator (though they might not
let you mix types, such as multiplying an integer and a floating point
number). I think having different operators for different types would
quickly get ugly if you want to support lots of types (such as different
sized integers).

OCaml has been on my list of languages to learn for many years, but has
not got near the top yet!

>
> I think that is to help with its type inference.
>
>

On Thu, 20 Jul 2023 01:46:07 -0700 (PDT)
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> One machine I worked on (the Nintendo 64) had nine bits per byte. However
> the C compiler and most assembly instructions only used 8 bits.The 9th
> bit was used by the GPU and you could access it using special machine
> instructions.

So I take it that the largest value you could get accessing a byte through
an unsigned char would be 255 rather than 511.

> It wasn't used for trap representations of course. But 32 logical bits
> doesn't necessarily means 32 physical bits.

On Thursday, 20 July 2023 at 10:51:39 UTC+1, Spiros Bousbouras wrote:
> On Thu, 20 Jul 2023 01:46:07 -0700 (PDT)
> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> > One machine I worked on (the Nintendo 64) had nine bits per byte. However
> > the C compiler and most assembly instructions only used 8 bits.The 9th
> > bit was used by the GPU and you could access it using special machine
> > instructions.
> So I take it that the largest value you could get accessing a byte through
> an unsigned char would be 255 rather than 511.
>
Yes. The vast majority of the instructions worked on multiples of 8 bits, and ignored
the ninth bit. So CHAR_BIT was 8 and unsigned char went from 0-255. However
by using a spot of assembly you could access the ninth bit and squeeze a bit
of extra data in. The ninth bit was physically present. The idea was that you could
pass rgba buffers to the GPU and it had a bit of wiggle room to help its internal
calculations.