On 20/07/2023 09:46, Malcolm McLean 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.
> It wasn't used for trap representations of course. But 32 logical bits doesn't necessarily
> means 32 physical bits.

The first machine I made (based on 8-bit Z80), used 6-bit bytes in parts
of the memory used for the text display buffer (because I was too tight
to buy two extra 1Kx1 chips to make it 8).

And 4-bit bytes in the memory used for the graphical display (to
simplify access when used in greyscale mode: each of the 128x128 pixels
had its own address).

I can't remember the details, but I'd hope the unused bits were pulled
down to appear as zeros, otherwise they would be read as 1s - maybe.

David Brown schrieb am Donnerstag, 20. Juli 2023 um 11:43:00 UTC+2:
> On 19/07/2023 22:49, Bart wrote:
> > On 19/07/2023 20:47, Ben Bacarisse wrote:
> >> David Brown <david...@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).

Forth is stack-based. Say you have two items on the integer stack and two items
on the fp-number stack. Overloading '+' doesn't work here because the compiler
wouldn't know on which stack to operate.

Its "queer" syntax is just a matter of getting used to it.

The benefit: Forth is so simple, efficient and compact; you can modify the compiler
as you wish to build your own DSL in just a few kilobytes.

On 7/20/23 05:07, Bonita Montero wrote:
> 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.
>
​The fact that it's possible doesn't mean that it will happen; again,
languages do not exist in a vaccuum.
--
⚗︎ | /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 20/07/2023 14:39, minf...@arcor.de wrote:
> David Brown schrieb am Donnerstag, 20. Juli 2023 um 11:43:00 UTC+2:
>> On 19/07/2023 22:49, Bart wrote:
>>> On 19/07/2023 20:47, Ben Bacarisse wrote:
>>>> David Brown <david...@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).
>
> Forth is stack-based. Say you have two items on the integer stack and two items
> on the fp-number stack. Overloading '+' doesn't work here because the compiler
> wouldn't know on which stack to operate.

Yes, exactly - Forth is basically untyped. OCaml is not stack based -
it is statically typed and makes heavy use of type inference, which
makes it more surprising (to me) that it has different operators for
different types.

>
> Its "queer" syntax is just a matter of getting used to it.
>
> The benefit: Forth is so simple, efficient and compact; you can modify the compiler
> as you wish to build your own DSL in just a few kilobytes.

1 1 + . -> 2 ok
: 1 2 ; -> ok
1 1 + . -> 4 ok

Yes, you can modify Forth as much as you like!

It's a powerful language in its way, but it gives plenty of interesting
ways to make a total mess :-)

Some of the "modern" variants are even more fun. In Color Forth, the
colour of identifiers influences their meaning. And the low-level Forth
used by GreenArray chips makes APL look clear and simple.

On 20/07/2023 13:55, David Brown wrote:
> On 20/07/2023 14:39, minf...@arcor.de wrote:

>> Forth is stack-based. Say you have two items on the integer stack and
>> two items
>> on the fp-number stack. Overloading '+' doesn't work here because the
>> compiler
>> wouldn't know on which stack to operate.
>
> Yes, exactly - Forth is basically untyped. OCaml is not stack based -
> it is statically typed and makes heavy use of type inference, which
> makes it more surprising (to me) that it has different operators for
> different types.
>
>>
>> Its "queer" syntax is just a matter of getting used to it.
>>
>> The benefit: Forth is so simple, efficient and compact; you can modify
>> the compiler
>> as you wish to build your own DSL in just a few kilobytes.
>
> 1 1 + . -> 2 ok
> : 1 2 ; -> ok
> 1 1 + . -> 4 ok
>
> Yes, you can modify Forth as much as you like!
>
> It's a powerful language in its way, but it gives plenty of interesting
> ways to make a total mess :-)
>
> Some of the "modern" variants are even more fun. In Color Forth, the
> colour of identifiers influences their meaning. And the low-level Forth
> used by GreenArray chips makes APL look clear and simple.

I've tried to get into Forth a few times but found it impossible. I just
can't get a grip on the language.

I even tried my own toy implementation, then when looking for examples
to download, found that every one used its own slightly different
dialect. It's a language you make up as you go. However simple stuff
like this works:

Bart-Forth
Type bye, quit or exit to stop
> 2 2 + .
4
>

As for its being small, I download GForth for Windows, it was about a
100KB executable. Not huge, but I have my own stack-based IL language
interpreter which is only 80KB (including a 30KB stdlib which could be
reduced).

But it's a real, full-spec language with support for i64, u64, f64, f32,
storage types of 8/16/32 bits, full pointer arithmetic, floating point
support /using the same stack/, has an FFI to call into external
routines including C etc.

(It can run most of my M-language programs, but interpreted, including
itself.)

It is intended for machine generation so it is not pretty, but it is
still easier for me to write code, if I had to do it manually, than in
Forth. Although of course a proper HLL is always superior.

My above example, usually submitted by file not REPL, would be:

loadimm 2
loadimm 2
add i64 # operators need type annotations
printi64

(Forth as a target language for a compiler has been proposed; I think it
makes a lousy target compared with my IL.)

Am 20.07.2023 um 14:49 schrieb Blue-Maned_Hawk:
> On 7/20/23 05:07, Bonita Montero wrote:
>> 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.
>>
>
> ​The fact that it's possible doesn't mean that it will happen; again,
> languages do not exist in a vaccuum.

C is chosen many times when C or C++ would be a viable option
and both would save much work.

On 20/07/2023 16:03, Bart wrote:
>
> On 20/07/2023 13:55, David Brown wrote:
> > On 20/07/2023 14:39, minf...@arcor.de wrote:
>
> >> Forth is stack-based. Say you have two items on the integer stack and
> >> two items
> >> on the fp-number stack. Overloading '+' doesn't work here because the
> >> compiler
> >> wouldn't know on which stack to operate.
> >
> > Yes, exactly - Forth is basically untyped.  OCaml is not stack based -
> > it is statically typed and makes heavy use of type inference, which
> > makes it more surprising (to me) that it has different operators for
> > different types.
> >
> >>
> >> Its "queer" syntax is just a matter of getting used to it.
> >>
> >> The benefit: Forth is so simple, efficient and compact; you can modify
> >> the compiler
> >> as you wish to build your own DSL in just a few kilobytes.
> >
> > 1 1 + .     -> 2 ok
> > : 1 2 ;     -> ok
> > 1 1 + .     -> 4 ok
> >
> > Yes, you can modify Forth as much as you like!
> >
> > It's a powerful language in its way, but it gives plenty of interesting
> > ways to make a total mess :-)
> >
> > Some of the "modern" variants are even more fun.  In Color Forth, the
> > colour of identifiers influences their meaning.  And the low-level Forth
> > used by GreenArray chips makes APL look clear and simple.
>
> I've tried to get into Forth a few times but found it impossible. I just
> can't get a grip on the language.
>

Like Yoda must you think if Forth to understand you are. Or something
like that!

While the stack notation lets you write simple things easily enough, it
gets ugly fast when you want to access data that is not on the stack.

I haven't done more than play around a little with it myself. But I
know some people who swear it's the best thing since sliced bread. I
guess it just takes time to get used to it.

> I even tried my own toy implementation, then when looking for examples
> to download, found that every one used its own slightly different
> dialect. It's a language you make up as you go. However simple stuff
> like this works:
>
>     Bart-Forth
>     Type bye, quit or exit to stop
>     > 2 2 + .
>     4
>     >
>

Yes, that's a big selling point of Forth - it is easy to make an
interpreter in it. And you can extend it in many ways - it's common to
have an assembler (with an RPN notation, naturally) in it.

I have also seen hardware description languages implemented in Forth. I
read of a system that used that to implement a CPU in an FPGA, and since
the software was all in Forth, you could basically pick which words (the
Forth term for functions) were hardware opcodes, and which were in
software. The design was extremely flexible about the balance between
size in the FPGA, and speed of the device.

> As for its being small, I download GForth for Windows, it was about a
> 100KB executable. Not huge, but I have my own stack-based IL language
> interpreter which is only 80KB (including a 30KB stdlib which could be
> reduced).

Well, remember that GForth includes an optimising compiler, not just an
interpreter. And it supports a /lot/ beyond basic Forth.

(You might get on with the maintainer of GForth. He is a rabid
gcc-hater who thinks compiler optimisations that take advantage of UB
are the biggest curse to face mankind. He is also extremely smart, and
GForth has all kinds of ugly tricks for speed.)

>
> But it's a real, full-spec language with support for i64, u64, f64, f32,
> storage types of 8/16/32 bits, full pointer arithmetic, floating point
> support /using the same stack/, has an FFI to call into external
> routines including C etc.
>
> (It can run most of my M-language programs, but interpreted, including
> itself.)
>
> It is intended for machine generation so it is not pretty, but it is
> still easier for me to write code, if I had to do it manually, than in
> Forth. Although of course a proper HLL is always superior.
>
> My above example, usually submitted by file not REPL, would be:
>
>     loadimm 2
>     loadimm 2
>     add i64             # operators need type annotations
>     printi64
>
> (Forth as a target language for a compiler has been proposed; I think it
> makes a lousy target compared with my IL.)

Forth as a target language has its advantages and disadvantages.

Many small processor designs - indeed, almost all 4-bit devices - use a
Forth-inspired instruction set. With small instructions you have no
room for coding register numbers - stack-based addressing is much
simpler. And when developing for them, your program simply builds up
words on top of the assembly code - it's more appropriate for these
things than C coding would be!

Forth was also used for a while for device drivers in hardware, with the
idea that hardware cards could have their driver code in Forth in a
little eeprom, and the host computer could run it regardless of the
processor. It did not really take off, however.

On 2023-07-20, David Brown <david.brown@hesbynett.no> wrote:
> 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.
> """

Here we can "macro expand" the definition of indeterminate;
this means exactly the same thing as "it has either an unspecified
value, or else a trap representation".

If the implementation doesn't have the latter, it has to be the former.

An unspecified value is very similar to unspecified behavior:

"[A] valid value of the relevant type where this International Standard
imposes no requirements on which value is chosen in any instance."

Note the word "valid"!

If the program subsequently makes a decision based on the value,
the behavior cannot be anything but unspecified.

This is not just automatic storage variables.

"The malloc function allocates space for an object whose size is
specified by size and whose value is indeterminate"

We can allocate space for a struct type with malloc.
When we assign values to the members, the padding bits in the
structure remain uninitialized.

Yet, we can copy a structure using memcpy, even if it has
indeterminate padding bits.

This is because the underlying model is that the structure is accessed
as an array of unsigned char, and that type has no trap representations.
Therefore, the memcpy is reliably making a replica of the unspecified
values; the copied structure faithfully replicates the padding bits of
the original, that don't contribute to the value of its members.

I think that it is a defective wording to say that the use of an
indeterminate value is undefined behavior, because only in the situation
in which we don't know anything about the characteristics of the
implementation do we not know whether the behavior will be defined and
so have to conclude that we don't know the definition of behavior.

But we always know the characteristics of the implementation on which we
are running a program, and whether or not a given type has trap
representations.

Implementation, as an aggregate, do not have behavior. All
implementations exhibit behavior individually.
There are obvious ways in which a program can have undefined behavvior
on one implementation, but not another:

We don't assert that "1U << 31" has undefined behavior, only that it has
undefined behavior if unsigned int doesn't have at least 32 value bits.
There is no behavior without an implementation, and there is no
implementation without characteristics being pinned down.

Individual language constructs have behavior, but always in
consideration of being inside an implementation, where we take into
account all characteristics that are relevant to that construct.

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

Am 20.07.2023 um 16:25 schrieb Bonita Montero:
> Am 20.07.2023 um 14:49 schrieb Blue-Maned_Hawk:
>> On 7/20/23 05:07, Bonita Montero wrote:
>>> 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.
>>>
>>
>> ​The fact that it's possible doesn't mean that it will happen; again,
>> languages do not exist in a vaccuum.
>
> C is chosen many times when C or C++ would be a viable option
^ Rust
> and both would save much work.
>
>

Kaz Kylheku ha scritto:
> On 2023-07-17, David Brown <david.brown@hesbynett.no> wrote:
>> On 17/07/2023 12:16, Malcolm McLean wrote:
>>> On Monday, 17 July 2023 at 02:43:50 UTC+1, Ben Bacarisse wrote:
>>> messy (if you've several similar functions, do you create the same union everywhere
>>> in local scope, as you did, or do you create one in global scope - neither answer
>>> is ideal).
>>
>> Your code is messy too. It's okay for something as rarely needed as
>> this to be a bit verbose.
>
> But does it have to be verbose? Maybe we could use macros to shorten it.
>
> We had this bit of code upthread:
>
> inline bool sign_bit(float f)
> {
> union {
> uint32_t u;
> float f;
> } u;
> u.f = f;
> return u.u & 0x80000000;
> }
>
>
> The kernel here is that a union is declared with two members, of
> different types. It is initialized with one, and accessed with the other.
>
> With C99 syntax, we can do that as one expression:
>
> #include <stdio.h>
>
> #define union_cast(to_type, from_type, value) \
> ((union { to_type to; from_type from; }){ .from = (value) }.to)
>

Around the web I found this macro similar to yours:

#define chk_sign(from_type, value) \
(!!(union { from_type from; \
struct { \
uint64_t rest : ((sizeof(from_type) * CHAR_BIT) -
1); \
uint64_t sign : 1; \
} to; \
}) { .from = (value) }.to.sign)

>
> int main(void)
> {
> float x = 4.2;
> unsigned y = union_cast(unsigned, float, x);
> printf("%x\n", y);
> return 0;
> }
>
> Output produced:
>
> 40866666
>
> We could have a static assertion in there that to_type and from_type
> are of the same size and whatnot.
>

On 2023-07-20, jak <nospam@please.ty> wrote:
> Kaz Kylheku ha scritto:
>> With C99 syntax, we can do that as one expression:
>>
>> #include <stdio.h>
>>
>> #define union_cast(to_type, from_type, value) \
>> ((union { to_type to; from_type from; }){ .from = (value) }.to)
>>
>
> Around the web I found this macro similar to yours:
>
> #define chk_sign(from_type, value) \
> (!!(union { from_type from; \
> struct { \
> uint64_t rest : ((sizeof(from_type) * CHAR_BIT) -
> 1); \
> uint64_t sign : 1; \
> } to; \
> }) { .from = (value) }.to.sign)

That alone not work on anything but big endian machines.

Look at that file again to see whether it has something like

#if BIG_ENDIAN
#define chk_sign ... // the above definition
#else
#define chk_sign ... // alternative with rearranged union
#endif

A common allocation strategy for bitfields is that they follow
endianness. When a 1-bit field is allocated into a brand new
bitfield packing cell (which could be int-sized or whatever),
it goes into the lowest-offset byte first.

Within a byte, the order goes from MSB to LSB on big endian,
and LSB to msb on little endian:

Thus, here if we put 0x80 into x:

union {
unsigned char x;
unsigned y : 1;
};

then y will be 1 on big endian, 0 on little.

We cannot necessarily deduce all this from the ISO C standard, but
that's the way it is with GCC.

In device drivers it's not uncommon to see this:

struct foo_registers {
// 32 bit status word
#if BIG_ENDIAN
unsigned int on_fire : 1;
unsigned int read_ready : 1;
unsigned int locked_up : 1;
/// ... 29 more
#else
/// ... 29 more
unsigned int locked_up : 1;
unsigned int read_ready : 1;
unsigned int on_fire : 1;
#endif
}

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

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

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

ML (the language that OCaml is based on) uses the same operators for all
arithmetic, so mixed type arithmetic can become complicated. Haskell
has the same issue. It's what flummoxes most beginners in the first few
days. Since both Haskell and ML have strong type inference, they look,
to the uninitiated, like scripting languages with run-time determined
types, so it's baffling (at first) when one needs all those fromIntegral
calls.

I don't know for sure, but I'd bet that is why OCaml went with distinct
operators.

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

It certainly does that. I'm just not 100% sure that that was why the
decision was made.

--
Ben.

On 7/20/2023 2:38 AM, David Brown wrote:
> On 19/07/2023 21:47, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
[...]
> 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.
[...]

Fwiw, In 1982 I was 5 years old and working with BASIC, LOGO and PILOT
on my trusty Atari.

On 7/20/2023 5:39 AM, minf...@arcor.de wrote:
> David Brown schrieb am Donnerstag, 20. Juli 2023 um 11:43:00 UTC+2:
>> On 19/07/2023 22:49, Bart wrote:
>>> On 19/07/2023 20:47, Ben Bacarisse wrote:
>>>> David Brown <david...@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).
>
> Forth is stack-based. Say you have two items on the integer stack and two items
> on the fp-number stack. Overloading '+' doesn't work here because the compiler
> wouldn't know on which stack to operate.
>
> Its "queer" syntax is just a matter of getting used to it.

What is "queer" syntax?

On 7/20/2023 1:46 AM, Malcolm McLean wrote:
> 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:
[...]
> One machine I worked on (the Nintendo 64)

Nice!

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

Kaz Kylheku ha scritto:
> On 2023-07-20, jak <nospam@please.ty> wrote:
>> Kaz Kylheku ha scritto:
>>> With C99 syntax, we can do that as one expression:
>>>
>>> #include <stdio.h>
>>>
>>> #define union_cast(to_type, from_type, value) \
>>> ((union { to_type to; from_type from; }){ .from = (value) }.to)
>>>
>>
>> Around the web I found this macro similar to yours:
>>
>> #define chk_sign(from_type, value) \
>> (!!(union { from_type from; \
>> struct { \
>> uint64_t rest : ((sizeof(from_type) * CHAR_BIT) -
>> 1); \
>> uint64_t sign : 1; \
>> } to; \
>> }) { .from = (value) }.to.sign)
>
> That alone not work on anything but big endian machines.
>
> Look at that file again to see whether it has something like
>
> #if BIG_ENDIAN
> #define chk_sign ... // the above definition
> #else
> #define chk_sign ... // alternative with rearranged union
> #endif
>
> A common allocation strategy for bitfields is that they follow
> endianness. When a 1-bit field is allocated into a brand new
> bitfield packing cell (which could be int-sized or whatever),
> it goes into the lowest-offset byte first.
>
> Within a byte, the order goes from MSB to LSB on big endian,
> and LSB to msb on little endian:
>
> Thus, here if we put 0x80 into x:
>
> union {
> unsigned char x;
> unsigned y : 1;
> };
>
> then y will be 1 on big endian, 0 on little.
>
> We cannot necessarily deduce all this from the ISO C standard, but
> that's the way it is with GCC.
>
> In device drivers it's not uncommon to see this:
>
> struct foo_registers {
> // 32 bit status word
> #if BIG_ENDIAN
> unsigned int on_fire : 1;
> unsigned int read_ready : 1;
> unsigned int locked_up : 1;
> /// ... 29 more
> #else
> /// ... 29 more
> unsigned int locked_up : 1;
> unsigned int read_ready : 1;
> unsigned int on_fire : 1;
> #endif
> }
>

In fact, it is how you are saying but #if BIG_ENDIAN was distant several
lines and I have not seen it. My bad.

David Brown <david.brown@hesbynett.no> writes:
> On 20/07/2023 00:23, Malcolm McLean wrote:
>> On Wednesday, 19 July 2023 at 23:13:17 UTC+1, Keith Thompson wrote:
[...]
>>> 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.

Not necessarily; my results using clang matched Malcolm's.

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

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

David Brown <david.brown@hesbynett.no> writes:
[...]
> Like Yoda must you think if Forth to understand you are. Or something
> like that!
[...]

An old bumper sticker: "4TH ♥ IF HONK THEN"

--
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 19/07/2023 23:12, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:

>> 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 is a fake result. gcc even at -O0 does not actually attempt to do
the comparison, it just calls that first printf anyway. Code for the
other printf does not appear in the compiler output (this is version 10.x).

That is the case even when `n` is external. It assumes that n+1 must be
greater than n, always.

If I compare two externs a and b (set elsewhere to INT_MAX+1 and
INT_MAX), then I get <= like my compilers.

This means that gcc can give inconsistent results when apparently
comparing the same two pairs of values.

TBH I found it hard to predict the results of x64's cmp followed by jle.
But what's not hard however is predicting the result of INT_MAX+1. My
tools which don't try to be clever, will give more consistent results.

gcc assumes ints don't wrap, but sometimes they do.

Bart <bc@freeuk.com> writes:
> On 19/07/2023 23:12, Keith Thompson wrote:
[...]
>> 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 is a fake result.

No, it's not. It's exactly the output the program produced when I
compiled and ran it.

Please explain what you mean by "fake result". Are you insinuating that
I lied about it?

> gcc even at -O0 does not actually attempt to do
> the comparison, it just calls that first printf anyway. Code for the
> other printf does not appear in the compiler output (this is version 10.x).
>
> That is the case even when `n` is external. It assumes that n+1 must
> be greater than n, always.

Which is a valid assumption.

> If I compare two externs a and b (set elsewhere to INT_MAX+1 and
> INT_MAX), then I get <= like my compilers.

That's not surprising. (Of course nothing was actually set to
INT_MAX+1; something was set to the undefined result of evaluating that
expression.)

> This means that gcc can give inconsistent results when apparently
> comparing the same two pairs of values.

Certainly. That kind of thing is completely unsurprising for code whose
behavior is undefined.

[...]

I can explain the language rules to you. I can't understand them for you.

--
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 Friday, 21 July 2023 at 00:58:50 UTC+1, Keith Thompson wrote:
> Bart <b...@freeuk.com> writes:
> > On 19/07/2023 23:12, Keith Thompson wrote:
> [...]
> >> 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 is a fake result.
> No, it's not. It's exactly the output the program produced when I
> compiled and ran it.
>
> Please explain what you mean by "fake result". Are you insinuating that
> I lied about it?
> > gcc even at -O0 does not actually attempt to do
> > the comparison, it just calls that first printf anyway. Code for the
> > other printf does not appear in the compiler output (this is version 10.x).
> >
> > That is the case even when `n` is external. It assumes that n+1 must
> > be greater than n, always.
> Which is a valid assumption.
>
Try this one.

#include <stdio.h>
#include <stdint.h>
#include <string.h>

int main(void)
{ uint32_t nanpattern = 0x7f801234;
float x;

memcpy(&x, &nanpattern, 4);
printf("x %f\n", x);
if (x + 1 > x)
{
printf("Doesn't honour nan\n");
}
else
{
printf("Nan handled correctly\n");
}

return 0;
}

If it behaves in the same way then it is bugged.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> Try this one.
>
> #include <stdio.h>
> #include <stdint.h>
> #include <string.h>
>
> int main(void)
> {
> uint32_t nanpattern = 0x7f801234;
> float x;
>
> memcpy(&x, &nanpattern, 4);
> printf("x %f\n", x);
> if (x + 1 > x)
> {
> printf("Doesn't honour nan\n");
> }
> else
> {
> printf("Nan handled correctly\n");
> }
>
> return 0;
> }

On my system, it prints:
x nan
Nan handled correctly
when compiled with both gcc and clang at all optimization levels.

> If it behaves in the same way then it is bugged.

You may be right (assuming 0x7f801234 copied into a float yields a NaN;
I don't think the C standard specifies that), but I haven't given it
much though.

For any two valid integer values x and y, exactly one of x<y, x==y, x>y
is true. That's not the case for floating-point values, which means
that a compiler cannot assume (x + 1 > x) without information about the
value of x (given an implementation that supports NaNs).

--
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 21/07/2023 00:58, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 19/07/2023 23:12, Keith Thompson wrote:
> [...]
>>> 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 is a fake result.
>
> No, it's not. It's exactly the output the program produced when I
> compiled and ran it.
>
> Please explain what you mean by "fake result". Are you insinuating that
> I lied about it?

No. gcc on my machine hard-codes that output without bothering to
execute the comparison to see what the hardware does with it.

Because it makes an assumption about the result of comparing n+1 with n.
If those same two values were compared via variables where it did not
not know their values and their relationship, it would be forced to do
an actual comparison.

On my machine, that produced a different result even still comparing
values of INT_MAX+1 with INT_MAX.

Bart <bc@freeuk.com> writes:
> On 21/07/2023 00:58, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 19/07/2023 23:12, Keith Thompson wrote:
>> [...]
>>>> 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 is a fake result.
>> No, it's not. It's exactly the output the program produced when I
>> compiled and ran it.
>> Please explain what you mean by "fake result". Are you insinuating
>> that
>> I lied about it?
>
> No. gcc on my machine hard-codes that output without bothering to
> execute the comparison to see what the hardware does with it.

Are you saying that that's what you meant by "fake result"? Are you
saying there's something "fake" about not emitting an ADD instruction in
response to a C "+" operation? Is evaluating 2+2 at compile time
"fake"?

> Because it makes an assumption about the result of comparing n+1 with
> n. If those same two values were compared via variables where it did
> not not know their values and their relationship, it would be forced
> to do an actual comparison.

Yes. Are you under the impression I didn't know that? Do you think the
assumption is invalid, given that the code's behavior is undefined?

> On my machine, that produced a different result even still comparing
> values of INT_MAX+1 with INT_MAX.

And what exactly is your point?

Or are you just trying to make this look worse and more complicated than
it really is?

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

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

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

Non-normative, as I am sure you know. And, as I said elsewhere, if it
accurately reflects the intent, then it explicitly excludes the case in
point with allocated storage.

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

So everyone says, but no one has produced the normative text that says
so. I was trying to get there. I think there's some justification for
saying the something that is potentially UB could be called UB. It's
not a strong argument, but is there anything better? What's your
reasoning?

There's another case that has also come up before. It's often said that
conversion of an out-of-rang value to int is undefined, and indeed
Appendix J.2 p16 says "Conversion to or from an integer type produces a
value outside the range that can be represented (6.3.1.4)" but 6.3.1.4
only refers to the conversion between real and int types. It says --
explicitly -- that

int i = 1e123;

is undefined (for sane integer widths). But this:

int i = UINT_MAX;

is also a conversion "to or from an integer type" that (for the usual
sizes) "produces a value outside the range that can be represented".
But the normative text (6.3.1.3) says that if

"the new type is signed and the value cannot be represented in it;
either the result is implementation-defined or an
implementation-defined signal is raised"

so I tried the "if it /might/ UB it /is/ UB" argument on this one too in
the past. I'm not sure anyone bought it then either. I'm not sure I
buy it!

>> 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 should only note it if it's true! Is it?

--
Ben.