piątek, 21 lipca 2023 o 15:06:49 UTC+2 fir napisał(a):
> 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.

note well one thing:

1) i dont state it to fight a war on c vs c++ (liek you would be c++ pony and im c pony then - no

2) i state it becouse on usenet is good ancest tradition to deny misinformation or at least doubtfull statements which many reasoneble people dont share..(and if thso satements are not shown and kinda proved)

you come and copy and pase your belifs on pony++ just like maniacal religious evengelist
(which makes you a troll like rick hodgin on jesus) and people are to weary to deny thsi doubtfull statements becouse they are pasted in a forms of tens if not thousands

and in fact nothink can be done if you do it as spam but sometimes it is not bad to revert to tradition and warn people

On 21/07/2023 14:05, David Brown wrote:
> 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>

The rules appear to be these:

u8 u16 u32 u64 i8 i16 i32 i64

u8 S S u u S S S S
u16 S S u u S S S S
u32 u u u u u u u S
u64 u u u u u u u u

i8 S S u u S S S S
i16 S S u u S S S S
i32 S S u u S S S S
i64 S S S u S S S S

This shows whether the result of a binary op between two int values is
signed or unsigned (S or u). The size will be 32 bits unless either one
is 64 bits then it will be 64.

I wouldn't call those rules clear. This program was generated by the C
program below. If I write a similar program for my language, it produces
this chart:

u8 u16 u32 u64 i8 i16 i32 i64

u8 S S S S S S S S
u16 S S S S S S S S
u32 S S S S S S S S
u64 S S S u S S S S

i8 S S S S S S S S
i16 S S S S S S S S
i32 S S S S S S S S
i64 S S S S S S S S

I would say that the rules here are simpler (note all calculations are
done at 64 bits; C uses either 32 or 64 bits).

-------------------------------

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

#define issigned(x) _Generic((x),\
int8_t: "S",\
int16_t: "S",\
int32_t: "S",\
int64_t: "S",\
uint8_t: "u",\
uint16_t: "u",\
uint32_t: "u",\
uint64_t: "u",\
default: "other")

int main(void) {
uint8_t xu8;
uint16_t xu16;
uint32_t xu32;
uint64_t xu64;

int8_t xi8;
int16_t xi16;
int32_t xi32;
int64_t xi64;

uint8_t yu8;
uint16_t yu16;
uint32_t yu32;
uint64_t yu64;

int8_t yi8;
int16_t yi16;
int32_t yi32;
int64_t yi64;

puts(" u8 u16 u32 u64 i8 i16 i32 i64\n");

printf(" u8");
printf("%4s",issigned(xu8*yu8));
printf("%4s",issigned(xu8*yu16));
printf("%4s",issigned(xu8*yu32));
printf("%4s",issigned(xu8*yu64));
printf(" %4s",issigned(xu8*yi8));
printf("%4s",issigned(xu8*yi16));
printf("%4s",issigned(xu8*yi32));
printf("%4s\n",issigned(xu8*yi64));

printf(" u16");
printf("%4s",issigned(xu16*yu8));
printf("%4s",issigned(xu16*yu16));
printf("%4s",issigned(xu16*yu32));
printf("%4s",issigned(xu16*yu64));
printf(" %4s",issigned(xu16*yi8));
printf("%4s",issigned(xu16*yi16));
printf("%4s",issigned(xu16*yi32));
printf("%4s\n",issigned(xu16*yi64));

printf(" u32");
printf("%4s",issigned(xu32*yu8));
printf("%4s",issigned(xu32*yu16));
printf("%4s",issigned(xu32*yu32));
printf("%4s",issigned(xu32*yu64));
printf(" %4s",issigned(xu32*yi8));
printf("%4s",issigned(xu32*yi16));
printf("%4s",issigned(xu32*yi32));
printf("%4s\n",issigned(xu32*yi64));

printf(" u64");
printf("%4s",issigned(xu64*yu8));
printf("%4s",issigned(xu64*yu16));
printf("%4s",issigned(xu64*yu32));
printf("%4s",issigned(xu64*yu64));
printf(" %4s",issigned(xu64*yi8));
printf("%4s",issigned(xu64*yi16));
printf("%4s",issigned(xu64*yi32));
printf("%4s\n\n",issigned(xu64*yi64));

printf(" i8");
printf("%4s",issigned(xi8*yu8));
printf("%4s",issigned(xi8*yu16));
printf("%4s",issigned(xi8*yu32));
printf("%4s",issigned(xi8*yu64));
printf(" %4s",issigned(xi8*yi8));
printf("%4s",issigned(xi8*yi16));
printf("%4s",issigned(xi8*yi32));
printf("%4s\n",issigned(xi8*yi64));

printf(" i16");
printf("%4s",issigned(xi16*yu8));
printf("%4s",issigned(xi16*yu16));
printf("%4s",issigned(xi16*yu32));
printf("%4s",issigned(xi16*yu64));
printf(" %4s",issigned(xi16*yi8));
printf("%4s",issigned(xi16*yi16));
printf("%4s",issigned(xi16*yi32));
printf("%4s\n",issigned(xi16*yi64));

printf(" i32");
printf("%4s",issigned(xi32*yu8));
printf("%4s",issigned(xi32*yu16));
printf("%4s",issigned(xi32*yu32));
printf("%4s",issigned(xi32*yu64));
printf(" %4s",issigned(xi32*yi8));
printf("%4s",issigned(xi32*yi16));
printf("%4s",issigned(xi32*yi32));
printf("%4s\n",issigned(xi32*yi64));

printf(" i64");
printf("%4s",issigned(xi64*yu8));
printf("%4s",issigned(xi64*yu16));
printf("%4s",issigned(xi64*yu32));
printf("%4s",issigned(xi64*yu64));
printf(" %4s",issigned(xi64*yi8));
printf("%4s",issigned(xi64*yi16));
printf("%4s",issigned(xi64*yi32));
printf("%4s\n",issigned(xi64*yi64));
}

On 21/07/2023 15:42, Bart wrote:
>
> On 21/07/2023 14:05, David Brown wrote:
> > 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>
>
> The rules appear to be these:
>
>        u8  u16 u32 u64  i8  i16 i32 i64
>
>    u8   S   S   u   u    S   S   S   S
>   u16   S   S   u   u    S   S   S   S
>   u32   u   u   u   u    u   u   u   S
>   u64   u   u   u   u    u   u   u   u
>
>    i8   S   S   u   u    S   S   S   S
>   i16   S   S   u   u    S   S   S   S
>   i32   S   S   u   u    S   S   S   S
>   i64   S   S   S   u    S   S   S   S

Why would you make up something like that, when there are already
specific rules, using C's terminology and types? Anything smaller than
"int" is promoted to "int". If the two types have the same signedness,
then the smaller type is converted to the larger. If they have
different signedness, and the signed type is larger, the smaller type is
converted to the larger. If the unsigned type is the same or larger,
they are both converted to the unsigned type.

As a summary suitable for pretty much any real system, you can say that
the values are all preserved unchanged except when you have a mix of
signed and unsigned types (at least as big as int), and the signed type
is not bigger. Then the signed value is converted to the unsigned type.
It's not hard to remember.

You might not agree on the choices there (I don't - I'd rather that any
conversion that changes a value would be a constraint error and
disallowed by the language. Converting mixes to the signed type, or to
a bigger signed type, would also be wrong). But they are simple enough.

>
> This shows whether the result of a binary op between two int values is
> signed or unsigned (S or u). The size will be 32 bits unless either one
> is 64 bits then it will be 64.

Here in comp.lang.c - emphasis on the /C/ - it makes more sense to use
the /C/ types. "int" is not restricted to 32-bit. And if you must use
fixed-size types, which are inappropriate here, use the C fixed size
types - int32_t, etc. Using your own private abbreviations is not
helpful even though we all know what you mean. It just gives the
impression that you don't really understand C, and are not interested in
learning it or discussing it, leaving people to wonder why you are here.
(To be clear, I am glad that you /are/ in this group, and we've had
many interesting discussions, but going out of your way to use
non-standard terms or types does not help anyone.)

>
> I wouldn't call those rules clear.

No, what you mean is you don't /like/ these rules. I simply don't
believe that you find them unclear.

Any choice of rules - including yours - will get things wrong when
signednesses are mixed. It is obviously impossible to combine two types
with ranges that are not a subset of each other, unless you first expand
to a type that covers both ranges. And it is obviously impossible to do
that with a fixed maximum size for the types.

So languages have three ways to handle combining types that are not
subsets (such as int and unsigned int) :

1. The language can have no fixed limit on the size of integers, and
thus handle the both values correctly (Python does this). The cost is
in the efficiency.

2. The language can pick rules that dictate a common type in the case of
conflicting signedness. C does this. Your language does this. The
cost is that in some cases, for some values, the result does not match
the mathematical expectation (i.e., what you would get with unlimited
integers).

3. The language can disallow operations that cannot guarantee
mathematical correctness, and treat such mixes as errors. The cost is
inconvenience in the code when the programmer knows the real range of
the values can be combined safely.

Your language picks 2. It is no better and no worse than C - it gets
things wrong, just different things. Your sense of superiority is
illusionary.

I prefer solution 3. I can get that to some extent, using gcc's
warnings, but not ideally. And when I use these warnings I have to live
with occasional extra inconvenience (such as casts between signed or
unsigned types).

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>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.
>

In 1983, I started working at Burroughs writing a new Master Control
Program to replace the 1966 version. We wrote in a mix of a high-level
modula-like language called SPRITE and a companion low-level assembler called
SPRASM.

SPRITE:

$TITLE "----- Show Language --------" 01577210
% --------------------------------------------------------- 01577220
% | | 01577230
show_language 01577240
% | | 01577250
% --------------------------------------------------------- 01577260
01577270
PROC( file VALUE FILE_ID, 01577280
family VALUE FAMILY ); 01577290
SHARES 01577300
CONST system_language; 01577310
01577320
VAR 01577324
lang LANGUAGE_TABLE_PTR, 01577326
msg STRING (72) OF EBCDIC; 01577328
01577332
% ===== Show Language ==== 01577336
01577340
msg := "Language: xxxxxxxxxxxxxxxxx"; 01577344
msg[11::17] := lang @.name; 01577348
kbout.string_out( msg ); 01577352
01577356
DO 01577360
msg := fill_string( " " ); 01577364
kbout.string_out( msg ); 01577368
01577372
msg := "File: ffffff Family: "; 01577376
msg[11::17] := lang @.title; 01577380
msg[44::17] := lang @.family; 01577384
kbout.string_out( msg ); 01577388
01577392
msg := "Words: eeeeee/ma:size Phrases: "; 01577396
msg[11::6] := translate( lang @.word_cd[1::6], h_to_a ); 01577400
msg[18::2] := translate( lang @.word_cd[7::2], h_to_a ); 01577406
msg[21::5] := edit_number( lang @.word_size, "-ZZZ9" ); 01577412
msg[44::6] := translate( lang @.phrase_cd[1::6], h_to_a ); 01577418
msg[51::2] := translate( lang @.phrase_cd[7::2], h_to_a ); 01577424
msg[54::5] := edit_number( lang @.phrase_size, "-ZZZ9" ); 01577430
kbout_mod.string_out( msg ); 01577436
01577442
msg := "Map: eeeeee/ma:size"; 01577448
msg[11::6] := translate( lang @.map_cd[1::6], h_to_a ); 01577454
msg[18::2] := translate( lang @.map_cd[7::2], h_to_a ); 01577460
msg[21::5] := edit_number( lang @.map_size, "-ZZZ9" ); 01577466
kbout_mod.string_out( msg ); 01577472
...

CONST 09610000
words ARRAY [WORD_NAMES] OF WORD_ENTRY = 09611000
[ 09612000
[ "BUFSIZE ", wd_bufsize ],09613000
[ "FAMILY ", wd_family ],09614000
[ "LANGUAGE ", wd_language ],09615000
[ "NUMBUFFERS", wd_numbuffers ] 09616000
]; 09617000
VAR 09618000
bufsize INT10, %% Size, in bytes 09619000
key MESSAGE_KEY, %% Key for messages 09620000
lang LANGUAGE_NAME, %% New language name09621000
numbuffers INT4, %% buffers per file 09622000
olang LANGUAGE_NAME; %% Old language name09623000
09624000
% ===== alter system attributes ===== 09625000
09626000
global_mod.scan; 09627000
WHILE ^scan_result.no_more_input 09628000
DO 09629000
%% Ok, we must have an attribute name 09630000
IF (scan_result.type ^= alphanumeric) 09631000
| (scan_result.length > 10) 09632000
THEN 09633000
page_information.control_error_code := inv_syntax; 09634000
RETURN; 09635000
FI; 09636000
09637000
FIND thing 09638000
INTO words 09639000
WHERE thing@.word[1::scan_result.length] 09640000
= scan_result.word.pointer@[1::scan_result.length] 09641000
THEN 09642000
option := thing@.word_name; 09643000
ELSE 09644000
page_information.control_error_code := inv_option; 09645000
RETURN; 09646000
DNIF; 09647000
09648000
CASE option 09649000
IS wd_bufsize: 09650000
bufsize := get_numeric_parameter( 10 ); %% Get buffer size 09651000
IF page_information.control_error_code ^= 0 09652000
THEN 09653000
RETURN; 09654000
FI; 09655000
%% Here we should valid that bufsize is legal 09656000
OR wd_family: 09657000
get_parameter( FAMILY.SIZE/2, false ); %% Get family name 09658000
IF page_information.control_error_code ^= 0 09659000
THEN 09660000
RETURN; 09661000
FI; 09662000
family := scan_result.word.pointer@[1::scan_result.length]; 09663000
OR wd_language: 09664000
get_parameter( 17, false ); %% Get language name 09665000
IF page_information.control_error_code ^= 0 09666000
THEN 09667000
RETURN; 09668000
FI; 09669000
lang := scan_result.word.pointer@[1::scan_result.length]; 09670000
OR wd_numbuffers: 09671000
numbuffers := get_numeric_parameter( 4 ); 09672000
IF page_information.control_error_code ^= 0 09673000
THEN 09674000
RETURN; 09675000
FI; 09676000
%% Here we should validate the legality of numbuffers 09677000
ESAC; 09678000
09679000
global_mod.scan; %% Pick up end or comma 09680000
IF ^scan_result.no_more_input 09681000
THEN 09682000
IF (scan_result.type ^= special_char) 09683000
| (scan_result.word.pointer@[1::1] ^= ",") 09684000
THEN 09685000
page_information.control_error_code := inv_syntax; 09686000
RETURN; 09687000
FI; 09688000
global_mod.scan; 09689000
FI; 09690000
OD; 09691000
--------

On 21/07/2023 13:52, David Brown wrote:
> 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.

C requires reduction of constant-expressions for compile-time
expressions, and within conditional expressions of the preprocessor.

So the mechanism for doing that is already there; it is not optional.

Actually it is also required for ?:

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

The generated assembly depends entirely on the hardware.

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

I suspect Keith had not even bothered looking at the output, whether
running on a real machine, or even at the generated code.

Some of us are more practically minded.

(I think that of those discussing this here, I'm the only one who has
had to generate real code for real machines for real applications, from
source code like this. )

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

And that comment suggests *you* have no idea! Recursive Fibonacci is a
famous benchmark that involves very large numbers of function calls.
That allows you to compare how languages and implmentations cope.

One that always takes 0 seconds because it has completely elided the
user's code would be useless.

> Different code could give different results. Different versions of gcc
> could give different results. Different flags could give different
> results.

On the same hardware.

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

Apparently C23 has finally admitted that signed integers predominantly
use two's complement representation. But they have to keep overflow as
UB, *BECAUSE* of compilers like gcc which have invested so much into
exploiting it.

In my languages and compilers, signed integer overflow has never been
undefined. It's a choice.

There is still plenty of UB (to do with out-of-bounds accesses etc), but
I haven't catalogued it. Overflow however has never been UB because on
all my targets, it has been well-defined.

>> 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.
The probablity is near 100% that it will do so on x64 and likely most
other two's complement machines.

If you had to put money on what the output might be here:

int a=INT_MAX;
a=a+1;
printf("%d\n", a);

what would you go for? If the program was run again, would you make the
same choice, or would you genuinely think the result might be different?
I suspect I might win a lot of money from you!

Some of us are realists. However, even I would be hesitant of putting
that into a real program, but /because/ of the reputation of C compilers
regarding overflow.

BTW what is the purpose of gcc's -fwrapv option? Does it specify a
version of C where integer overflow is well-defined?

> It's garbage in, garbage out.

Unless -fwrapv suddenly makes it OK? How can one simple flag make sense
of 'garbage'?

> Despite having written several compilers of your own, I really don't
> think you understand how they work.

I know how mine works. It is not 'written' how compilers are supposed to
work. You're only familiar with gcc with its 1000s of options which can
make it work a million different ways.

So I can well make it a dumb line to line translator. It seems to work
well. There have been innumerable compilers before gcc and since that
work the same way, and they do the job.

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

You're describing an optimising compiler. If there is a place for a slow
language like Python, then there is also a place for a non-optimising
native code compiler, which is still a magnitude or two faster than Python.

When I was briefly using gcc 12.x, it took 500 times longer to optimise
my generated-C interpreter via -O3, as my language's compiler took to do
a non-optimised build.

However, the result wasn't 500 times faster, it was under 1.4 times as
fast (38%). But on that application, I normally use an accelerator, not
available using C, that makes it twice as fast as gcc-compiled code anyway.

So I think I'll stick with my compiler, thank you!

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

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

Well now I think I can!

6.3.2.1 p2:

"[...] If the lvalue designates an object of automatic storage
duration that could have been declared with the register storage class
(never had its address taken), and that object is uninitialized (not
declared with an initializer and no assignment to it has been
performed prior to use), the behavior is undefined."

Odd that seems to say that this:

int i, *ip = &i;
printf("%d\n", i);

is not undefined (or at least not undefined as a result is this
paragraph), but it's more than I'd spotted before.

So I now regret agreeing that

int *q = malloc(sizeof *q);
if (q) *q;

is undefined. I don't think it is anymore, despite the object having an
indeterminate representation.

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

Yes. Why does J.2 not refer to 6.3.2.1?

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

It's been there forever, although with different wording.

--
Ben.

On 21/07/2023 15:22, David Brown wrote:
> On 21/07/2023 15:42, Bart wrote:
>>
>> On 21/07/2023 14:05, David Brown wrote:
>> > 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>
>>
>> The rules appear to be these:
>>
>> u8 u16 u32 u64 i8 i16 i32 i64
>>
>> u8 S S u u S S S S
>> u16 S S u u S S S S
>> u32 u u u u u u u S
>> u64 u u u u u u u u
>>
>> i8 S S u u S S S S
>> i16 S S u u S S S S
>> i32 S S u u S S S S
>> i64 S S S u S S S S
>
> Why would you make up something like that, when there are already
> specific rules, using C's terminology and types? Anything smaller than
> "int" is promoted to "int". If the two types have the same signedness,
> then the smaller type is converted to the larger. If they have
> different signedness, and the signed type is larger, the smaller type is
> converted to the larger. If the unsigned type is the same or larger,
> they are both converted to the unsigned type.

And yet, the chart is irregular. You can change the order of the
quadrants, or the order of the types, but there will still be
irregularities.

My chart used to be different: the entire top left quadrant was 'u's.
Still simple, but I decided everything should be i64 as much as possible.

>
> As a summary suitable for pretty much any real system, you can say that
> the values are all preserved unchanged except when you have a mix of
> signed and unsigned types (at least as big as int), and the signed type
> is not bigger. Then the signed value is converted to the unsigned type.

There is another chart that shows the types and therefore their sizes. C
is hampered having a 2-step integer width: 32-bit and 64-bit (so did I,
between 64-bit and 128-bit, until I dropped 128 bits).

> It's not hard to remember.
>
> You might not agree on the choices there (I don't - I'd rather that any
> conversion that changes a value would be a constraint error and
> disallowed by the language. Converting mixes to the signed type, or to
> a bigger signed type, would also be wrong). But they are simple enough.

I don't like mixing unsigned and signed either, but like C that habit is
too ingrained. However, my choice of i64 can represent ALL other types
without losses, signed or unsigned, EXCEPT for u64 (this is why I made
the change).

> Here in comp.lang.c - emphasis on the /C/ - it makes more sense to use
> the /C/ types.

They wouldn't fit on my chart! i32 etc are not C type names, they are
handy colloquialisms that everyone understands (except Ben and Keith
possibly).

> "int" is not restricted to 32-bit. And if you must use
> fixed-size types, which are inappropriate here, use the C fixed size
> types - int32_t, etc. Using your own private abbreviations is not
> helpful even though we all know what you mean.

They are hardly private to me; where do you think I took them from? My
language uses both `word64` and `u64`, but on forums I use the latter. I
think both Rust and Zig use only those short-forms.

(I started using `u64` etc in generated C code to keep it short, then I
thought, why shouldn't it be part of my own syntax?)

> Any choice of rules - including yours - will get things wrong when
> signednesses are mixed. It is obviously impossible to combine two types
> with ranges that are not a subset of each other, unless you first expand
> to a type that covers both ranges. And it is obviously impossible to do
> that with a fixed maximum size for the types.

> So languages have three ways to handle combining types that are not
> subsets (such as int and unsigned int) :
>
> 1. The language can have no fixed limit on the size of integers, and
> thus handle the both values correctly (Python does this). The cost is
> in the efficiency.
>
> 2. The language can pick rules that dictate a common type in the case of
> conflicting signedness. C does this. Your language does this. The
> cost is that in some cases, for some values, the result does not match
> the mathematical expectation (i.e., what you would get with unlimited
> integers).
>
> 3. The language can disallow operations that cannot guarantee
> mathematical correctness, and treat such mixes as errors. The cost is
> inconvenience in the code when the programmer knows the real range of
> the values can be combined safely.
>
>
>
> Your language picks 2. It is no better and no worse than C - it gets
> things wrong, just different things. Your sense of superiority is
> illusionary.
>
> I prefer solution 3. I can get that to some extent, using gcc's
> warnings, but not ideally. And when I use these warnings I have to live
> with occasional extra inconvenience (such as casts between signed or
> unsigned types).

As stated above, my solution 2 uses i64 which can represent almost
everything.

But that that still leaves 3. Here, there are some combinations my
language disallows (because I got caught out in the past), for example:

u64 a := 0xC000'0000'0000'0000

if a > 0x7F00'0000'0000'0000 then

The 0x7F... literal has type i64, the comparison is done as i64, but
this gives the wrong result, as `a` ends up as a negative value.

So when used with literals there are special rules. (Or there should be;
this code passes; I'll have to find out why the check was turned off.)

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

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

I agree with your points, but as your last sentence demonstrates, the
result is still messy. Since the intent was to find something informal
that is better than the technically incorrect "compatible", I'd accept
the possibility of some confusion.

--
Ben.

On 21/07/2023 17:40, Bart wrote:
>
> On 21/07/2023 15:22, David Brown wrote:
> > On 21/07/2023 15:42, Bart wrote:
> >>
> >>  > 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>
> >>
> >
> > Why would you make up something like that, when there are already
> > specific rules, using C's terminology and types?  Anything smaller than
> > "int" is promoted to "int".  If the two types have the same signedness,
> > then the smaller type is converted to the larger.  If they have
> > different signedness, and the signed type is larger, the smaller type is
> > converted to the larger.  If the unsigned type is the same or larger,
> > they are both converted to the unsigned type.
>
> And yet, the chart is irregular. You can change the order of the
> quadrants, or the order of the types, but there will still be
> irregularities.
>

Your chart was also irregular.

> My chart used to be different: the entire top left quadrant was 'u's.
> Still simple, but I decided everything should be i64 as much as possible.
>

You can decide whatever you like for your language. But you /cannot/
make it correct. You simply have to decide what wrong arrangements you
think are least bad.

As I have said, I don't like C's position here. But I also don't like
yours. Both have the cases that I think are wrong. If a language uses
64-bit integers by default, then the risk of hitting an incorrect case
are minimal in practice, and I agree with you that converting to signed
rather than unsigned is less bad. So I would be happier with your
arrangement than C's (though I would be distinctly unhappy if the
language implementer changed things as you have done - known bad is
better than unknown bad). I would be happier still if it mixed
conversions were flagged as errors.

However, the point is that the rules for C - this being a C discussion
group - are clear and easy to learn. And if you don't like them, it's
easy to add conversions manually to get the effects you want.

>
> I don't like mixing unsigned and signed either, but like C that habit is
> too ingrained. However, my choice of i64 can represent ALL other types
> without losses, signed or unsigned, EXCEPT for u64 (this is why I made
> the change).

In your language, /you/ make the rules. Surely you can't be saying you
made your rules but you don't like them, because you have bad habits?

>
> > Here in comp.lang.c - emphasis on the /C/ - it makes more sense to use
> > the /C/ types.
>
> They wouldn't fit on my chart!

So drop the chart - it's not necessary, and it's not helpful.

> i32 etc are not C type names, they are
> handy colloquialisms that everyone understands (except Ben and Keith
> possibly).

We all understand them - we don't like them. They are utterly pointless
abbreviations. Please don't use them for C discussions. (Many of us
adapt the way we write code to suit the group, using noticeably
different styles from our normal coding practice - it's about
communicating with others in a common language. Do us the courtesy of
making the same effort.)

>
>
> > "int" is not restricted to 32-bit.  And if you must use
> > fixed-size types, which are inappropriate here, use the C fixed size
> > types - int32_t, etc.  Using your own private abbreviations is not
> > helpful even though we all know what you mean.
>
> They are hardly private to me; where do you think I took them from? My
> language uses both `word64` and `u64`, but on forums I use the latter. I
> think both Rust and Zig use only those short-forms.

This is /C/. Yes, they are private to /you/ when /you/ use them in
/your/ code. It doesn't matter how many other people use them in C, and
it certainly doesn't matter how many other people use them in different
languages. The types, macros, functions and other identifiers can be
divided into two categories here - standard C names, as defined in the C
standards, or private personal names that exist in the authors code. It
doesn't matter who wrote the code, or where it came from - you post it,
it's your code, and your private non-standard identifiers.

>
> (I started using `u64` etc in generated C code to keep it short, then I
> thought, why shouldn't it be part of my own syntax?)
>
> > Any choice of rules - including yours - will get things wrong when
> > signednesses are mixed.  It is obviously impossible to combine two types
> > with ranges that are not a subset of each other, unless you first expand
> > to a type that covers both ranges.  And it is obviously impossible to do
> > that with a fixed maximum size for the types.
>
> > So languages have three ways to handle combining types that are not
> > subsets (such as int and unsigned int) :
> >
> > 1. The language can have no fixed limit on the size of integers, and
> > thus handle the both values correctly (Python does this).  The cost is
> > in the efficiency.
> >
> > 2. The language can pick rules that dictate a common type in the case of
> > conflicting signedness.  C does this.  Your language does this.  The
> > cost is that in some cases, for some values, the result does not match
> > the mathematical expectation (i.e., what you would get with unlimited
> > integers).
> >
> > 3. The language can disallow operations that cannot guarantee
> > mathematical correctness, and treat such mixes as errors.  The cost is
> > inconvenience in the code when the programmer knows the real range of
> > the values can be combined safely.
> >
> >
> >
> > Your language picks 2.  It is no better and no worse than C - it gets
> > things wrong, just different things.  Your sense of superiority is
> > illusionary.
> >
> > I prefer solution 3.  I can get that to some extent, using gcc's
> > warnings, but not ideally.  And when I use these warnings I have to live
> > with occasional extra inconvenience (such as casts between signed or
> > unsigned types).
>
> As stated above, my solution 2 uses i64 which can represent almost
> everything.

That's fine, for your language. It's also C's solution. It's broken,
with different breakages that depend on the details of the implicit
conversions. But it can still be good enough for many purposes - most C
programmers are able to write code to C's rules, and I presume you can
write code to the rules of your language.

>
> But that that still leaves 3. Here, there are some combinations my
> language disallows (because I got caught out in the past), for example:
>
>     u64 a := 0xC000'0000'0000'0000
>
>     if a > 0x7F00'0000'0000'0000 then
>
> The 0x7F... literal has type i64, the comparison is done as i64, but
> this gives the wrong result, as `a` ends up as a negative value.
>

And that's why a "type 2" solution is inevitably broken for some cases.
And a rule that is not always correct, is broken.

> So when used with literals there are special rules. (Or there should be;
> this code passes; I'll have to find out why the check was turned off.)

Then what do you do if the values used are /not/ literals, but a "u64"
and an "i64" from elsewhere, but which happen to contain these values?
Still broken.

On 21/07/2023 17:56, David Brown wrote:
> On 21/07/2023 17:40, Bart wrote:
>> i32 etc are not C type names, they are handy colloquialisms that
>> everyone understands (except Ben and Keith possibly).
>
> We all understand them - we don't like them. They are utterly pointless
> abbreviations.

I post in other forums and nobody has any problem with them, no matter
what language is the topic. To repeat: they are not official C types.
`i32` is a convenient, lingua franca way of saying `signed 32-bit integer`.

Alternately I can write `unsigned long long int` in place of `u64`, I'm
sure that would make everyone happy.

Obviously I can't write `uint64_t` since that would only be meaningful
if `stdint.h` has been processed, something that cannot be determined in
an informal discussion in English.

>> But that that still leaves 3. Here, there are some combinations my
>> language disallows (because I got caught out in the past), for example:
>>
>> u64 a := 0xC000'0000'0000'0000
>>
>> if a > 0x7F00'0000'0000'0000 then
>>
>> The 0x7F... literal has type i64, the comparison is done as i64, but
>> this gives the wrong result, as `a` ends up as a negative value.
>>
>
> And that's why a "type 2" solution is inevitably broken for some cases.
> And a rule that is not always correct, is broken.
>
>> So when used with literals there are special rules. (Or there should
>> be; this code passes; I'll have to find out why the check was turned
>> off.)
>
> Then what do you do if the values used are /not/ literals, but a "u64"
> and an "i64" from elsewhere, but which happen to contain these values?
> Still broken.

As I said, I'm not happy about it, yet I'm not ready to ban mixed
arithmetic completely.

I have however just tried banning mixed i64/u64 (that is, signed and
unsigned 64-bit integers) when used with relative comparisons (< <= >= >).

Surprisingly, half my programs still worked, as mixed arithmetic is
uncommon. The others needed some tweaks on a handful of instances of
comparing unsigned values to small constants.

So another thing I changed was for my bitfields, which are unsigned, to
be widened to i64 rather than u64, something that should have been done
anyway to match promotion rules elsewhere.

What's left is a whole bunch of operators that still allow i64/u64
arithmetic. Those can give rise to subtly unexpected behaviour. This
example is similar to the one above:

real x # (double)
u64 u := 0x7FFF'FFFF'FFFF'FFFF

x := u+1
println x

The result of u+1 is signed, so the value of x printed is:

-9223372036854775800.000000

Banning mixed '+' means not being able to do things like u+1. I think
something else I played with was for literals used in a binary operator
with unsigned, to assume a `u64` value as well.

You can see however, how it's not that hard to do this stuff, even with
existing codebases.

If you modified a codebase so that it has extra casts to suit a stricter
language/compiler, it will still work with an old compiler, with
probably fewer bugs (I found one today).

Bart <bc@freeuk.com> writes:
> 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?

My point was that the program's output when compiled by gcc is valid
because evaluating INT_MAX+1 has undefined behavior. Your point, as far
as I can tell, is that you don't like that. I agree: you don't like
that.

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

No, I posted a piece of code and reported the results I got on my own
system. I made no challenge. Of course anyone is free to try the code,
but showing more specific results wouldn't really prove anything.

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

Of course it doesn't "attempt to put the actual hardware to the test".
I never said it did, and it's completely beside the point.

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

Right, because it doesn't need to.

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

Are you saying that's a problem?

C programs do not specify CPU instructions. They specify behavior.

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

So they definitely shouldn't use my sample code, because that's not what
it was for.

[...]

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

Forget what?

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

Did I use the word "good" or "bad"? I'm not talking about personal
preferences. I'm discussing what the C standard requires.

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

Not if you understand how C is defined. (Which I think you actually do;
you just pretend not to understand it because you want to let us all
know you don't like it.)

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

If gcc behaved that way, it would be wrong. Here's a version of my
sample code modified to use unsigned int and UINT_MAX:

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

Its output (with every compiler I've tried at every optimization level) is

0 <= 4294967295

Any other output (perhaps with different values for UINT_MAX) would be
incorrect (a compiler bug is possible but unlikely).

If you got something like "0 > 4294967295", then I strongly suspect you
did something wrong.

--
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 21/07/2023 12:21, Bart wrote:
[...]
>> 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.)

I approve this message.

(With one very small quibble: the behavior of the program doesn't
*prove* anything about what gcc's maintainers believe. But I'm
confident that they understand C's rules, and the program's output
is a consequence of that understanding.)

[...]

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

Bart <bc@freeuk.com> writes:
> On 21/07/2023 13:52, David Brown wrote:
>> On 21/07/2023 12:21, Bart wrote:
>>> On 21/07/2023 02:28, Keith Thompson wrote:
[...]
>> 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,
>
> The generated assembly depends entirely on the hardware.
>
>> If you had looked up instead, you'd have seen Keith's point flying over
>> your head.
>
> I suspect Keith had not even bothered looking at the output, whether
> running on a real machine, or even at the generated code.

I certainly did look at the output before I posted it. I had to,
because I knew that the source code of my sample program does not
completely determine what the output will be.

No, I didn't look at the generated code, because it was irrelevant to my
point.

Again, C code specifies behavior, not CPU 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.
>>
>> And that would be perfectly reasonable. We already know you have no
>> idea how to benchmark tools.
>
> And that comment suggests *you* have no idea! Recursive Fibonacci is a
> famous benchmark that involves very large numbers of function calls.
> That allows you to compare how languages and implmentations cope.
>
> One that always takes 0 seconds because it has completely elided the
> user's code would be useless.

Not if it gives the correct result.

It doesn't matter that something is a poor benchmark if it wasn't
intended to be a benchmark. If a program produces the correct output by
transforming `printf("%d\n", fib(36));` to `puts("14930352")`, what's
the problem?

>> Different code could give different results. Different versions of gcc
>> could give different results. Different flags could give different
>> results.
>
> On the same hardware.

Yes.

>> 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.
>
> Apparently C23 has finally admitted that signed integers predominantly
> use two's complement representation. But they have to keep overflow as
> UB, *BECAUSE* of compilers like gcc which have invested so much into
> exploiting it.
>
> In my languages and compilers, signed integer overflow has never been
> undefined. It's a choice.

In C, signed integer overflow is undefined. You reject that choice.

[...]

> BTW what is the purpose of gcc's -fwrapv option? Does it specify a
> version of C where integer overflow is well-defined?

Yes.

Note that "gcc -fwrapv" is still conforming. Since integer overflow is
undefined, having it wrap consistently is one of the allowed behaviors.
The "-fwrapv" option simply tells gcc to make once particular choice out
of the many that are allowed by the standard.

>> It's garbage in, garbage out.
>
> Unless -fwrapv suddenly makes it OK? How can one simple flag make
> sense of 'garbage'?

That's its job. Seriously, what are you pretending not to understand?

[...]

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

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> David Brown <david.brown@hesbynett.no> writes:
[...]
>> I have to agree with you here. I really cannot see a convincing argument
>> for why using indeterminate values in local variables is UB.
>
> Well now I think I can!
>
> 6.3.2.1 p2:
>
> "[...] If the lvalue designates an object of automatic storage
> duration that could have been declared with the register storage class
> (never had its address taken), and that object is uninitialized (not
> declared with an initializer and no assignment to it has been
> performed prior to use), the behavior is undefined."

I addressed this over in comp.std.c.

[SNIP]

--
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 7/21/2023 1:24 AM, David Brown wrote:
> 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!).

I freaked out when my parents bought that Atari for me. They even got a
cassette drive.

Bart <bc@freeuk.com> writes:

[on mixed-type arithmetic]

> Banning mixed '+' means not being able to do things like u+1.

(where u is a variable with an unsigned type -- say unsigned int)

No, there are solutions for such cases. It would be possible to pick
the result type from those involved in the expression by allowing all
literal constants to be polymorphic. The rules, in a C-like language
would say that, since all the constant sub-expressions have values that
can be represented in the unsigned type, the result would be unsigned.

You would still have to ban

int i = 1; unsigned u = 42;
...
u + i

because type errors should be diagnosed at compile time.

--
Ben.

Bart <bc@freeuk.com> writes:
> On 21/07/2023 17:56, David Brown wrote:
>> On 21/07/2023 17:40, Bart wrote:
>>> i32 etc are not C type names, they are handy colloquialisms that
>>> everyone understands (except Ben and Keith possibly).
>>
>> We all understand them - we don't like them. They are utterly pointless
>> abbreviations.
>
> I post in other forums and nobody has any problem with them, no matter
> what language is the topic. To repeat: they are not official C types.
> `i32` is a convenient, lingua franca way of saying `signed 32-bit integer`.

Other forums aren't dedicated to the C language.

> Alternately I can write `unsigned long long int` in place of `u64`,
> I'm sure that would make everyone happy.

Why are you pretending not to know that unsigned long long is not
necessarily exactly 64 bits?

> Obviously I can't write `uint64_t` since that would only be meaningful
> if `stdint.h` has been processed, something that cannot be determined
> in an informal discussion in English.

You can't be serious.

You also tend to gloss over the fact that C treats integer types
narrower than int very differently. There are no arithmetic operations
on narrow integer types; they're promoted to int or unsigned int before
any operations are performed. int is not necessarily 32 bits. By
referring to i8, i16, i32, and i64, you make it difficult to discuss the
rules correctly. (I'm sure you dislike those rules. So do I. That's not
the point.)

[...]

--
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 22:34, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 21/07/2023 17:56, David Brown wrote:
>>> On 21/07/2023 17:40, Bart wrote:
>>>> i32 etc are not C type names, they are handy colloquialisms that
>>>> everyone understands (except Ben and Keith possibly).
>>>
>>> We all understand them - we don't like them. They are utterly pointless
>>> abbreviations.
>>
>> I post in other forums and nobody has any problem with them, no matter
>> what language is the topic. To repeat: they are not official C types.
>> `i32` is a convenient, lingua franca way of saying `signed 32-bit integer`.
>
> Other forums aren't dedicated to the C language.

Whatever the language and whatever its actual denotations, everyone
understands what I mean by i32 or sometimes int32. There are fewer
pedantics than in this forum.

>> Alternately I can write `unsigned long long int` in place of `u64`,
>> I'm sure that would make everyone happy.
>
> Why are you pretending not to know that unsigned long long is not
> necessarily exactly 64 bits?

Is uint64_t guaranteed to be exactly 64 bits? Even on non-64-bit hardware?

>
>> Obviously I can't write `uint64_t` since that would only be meaningful
>> if `stdint.h` has been processed, something that cannot be determined
>> in an informal discussion in English.
>
> You can't be serious.

Dead serious:

uint64_t abc;

gcc says:

error: unknown type name 'uint64_t'

Pedantic, yes, but so are you lot being. But if a typedef for uint64_t
can be assumed, why not one for u64?

Bart <bc@freeuk.com> writes:
> On 21/07/2023 22:34, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
[...]
>>> Alternately I can write `unsigned long long int` in place of `u64`,
>>> I'm sure that would make everyone happy.
>> Why are you pretending not to know that unsigned long long is not
>> necessarily exactly 64 bits?
>
> Is uint64_t guaranteed to be exactly 64 bits? Even on non-64-bit hardware?

Either it's exactly 64 bits with no padding bits, or the implementation
doesn't define it. Did you not really not know that?

[...]

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

On Friday, 21 July 2023 at 23:03:15 UTC+1, Bart wrote:
> On 21/07/2023 22:34, Keith Thompson wrote:
> > Bart <b...@freeuk.com> writes:
> >> On 21/07/2023 17:56, David Brown wrote:
> >>> On 21/07/2023 17:40, Bart wrote:
> >>>> i32 etc are not C type names, they are handy colloquialisms that
> >>>> everyone understands (except Ben and Keith possibly).
> >>>
> >>> We all understand them - we don't like them. They are utterly pointless
> >>> abbreviations.
> >>
> >> I post in other forums and nobody has any problem with them, no matter
> >> what language is the topic. To repeat: they are not official C types.
> >> `i32` is a convenient, lingua franca way of saying `signed 32-bit integer`.
> >
> > Other forums aren't dedicated to the C language.
> Whatever the language and whatever its actual denotations, everyone
> understands what I mean by i32 or sometimes int32. There are fewer
> pedantics than in this forum.
> >> Alternately I can write `unsigned long long int` in place of `u64`,
> >> I'm sure that would make everyone happy.
> >
> > Why are you pretending not to know that unsigned long long is not
> > necessarily exactly 64 bits?
> Is uint64_t guaranteed to be exactly 64 bits? Even on non-64-bit hardware?
> >
> >> Obviously I can't write `uint64_t` since that would only be meaningful
> >> if `stdint.h` has been processed, something that cannot be determined
> >> in an informal discussion in English.
> >
> > You can't be serious.
> Dead serious:
>
> uint64_t abc;
>
> gcc says:
>
> error: unknown type name 'uint64_t'
>
> Pedantic, yes, but so are you lot being. But if a typedef for uint64_t
> can be assumed, why not one for u64?
>
This was a nuisance. Some implementations had stdint.h, others did not,
and so you had to use conditional defines to get the types. It was tempting
to roll your own.
Also, the situations where you genuinely need a type of known width are
rare. In Baby X BBX_RGBA ought to be a 32 bit unsigned value, but that's the
only place in a large codebase that it matters. And if fact if you restrict yourself
to the BabyX interfaces it won't break if BBX_RGBA is wider.
However a lot of programmers don't understand this and use fixed width types
where they want a type to use an index value. So the quality of code deteriorates
when stdint.h is available.

However nowadays it's rare to come across a compiler that doesn't have stdint.h.
Whilst the names are ugly, it's better to have standard names than to define your
own. Otherwise you get a mess as every third party defines their own fixed width
types.

On 7/21/23 03:32, Bonita Montero wrote:
> <snip />
>
> If you're know C++ halfway you're multiple times faster than
> with C, where you have to deal with every details yourself.
Okay, where's your evidence for that?
--
⚗︎ | /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 22/07/2023 05:49, Malcolm McLean wrote:
> On Friday, 21 July 2023 at 23:03:15 UTC+1, Bart wrote:
>> On 21/07/2023 22:34, Keith Thompson wrote:
>>> Bart <b...@freeuk.com> writes:
>>>> On 21/07/2023 17:56, David Brown wrote:
>>>>> On 21/07/2023 17:40, Bart wrote:
>>>>>> i32 etc are not C type names, they are handy colloquialisms that
>>>>>> everyone understands (except Ben and Keith possibly).
>>>>>
>>>>> We all understand them - we don't like them. They are utterly
pointless
>>>>> abbreviations.
>>>>
>>>> I post in other forums and nobody has any problem with them, no matter
>>>> what language is the topic. To repeat: they are not official C types.
>>>> `i32` is a convenient, lingua franca way of saying `signed 32-bit
integer`.
>>>
>>> Other forums aren't dedicated to the C language.
>> Whatever the language and whatever its actual denotations, everyone
>> understands what I mean by i32 or sometimes int32. There are fewer
>> pedantics than in this forum.
>>>> Alternately I can write `unsigned long long int` in place of `u64`,
>>>> I'm sure that would make everyone happy.
>>>
>>> Why are you pretending not to know that unsigned long long is not
>>> necessarily exactly 64 bits?
>> Is uint64_t guaranteed to be exactly 64 bits? Even on non-64-bit
hardware?
>>>
>>>> Obviously I can't write `uint64_t` since that would only be meaningful
>>>> if `stdint.h` has been processed, something that cannot be determined
>>>> in an informal discussion in English.
>>>
>>> You can't be serious.
>> Dead serious:
>>
>> uint64_t abc;
>>
>> gcc says:
>>
>> error: unknown type name 'uint64_t'
>>
>> Pedantic, yes, but so are you lot being. But if a typedef for uint64_t
>> can be assumed, why not one for u64?
>>

> This was a nuisance. Some implementations had stdint.h, others did not,
> and so you had to use conditional defines to get the types. It was
tempting
> to roll your own.
> Also, the situations where you genuinely need a type of known width are
> rare.

So the choice is to use...? In my languages `int` is 64 bits, which can
represent pretty much everything.

In C, it is 32 bits, which is much more limiting. But the next size up
is not obvious: `long long int`? Too long! `long`? It might be only 32
bits still. `int64_t`? But that is now the fixed size type you wanted to
avoid!

> In Baby X BBX_RGBA ought to be a 32 bit unsigned value, but that's the
> only place in a large codebase that it matters. And if fact if you
restrict yourself
> to the BabyX interfaces it won't break if BBX_RGBA is wider.
> However a lot of programmers don't understand this and use fixed
width types
> where they want a type to use an index value. So the quality of code
deteriorates
> when stdint.h is available.

What type should be used for an index then, int? Unsigned int? Since
array indices are usually positive.

`int` apparently could conceivably be only 16 bits. `long` could be 32
bits or it might be 64. 'unsigned int` is too much to type, and would
mean too many interactions between signed and unsigned values (you get
that in Rust where indices must have `usize` type, and there you don't
have automatic conversions).

> However nowadays it's rare to come across a compiler that doesn't
have stdint.h.
> Whilst the names are ugly, it's better to have standard names than to
define your
> own. Otherwise you get a mess as every third party defines their own
fixed width
> types.

Many programs and libraries still define their own types, sometimes on
top of stdint.h. So you still get that mess.

And where they don't, you have source which is such a sea of `uint64_t`
that you can hardly make out the real code:

int32_t fn(int64_t a, int64_t b, int64_t c);

Compare with:

i32 fn(i64 a, i64 b, i64 c);

or even, if you could do this in C (you can't):

i32 fn(i64 a, b, c);

Here you can easily see, even in black and white, that there are three
parameters a, b, c which all share the same type. To me, C syntax makes
things needlessly elaborate.

On Saturday, 22 July 2023 at 11:41:17 UTC+1, Bart wrote:
> On 22/07/2023 05:49, Malcolm McLean wrote:
> > On Friday, 21 July 2023 at 23:03:15 UTC+1, Bart wrote:
> >> On 21/07/2023 22:34, Keith Thompson wrote:
> >>> Bart <b...@freeuk.com> writes:
> >>>> On 21/07/2023 17:56, David Brown wrote:
> >>>>> On 21/07/2023 17:40, Bart wrote:
> >>>>>> i32 etc are not C type names, they are handy colloquialisms that
> >>>>>> everyone understands (except Ben and Keith possibly).
> >>>>>
> >>>>> We all understand them - we don't like them. They are utterly
> pointless
> >>>>> abbreviations.
> >>>>
> >>>> I post in other forums and nobody has any problem with them, no matter
> >>>> what language is the topic. To repeat: they are not official C types.
> >>>> `i32` is a convenient, lingua franca way of saying `signed 32-bit
> integer`.
> >>>
> >>> Other forums aren't dedicated to the C language.
> >> Whatever the language and whatever its actual denotations, everyone
> >> understands what I mean by i32 or sometimes int32. There are fewer
> >> pedantics than in this forum.
> >>>> Alternately I can write `unsigned long long int` in place of `u64`,
> >>>> I'm sure that would make everyone happy.
> >>>
> >>> Why are you pretending not to know that unsigned long long is not
> >>> necessarily exactly 64 bits?
> >> Is uint64_t guaranteed to be exactly 64 bits? Even on non-64-bit
> hardware?
> >>>
> >>>> Obviously I can't write `uint64_t` since that would only be meaningful
> >>>> if `stdint.h` has been processed, something that cannot be determined
> >>>> in an informal discussion in English.
> >>>
> >>> You can't be serious.
> >> Dead serious:
> >>
> >> uint64_t abc;
> >>
> >> gcc says:
> >>
> >> error: unknown type name 'uint64_t'
> >>
> >> Pedantic, yes, but so are you lot being. But if a typedef for uint64_t
> >> can be assumed, why not one for u64?
> >>
>
> > This was a nuisance. Some implementations had stdint.h, others did not,
> > and so you had to use conditional defines to get the types. It was
> tempting
> > to roll your own.
> > Also, the situations where you genuinely need a type of known width are
> > rare.
> So the choice is to use...? In my languages `int` is 64 bits, which can
> represent pretty much everything.
>
> In C, it is 32 bits, which is much more limiting. But the next size up
> is not obvious: `long long int`? Too long! `long`? It might be only 32
> bits still. `int64_t`? But that is now the fixed size type you wanted to
> avoid!
>
Most computer programs ultimately deal with things inthe real world. And
most counts of things can't go very high. If yiu need more than 2 billion
objects in the program, it's worth handling that specially.
>
> > In Baby X BBX_RGBA ought to be a 32 bit unsigned value, but that's the
> > only place in a large codebase that it matters. And if fact if you
> restrict yourself
> > to the BabyX interfaces it won't break if BBX_RGBA is wider.
> > However a lot of programmers don't understand this and use fixed
> width types
> > where they want a type to use an index value. So the quality of code
> deteriorates
> > when stdint.h is available.
> What type should be used for an index then, int? Unsigned int? Since
> array indices are usually positive.
>
The official type is size_t.
size_t is the width of the address bus, and so can index anything.
But there are problems with it. As I said, most counts of things can't go
very high. But size_t has to be 64 bits on a amchine with more than 4 GB
of address space. So you've got a potential performance issue. You're
gobbling twice as much cache as you need, even if 64 bit operations are
as fast as 32 bit operations. And the choice of an unsigned type is undesirable
because intermediate array index calculations can go negative (e.g. you are
applying a filter to an array). And the name size_t is very unintuitive for a
variable used as an index.
So generally you want int. But you can be caught out if datasets go much larger
than you were expecting.
>
> `int` apparently could conceivably be only 16 bits. `long` could be 32
> bits or it might be 64. 'unsigned int` is too much to type, and would
> mean too many interactions between signed and unsigned values (you get
> that in Rust where indices must have `usize` type, and there you don't
> have automatic conversions).
>
int could be 16 bits. But then you probably have only 64k of memory. You
are unlikely to need to process over 30,000 objects on a small machine with
only 16 bit registers.

> > However nowadays it's rare to come across a compiler that doesn't
> have stdint.h.
> > Whilst the names are ugly, it's better to have standard names than to
> define your
> > own. Otherwise you get a mess as every third party defines their own
> fixed width
> > types.
> Many programs and libraries still define their own types, sometimes on
> top of stdint.h. So you still get that mess.
>
That totally defeats the purpose. That doesn't mean that some people won't
do it, of course.
>
> And where they don't, you have source which is such a sea of `uint64_t`
> that you can hardly make out the real code:
>
> int32_t fn(int64_t a, int64_t b, int64_t c);
>
> Compare with:
>
> i32 fn(i64 a, i64 b, i64 c);
>
> or even, if you could do this in C (you can't):
>
> i32 fn(i64 a, b, c);
>
> Here you can easily see, even in black and white, that there are three
> parameters a, b, c which all share the same type. To me, C syntax makes
> things needlessly elaborate.
>
It's best to make things obvious to someone who knows a bit about programming
but isn't necessarily very familiar with C.

int fn(int a, int b, int c)

is pretty obviously a function which takes three integers and returns an integer
and if you don't know C you can easily guess that. Difficulties mount when you
get away from the core language.

Am 21.07.2023 um 15:06 schrieb fir:

> that is what you belive... but i think you dont know c ...

I've been programming C when I guess that you didn't exist.

> in c you dont need to deal with every detail ..

Of course you neeed. You'd have to do anything manually the
STL does or you. People don't use anything comparable in C
since C doesn't has the features to be as covenient with
that like with C++. Real OOP, RAII and exceptions make the
life much easier.

Am 22.07.2023 um 07:30 schrieb Blue-Maned_Hawk:
> On 7/21/23 03:32, Bonita Montero wrote:
>> <snip />
>>
>> If you're know C++ halfway you're multiple times faster than
>> with C, where you have to deal with every details yourself.
>
> Okay, where's your evidence for that?

Show me the C-code for that:

vector<string> vs;

void fn( char const *str )
{ vs.emplace_back( str );
}

Thats just an example how convenient the STL is. Imagine what effort
you need to do the exponential growth of the vector yoursel. And you
don't need to deal with the errors of emplace_back where they happen,
but just catch bad_alloc some call levels above.
C++ is full of such convenient features which make a lot of work in C.