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

> Po Lu <luangruo@yahoo.com> writes:
>
>> kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
>>
>>> Po Lu <luangruo@yahoo.com> wrote:
>>>
>>>> kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
>>>>
>>>>> No. Lots of C programs are quite portable. That includes e.g. Linux
>>>>> kernel, BSD kernels, PostgreSQL, Apache, Postfix, and many,
>>>>> many other Unix daemons. PostgreSQL runs not only on Unix
>>>>> but even on Windows. Possibly OpenLDAP does, too.
>>>>
>>>> Yet none of these programs strictly conform to a Standard. They are
>>>> more or less conforming programs, meaning that they are acceptable
>>>> to
>>>> the C implementations that they have been ported to.
>>>
>>> You could well be right. But invoking UB is something so evil
>>> that no C or C++ program must ever do it, meaning that the
>>> programmers must know enough to avoid it.
>>>
>>> Since you seem to be confident about your claim, is it possible
>>> for you to describe what aspects of Postfix are non-corforming
>>> C code?
>>
>> Not strictly conforming? Easy: any code that assumes char is 8 bits
>> wide, or that int can hold values larger than 32766.
>
> 32767.
>
> Or any code whose behavior depends on those things. For example, this:
>
> #include <stdio.h>
> #include <limits.h>
> int main(void) {
> printf("%d\n", INT_MAX);
> }
>
> is in a sense 100% portable to any hosted implementation, but it's not
> strictly conforming.
>
>>> Speaking of MTAs, Sendmail was/is portable enough so that it runs
>>> on practically every modern and not-so-modern UNIX. This being
>>> the case, one could assume that its C code must be very
>>> standards compliant, no? What do you think?
>>
>> What exactly is ``standards compliance''?
>> Mere conformance, or strict conformance?
>
> A "conforming program" is one that is acceptable to a conforming
> implementation -- an almost absurdly weak condition. If there's a C
> implementation that accepts Fortran programs as an extension (after
> issuing any required diagnostic), then a Forgran program is a
> "conforming program", though I doubt that the authors meant the
> definition to be quite that loose.
>
> But I think there's an intermediate level of conformance: a "correct
> program".
>
> A program that is correct in all other aspects, operating on correct
> data, containing unspecified behavior shall be a correct program and
> act in accordance with 5.1.2.3.
>
> (This in section 4 of the ISO C standard.)

Note that a "correct program" can include programs that depend on
unspecified behavior, and on implementation-defined behavior, and
on implementation-specific extensions covering particular cases
of undefined behavior. There is nothing "incorrect" about
depending on extensions that cover areas of undefined behavior.

Paul N <gw7rib@aol.com> writes:

> On Friday, July 14, 2023 at 6:26:20?PM UTC+1, Kalevi Kolttonen wrote:
>
>> David Brown <david...@hesbynett.no> wrote:
>>
>>>> Your code containing UB can work fine in the environment that you
>>>> use, but it might not work when you compile it elsewhere.
>>>
>>> Just like other bugs.
>>
>> Could you please provide a simple example of such a bug,
>> i.e. it must a bug that is not caused by relying on
>> Implementation Defined behavior or Undefined Behavior?
>
> I think you could get such a bug if you assume that the letters of
> the alphabet all have consecutive values. It's true of many
> computers today, but was not true of the mainframe when I was at
> university, which used EBCDIC instead of ASCII. As I understand it,
> this is not "Implementation Defined behaviour" because there is no
> requirement to say what values the letters have.

The values of members of the execution character set are indeed
implementation defined. Section 5.2.1, paragraph 1.

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

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

This indent does not alter the meaning. If the intent was to print
65535, the programmer needs to consider other careers.

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

No, I don't mean that. I don't mean either of your suggested
re-wordings. And, yes, we need context. The context is using English
to approximate the formal semantics of a C program. We are not
discussing a machine or probable values. We are discussing the
semantics of a computer programming language. In that context "unsigned
int" behaves like a type variable. All we know about it is what the C
standard says about unsigned int. We know its relative rank, for
example, and we know that -1u is an expression whose value is it's
largest value.

--
Ben.

Kaz Kylheku <864-117-4973@kylheku.com> writes:

[slightly reformatted for white space]

> 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 again. It works fine on my little endian machine.

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

Defining an indeterminate "value" as possibly being a trap
"representation" confuses the distinction between a representation of a
value and the value represented. I think it would have been better to
specify that an object can contain an indeterminate representation,
which is either a trap representation or a representation of an
unspecified value. They didn't consult me about it, for some reason :-).

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

Yes, whenever it's possible to determine that a given type has no trap
representations, an indeterminate value of that type can only be an
unspecified value. The standard guarantees directly that some types have
no trap representations, and you can derive the fact that unsigned char
has no trap representations from the fact that the number of different
non-trap representations it is required to have leaves no room for any
representations to be trap representations.

As a separate matter, if an implementation documents that a given type
has no trap representations, indeterminate values of that type cannot be
trap representations when using that implementation, regardless of
whether they might be on some other implementation.

On Friday, 21 July 2023 at 01:50:51 UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@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.
>
That's why I printed it out. Just to check.
IEEE 754 mandates a particular pattern for a 32 bit float, and virtually everyone
now uses that standard. But the C standard doesn't require it. However IEEE 754
doesn't impose endianness requirements. But usually when interpreted as a 32
bit integer, the sign bit will be the most significant bit, the exponent bits the next bits,
and the mantissa the least significant bits.
>
> 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).
>
Yes, exactly. it shouldn't assume that x + 1 > x for integer arithmetic either because

if (x + 1 > x)
{ y = x + 1;
if ( y > x) /* must be true ? */
}

and gcc's behaviour is undesireable.

On 7/20/23 13:48, Bonita Montero wrote:
> 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.
>>
>>
>
​What evidence have you that they would save work? On the contrary, i'd
say that the insane complexity of C++ and the hostile culture
surrounding Rust both would interfere with getting work done.
--
⚗︎ | /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 😩

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

[considering the rules for accessing an object of one type
when using an lvalue of a different type].

> There should be a name for this relationship between types, like
> "effectively compatible", but there isn't one in the language
> standard, and I don't think there is on that is widely used.
> Maybe we could use "effectively compatible"...

I don't like "effectively compatible" for two reasons. One,
the word "effectively" is commonly used with a different
meaning, and that would confuse the issue. Two, the word
"compatible" suggests a symmetric relationship, but the
effective type rules are not symmetric, so "compatible"
would be misleading, or at least confusing.

> Similarly, you will see people talk about two types being
> "assignment compatible" in order to refer to the related (but
> different) rules covering assignment and argument passing. The
> standard itself even refers to these rules in a number of
> places, but without a name for them, it must reference "the
> constraints of 6.5.16.1" instead!

Here again "compatible" is a poor fit because the type rules
for assignment are not symmetric. I might suggest, without
thinking about it too deeply, "assignment permissible" as
an adjective for describing the types on the right-hand
side of an assignment. This phrase could be extended with
a "for (left-hand-side type)" where needed, as for example
"the type of the expression '*p' is not assignment permissible
for an int* target".

Am 21.07.2023 um 08:06 schrieb Blue-Maned_Hawk:

> ​What evidence have you that they would save work?  On the contrary,
> i'd say that the insane complexity of C++ and the hostile culture
> surrounding Rust both would interfere with getting work done.

If you're know C++ halfway you're multiple times faster than
with C, where you have to deal with every details yourself.
There is no more rudimentary language than C in that sense.
I'm developing C++ since 1992 and maybe I've missed some useful
features, but it's easy to learn additional features by the way.

On 21/07/2023 01:24, Bart wrote:
> 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.

That's a silly thing to say. Keith did the test, and gave the 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).

The compiler knows that for any int, "n + 1" is bigger than "n". It
generates code accordingly.

The unsigned integer types in C form modulo groups, and comparisons are
not as simple, but the signed integer types model a subset of
mathematical integers as best as can be done in a limited range. Many
mathematical identities hold true for C ints, which they would not do if
they used modulo arithmetic.

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

Yes. It makes perfect sense.

Of course, a compiler is /also/ free to actually read "n", calculate "n
+ 1" according to the specifications of the language, and do the
comparison. It will get the same result for any "n" for which "n + 1"
is defined. And it can pick any value it wants for "INT_MAX + 1",
including impossible values that are not valid "int" values. So it
could pick "something bigger than INT_MAX" and get the same result as
before. Or it could pick "INT_MIN" and get a different result for the
comparison. Or it could pick 42, "bananas", or an invisible pink
unicorn, or a compile-time error. (But "something bigger than INT_MAX"
and INT_MIN are the two likely candidates.)

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

Compilers only make use of information they have to optimise code if it
actually optimises the code. They don't go out of their way to detect
instances of UB (unless you choose such modes, for checking your code or
fault-finding).

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

Yes. Is the concept of UB new to you?

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

gcc assumes your integer arithmetic does not overflow - and that if it
does, you don't care about the resulting behaviour of the code. That's
what UB means.

Why is this stuff so hard for you to understand? Look at 3.4.3 in the C
standards, defining the term "undefined behaviour". Read it, and see if
there is anything there that does not match up with what you have seen
above. If there is anything you are still not clear about, ask.

3.4.3

1 undefined behavior

behavior, upon use of a nonportable or erroneous program construct or of
erroneous data, for which this International Standard imposes no
requirements

2 NOTE Possible undefined behavior ranges from ignoring the situation
completely with unpredictable results, to behaving during translation or
program execution in a documented manner characteristic of the
environment (with or without the issuance of a diagnostic message), to
terminating a translation or execution (with the issuance of a
diagnostic message).

3 EXAMPLE
An example of undefined behavior is the behavior on integer overflow.

On 21/07/2023 07:46, Malcolm McLean wrote:
> On Friday, 21 July 2023 at 01:50:51 UTC+1, Keith Thompson wrote:

I don't know enough about the details of floating point operations -
either in IEEE or in C - to comment about it.

(For my own use of floating point in my code, it's all good, solid
finite numbers in reasonable ranges, and I use "-ffast-math" for
efficiency, especially on small devices. That makes it easy!)

>> 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).
>>
> Yes, exactly. it shouldn't assume that x + 1 > x for integer arithmetic either because
>
> if (x + 1 > x)
> {
> y = x + 1;
> if ( y > x) /* must be true ? */
> }
>
> and gcc's behaviour is undesireable.
>

If x is less than INT_MAX, then this sets y to x + 1 and the comparison
is always true. Agreed?

If x is equal to INT_MAX, then "if (x + 1 > x)" is undefined behaviour
and the compiler can do anything it likes - including assuming that the
comparison is true. The assignment "y = x + 1;" is also undefined
behaviour, and the compiler can put anything it likes in y - including
trapping values, leaving it uninitialised, keeping a "mental" note that
it is bigger than x, or firing off an email to the programmer's boss
saying that the programmer needs a refresher course on basic C.

The simplest, most efficient code consistent with all that is for the
compiler to assume the comparison is true. And that is the /desirable/
behaviour, because people who write correct code deserve to get
efficient results, not bigger and slower code just because some other
programmer has made a mistake.

On 21/07/2023 03:49, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 19/07/2023 21:21, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
<snip>
>>
>> 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).
>> """
>>
<snip>
>>
>> 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?
>

I have to agree with you here. I really cannot see a convincing
argument for why using indeterminate values in local variables is UB.
As you say, J.2 is not normative - but I had assumed that it contained
valid summaries of the normative text. (i.e., The paragraph in J.2
implied there was nominative text marking such accesses as UB, and I
just could not find them.) However, when no one here can see any
nominative text to that effect, maybe it simply doesn't exist - the J.2
paragraph could be an error, or a left-over from earlier drafts.

I think we can agree that if an indeterminate value is a trap value,
using it is undefined behaviour (6.2.6.1p5). And pretty much any
implementation will have trap values for _Bool, but perhaps not for any
other types. So as long as we stick to types with no trap values, I
can't see any normative justification for use being UB.

I see Keith has punted this one uphill to comp.standards.c, so we will
see if anything interesting comes out of that.

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

I think the answer to that is now indeterminate :-) (More seriously, I
hope Keith's c.s.c post gives a definite answer.)

Do you happen to know the corresponding situation for C++? The
standards there tend to be more complicated, but they might give insights.

On 21/07/2023 00:54, Keith Thompson wrote:
> 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"
>

:-)

On 20/07/2023 22:04, Chris M. Thomasson wrote:
> On 7/20/2023 5:39 AM, minf...@arcor.de wrote:

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

Syntax significantly different from that of other languages you are used
to. So of course it is an entirely subjective term. But given that
this is comp.lang.c, "queer syntax" would mean something radically
different to that of C, and unfamiliar to people whose only programming
language is C.

On 20/07/2023 22:03, Chris M. Thomasson wrote:
> 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.
>

I didn't see a computer until I was about 6 or 7 - a Commodore PET (with
dual tape drives!).

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
> 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've posted about this to comp.std.c (subject "Does reading an
uninitialized object have undefined behavior?") and emailed the C23
editors. (It's likely too late to make any significant changes to C23.)

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

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Friday, 21 July 2023 at 01:50:51 UTC+1, Keith Thompson wrote:
[...]
>> 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).
>>
> Yes, exactly. it shouldn't assume that x + 1 > x for integer arithmetic either because
>
> if (x + 1 > x)
> {
> y = x + 1;
> if ( y > x) /* must be true ? */
> }
>
> and gcc's behaviour is undesireable.

gcc's behavior is consistent with the standard.

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

David Brown <david.brown@hesbynett.no> writes:
[...]
> The compiler knows that for any int, "n + 1" is bigger than "n". It
> generates code accordingly.
[...]

Quibble: for any int value *for which n + 1 is defined*, n + 1 is
greater than n. (And for any int value for which n + 1 is not defined,
which is only INT_MAX, UB means the compiler can do what it likes.)

--
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 02:28, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 21/07/2023 00:58, Keith Thompson wrote:
>>> 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"?

Transforming 2+2 is more acceptable since the result is always going to
be consistent. It is not controversial.

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

What was yours?

You posted a piece of code and challenged people to try it themselves on
their own platforms.

However, the platform doesn't matter: gcc will always produce that
result no matter what. It does not attempt to put the actual hardware to
the test.

There was me looking at the output of my compilers trying to figure why
it was different, and gcc is not even bothering generating the instructions.

It's a like taking a program that calculates and prints fib(36), and
then discovering that the winning compiler or interpreter is only
emitting puts("14930352") and not doing the actual work.

Suppose someone is tasked with surveying dozens of machines to find out
exactly what `if (n+1>n)` produces. Well, if they're using gcc, they
might as well not bother, as they're not going to find out what /the
machine/ produces, only what gcc has decided it should produce.

Presumably your point was to demonstrate something about the
unpredictability of UB, but your chosen compiler had already made up its
mind in advance that it was going to do X no matter what!

This is what you said:

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

I doubt anything would make gcc do anything different!

But if you still can't see my objection, then forget it.

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

I consider inconsistency in comparing the same two values to be poor.
That is, comparing INT_MIN with INT_MAX. Because if you do this:

int b = INT_MAX;
int a = b+1; // yields INT_MIN even with gcc

if (a>b) {

that will get a different results compared with 'if (b+1, b)`. Is that
supposed to be good?

Comparing values at the limits of a type's bounds is always going to be
dodgy anyway, but at least you might expect the results to be always the
same.

Note that if you do this test using unsigned and UINT_MAX, gcc also
hardcodes the result, even this in this case it knows that b+1 could
wrap around to zero. The result showed will be wrong, but so is mine. At
least it is consistent with the signed version!

On Friday, 21 July 2023 at 11:21:32 UTC+1, Bart wrote:
>
> Note that if you do this test using unsigned and UINT_MAX, gcc also
> hardcodes the result, even this in this case it knows that b+1 could
> wrap around to zero. The result showed will be wrong, but so is mine. At
> least it is consistent with the signed version!
>
Did you write
unsigned int x = UINT_MAX;
if(x + 1 > x)

or

if(x + 1u > x)

?

C has some weird rules about expressions going to an int which date back to
the days of implict int.
I don't have a Linux machine handy so I can't test gcc.

On 21/07/2023 11:44, Malcolm McLean wrote:
> On Friday, 21 July 2023 at 11:21:32 UTC+1, Bart wrote:
>>
>> Note that if you do this test using unsigned and UINT_MAX, gcc also
>> hardcodes the result, even this in this case it knows that b+1 could
>> wrap around to zero. The result showed will be wrong, but so is mine. At
>> least it is consistent with the signed version!
>>
> Did you write
> unsigned int x = UINT_MAX;
> if(x + 1 > x)
>
> or
>
> if(x + 1u > x)
>
> ?

I wrote x+1, but using 1u didn't make any difference.

Since I think I forgot to write `unsigned`, only `UINT_MAX` and "%u"!

Using `unsigned`, then gcc does do the actual comparison. And this way
the results of comparing the same two values, UINT_MIN and UINT_MAX, are
consistent no matter how it is done.

(Doing u32 + i32 I think would yield a u32 result, in which case the 1u
is not necessary.)

On 21/07/2023 11:24, Keith Thompson wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On Friday, 21 July 2023 at 01:50:51 UTC+1, Keith Thompson wrote:
> [...]
>>> 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).
>>>
>> Yes, exactly. it shouldn't assume that x + 1 > x for integer arithmetic either because
>>
>> if (x + 1 > x)
>> {
>> y = x + 1;
>> if ( y > x) /* must be true ? */
>> }
>>
>> and gcc's behaviour is undesireable.
>
> gcc's behavior is consistent with the standard.
>

And it is desirable, at least to some people - such as myself, and
presumably also the gcc developers.

On 21/07/2023 12:21, Bart wrote:
> On 21/07/2023 02:28, Keith Thompson wrote:
> > Bart <bc@freeuk.com> writes:
> >> On 21/07/2023 00:58, Keith Thompson wrote:
> >>> 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"?
>
> Transforming 2+2 is more acceptable since the result is always going to
> be consistent. It is not controversial.

If it is merely "more" acceptable, then it is still controversial.
There will be people who don't understand how the C language works who
feel it should be translated into assembly instructions to add 2 and 2.
You understand a bit more than such people, and thus think 2 + 2 can be
pre-calculated at compile time, but you apparently still don't
understand that the same applies to the comparison in Keith's program.

>
>
> >> 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?
>
> What was yours?

His point - if I may be so bold as to interpret Keith's post - was that
real-world compilers regularly make use of assumptions about UB in order
to generate more efficient code. An example does not prove that this is
how the C language is defined, but it /does/ prove that mainstream
toolmakers believe that. (And the people behind the gcc compiler know
more about the definition of the language than you or I do.)

>
> You posted a piece of code and challenged people to try it themselves on
> their own platforms.

No, he did not. He posted a piece of code and ran it on his own system.

>
> However, the platform doesn't matter: gcc will always produce that
> result no matter what. It does not attempt to put the actual hardware to
> the test.
>

Why would you think it would do that? There's nothing
hardware-dependent in Keith's program.

When I am investigating how a compiler treats particular code pieces, I
usually don't bother running it at all on any hardware - it's a lot more
efficient and insightful (to me) to use godbolt and look at the
generated assembly. The hardware is irrelevant, beyond
implementation-dependent details like the size of the types and the
value of INT_MAX.

> There was me looking at the output of my compilers trying to figure why
> it was different, and gcc is not even bothering generating the
> instructions.
>

If you had looked up instead, you'd have seen Keith's point flying over
your head.

> It's a like taking a program that calculates and prints fib(36), and
> then discovering that the winning compiler or interpreter is only
> emitting puts("14930352") and not doing the actual work.
>

And that would be perfectly reasonable. We already know you have no
idea how to benchmark tools.

> Suppose someone is tasked with surveying dozens of machines to find out
> exactly what `if (n+1>n)` produces. Well, if they're using gcc, they
> might as well not bother, as they're not going to find out what /the
> machine/ produces, only what gcc has decided it should produce.

They would manage fine with gcc - /if/ they understand the language and
how to test compilers. You, apparently, do not, and are flummoxed by
the task.

>
> Presumably your point was to demonstrate something about the
> unpredictability of UB, but your chosen compiler had already made up its
> mind in advance that it was going to do X no matter what!
>
> This is what you said:
>
> >(This applies only to the quick experiment I just did, and could vary
> with the phase of the moon.)
>
> I doubt anything would make gcc do anything different!

Different code could give different results. Different versions of gcc
could give different results. Different flags could give different
results. It's undefined behaviour - only a fool would expect some
particular consistent choice of output. /That/ is the point. It would
be nice if you tried harder to understand.

>
> But if you still can't see my objection, then forget it.
>
>
> > Or are you just trying to make this look worse and more complicated than
> > it really is?
>
> I consider inconsistency in comparing the same two values to be poor.

As always - you are allowed to have an opinion on whether you like or
dislike the way C specifies this kind of thing. You are not allowed an
opinion on /how/ it specifies it - only on whether or not you like it or
approve of it. Understand the facts first - then form an opinion.

Oh, and note that it is not the comparison that is UB - comparison of
two int expressions is fully defined in C. It is the overflow on the
addition (INTMAX + 1) that is UB.

> That is, comparing INT_MIN with INT_MAX. Because if you do this:
>
>     int b = INT_MAX;
>     int a = b+1;       // yields INT_MIN even with gcc

It /might/ yield INT_MIN. It might not. It might crash the program
when it runs (try compiling with -fsantize=undefined). It might
complain at compile time. (gcc will do that if you mark "b" as "const".
I think it is weak that it does not do so for non-const "b", but
compilers can't warn about all bad code.) It is undefined behaviour -
maybe it will do what /you/ want it to do, but maybe not.

And it can certainly get in a self-contradictory state - it is /fine/
for the compiler to store one thing in "a" (if it bothers doing that at
all) while also tracking known facts about "a" for use in later
optimisations - such as a comparison. The compiler tracks range and
value facts all the time, allowing all kinds of optimisations. If you
give it code that gives the compiler contradictory information, you can
expect the possibility of contradictory results. Lying to your compiler
is not a good idea - it always ends in tears.

>
>     if (a>b) {
>
> that will get a different results compared with 'if (b+1, b)`. Is that
> supposed to be good?

It's garbage in, garbage out. Charles Babbage had this figured out - it
really should not come as a surprise to you.

Despite having written several compilers of your own, I really don't
think you understand how they work. A compiler is not a dumb translator
that works line by line. It analyses the code and forms internal graphs
tracking information and decisions. It re-arranges things to minimise
dependencies, re-use calculations, pre-calculate what it can, eliminate
redundant code, merge loads, stores and calculations, etc. The
statement "if (a > b) {" can therefore be transformed to "if (b + 1 >
b)" and then "if (true)", regardless of any writes to "a" which may or
may not take place, and which may be moved forwards or backwards in the
code.

And yes, this is /good/. It lets people write their code in whatever
makes the most sense when writing it - they can write clear and
maintainable source code, without getting bogged down in
micro-optimisations and concerns about the details of the code
generation. Human programmers can do what they do best, and let the
compiler do what it does best.

It is only a problem if there is a programmer who disregards the rules
of the language (and you certainly can't claim you don't know these
particular rules - if you break them, it is by intention). Compilers
can provide tools to help programmers spot accidental mistakes (and they
can always get better at this), but they can't force you to write proper
code.

>
> Comparing values at the limits of a type's bounds is always going to be
> dodgy anyway, but at least you might expect the results to be always the
> same.

On 21/07/2023 12:44, Malcolm McLean wrote:
> On Friday, 21 July 2023 at 11:21:32 UTC+1, Bart wrote:
>>
>> Note that if you do this test using unsigned and UINT_MAX, gcc also
>> hardcodes the result, even this in this case it knows that b+1 could
>> wrap around to zero. The result showed will be wrong, but so is mine. At
>> least it is consistent with the signed version!
>>
> Did you write
> unsigned int x = UINT_MAX;
> if(x + 1 > x)
>
> or
>
> if(x + 1u > x)
>
> ?
>
> C has some weird rules about expressions going to an int which date back to
> the days of implict int.
> I don't have a Linux machine handy so I can't test gcc.

The rules are very clear here. They are laid out in 6.3.1.1 of the C
standards. You can read them here, if you don't like reading the
standards: <https://en.cppreference.com/w/c/language/conversion>

If you add an unsigned int to an int, the int is first converted to an
unsigned int (by modulo wrapping if it is negative), then the operation
is carried out as an unsigned int addition, resulting in an unsigned int.

Thus "UINT_MAX + 1" and "UINT_MAX + 1u" are both handled as unsigned int
addition, with guaranteed wrapping semantics, and operate identically.
(UINT_MAX is guaranteed to be of "unsigned int" type.)

piątek, 21 lipca 2023 o 09:33:04 UTC+2 Bonita Montero napisał(a):
> Am 21.07.2023 um 08:06 schrieb Blue-Maned_Hawk:
>
> > ​What evidence have you that they would save work? On the contrary,
> > i'd say that the insane complexity of C++ and the hostile culture
> > surrounding Rust both would interfere with getting work done.
> If you're know C++ halfway you're multiple times faster than
> with C, where you have to deal with every details yourself.

that is what you belive... but i think you dont know c in c you dont need
to deal with every detail ..yopu only have to deal with detail onde, write your own
small specialised library and tehn not deal with detail anymore and
you have your own small library which suits you better than some other
libraries wjose have some weird things and you need to learn them
often much longer than writing yours
(eventually you dont need to write yours you may take some from others..
in thsi case you may also hit better than learning c++ std libraries which are kinda shame
imo (long timno didnt seen them though) yet you simply get better language
than pony++)

> There is no more rudimentary language than C in that sense.
> I'm developing C++ since 1992 and maybe I've missed some useful
> features, but it's easy to learn additional features by the way.