David Brown <david.brown@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?

Sorry, but my comprehension is a bit slow today.

br,
KK

In article <u8rm2a$1pha$1@dont-email.me>,
Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
>Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> - such as Keith Thompson, who is so fabulously insane, that
>> I always enjoy reading his stuff.
>
>During all these years I have never seen a single
>sign of Keith Thompson's "insanity". On the contrary,
>his posts are always informative and helpful.

You do you. As long as he stays entertaining, that's all that really matters.

--
He must be a Muslim. He's got three wives and he doesn't drink.

On 2023-07-14, Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
> Bart <bc@freeuk.com> wrote:
>> On 13/07/2023 21:30, Kalevi Kolttonen wrote:
>> So the answer is to do constant battle with the Rust Borrow Checker?
>
> I make no recommendations. I just observed the fact that
> in order to write safe C code, you need considerable amount
> of knowledge about the C standards in order to avoid the
> pitfalls.

The vast majority of it is common sense, like don't try to calculate
out-of-range numbers, or fit out of range numbers into a smaller type.

What's hard in C is writing a large body of code in which you don't make
any accidental mistakes which are obvious if pointed out by someone else
(rather than something you don't know).

Then there is the difficulty of all that manual memory management, and
also explicit concurrency, if you're required to use those.)

Separately from that, what is hard is defending against external inputs,
where it is obvious that there are combinatiosn of inputs that will
cause the program's operations to violate the rules.

For instance, it's quite clumsy to check something as simple as whether
two numbers can be added without overflow in C. Whereas in some
assembly languages, we can just try it and check a flag. Done.
that.

The result is that it's easy to code happy paths in C, and to "document
away" bad inputs as being the caller's or user's problem.

For instance, it's very easy to write a language interpreter in C,
if it's okay for that interpreter to inherit undefined behaviors
of C. (But it usually isn't.)

If we look at the POSIX specification for Awk, it basically waves its
hands in the area of numeric safety. Unless noted otherwise, Awk
expressions just follow C. Situations like division by zero or overflow
are therefore undefined behavior in Awk.

If you're writing an Awk implementation in C, in order to be conforming
to POSIX in the area of arithmetic, you don't have to do anything
special. Your + operator can just pull out some numbers out of the
operand nodes, and blindly hand them down to the C + operator without
any checks. The problem has been punted to the programmer writing the
Awk script.

This is the sort of thing that Rust is striking at: to be able
to write programs with happy paths in which there is implicit safety
for the unhappy inputs.

Problem is we already have plenty of languages which do that, that
are nice to program in and efficient. That's why Rust needs this
marketing positioning as a C and C++ replacement. It's not a compelling
replacement for anything managed, especially if it has a decent
compiler. You will not convince users of managed languages that it's bad
to be able to send an object anywhere in a program, and have multiple
references to it.

I don't believe there is a large application area where problems are so
simple that some primitive single-owner memory management is good
enough, yet we cannot use a nice garbage collected language. And even
in that area, we have to consider the alternative of using two
languages: a nice managed language, with small amount of C (that's
easy to develop and get right).

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

On 2023-07-14, Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
> Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <u8qqpv$3v3pg$1@dont-email.me>,
>> Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
>> ...
>>>> (I don't know Java. Does it really take care of memory management?)
>>>
>>>Yes, it has automatic garbage collection. Those who have started
>>>programming using Java can have considerable difficulties with
>>>manual memory management in C. They are not used to it at all.
>>
>> Much the same could be said about people who start out programming Excel
>> macros. When they start programming in C, they find it very strange that
>> you have to do memory management at all.
>
> You are quite right. The point is that manual memory management
> is an additional burden to the programmer.

The Rust rhetoric is that C++ is bad too, and C++ has great tools for
avoiding manual memory management. You can easily write a program
in C++98 that you can just about prove that has no memory leaks or
use-after-free.

You can also write yourself some numeric classes in C++ with overloaded
operators, such that operations that overflow or underflow will
throw exceptions.

> Creating serious memory leaks is one of the dangerous possibilities
> when coding in C. That danger can be avoided altogether when writing
> in e.g. Java.

There is no shortage of easy-to-use languages which avoid memory leaks
and use-after-free. You're not going to convince their users to switch
to Rust, where they have to deal with unfamiliar restrictions on the
propagation of pointers through the program.

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

On 2023-07-14, David Brown <david.brown@hesbynett.no> wrote:
> On 14/07/2023 16:39, Kenny McCormack wrote:
>> In article <e63aea0c-76ee-4e60-93b2-e22fd996759cn@googlegroups.com>,
>> james...@alumni.caltech.edu <jameskuyper@alumni.caltech.edu> wrote:
>> ...
>>> Many of us post responses to questions out of a sincere desire to be
>>> helpful to the person posting the message, as well as to other people who
>>> may read it. Sometimes we post out of a desire to be helpful to people
>>> who might be confused by a message posted by someone else.
>>
>> I get that that's the standard comeback to my assertion.
>> It may be true at some level, but in the end it all boils down to the same
>> thing. You post because it makes you feel good to do so.
>>
>
> There's a difference between posting for your own enjoyment, and posting
> for your own amusement.

There is big quality range in area of amusement.

For instance, I wouldn't find it amusing to stand on an overpass and
spit on cars passing below, but for some people, it's the highlight
of their existence.

For exactly the same reason I wouldn't be amused by posting the kind of
drivel that comes out of "fir", which is close to being the Usenet
equivalent of "hocking loogies".

It's not enough to justify yourself by *that* you're amused, but
by *how* you are amused.

On 2023-07-14, Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
> Bart <bc@freeuk.com> wrote:
>> So what do you you use to code in? I'm guessing Python
>> and/or Java.
>
> Bash, AWK, Python, C. My University courses had to be
> completed using Java, but that was over 20 years ago.
>
>>> Some people have suggested that Linux kernel modules should
>>> be allowed to be written in Rust, too. I do not know whether
>>> that suggestion was ever accepted by the Linux kernel developers.
>>>
>>>> Portable C is a myth. Even C you wrote 5 minutes ago might not work,
>>>> even on the exact same machine and OS, if someone uses a different set
>>>> of compiler options.
>>>
>>> No. Lots of C programs are quite portable. That includes e.g. Linux
>>> kernel,
>>
>> The Linux kernel is at least 26 million lines of code. It's not all
>> found in the same machine! There are lots of different files for
>> different hardware.
>
> As far as I know, the "different files" are mostly CPU architecture
> speficic assembly code. I could be wrong, though. Maybe you can offer
> some proof?
>
>> So a driver for one device will be different from that for another: you
>> write dedicated C code for each, so portability is not needed.
>
> Ummm...What? I just don't get it. Of course you write dedicated
> code for different devices. What does that have to do with portability?

Well, firstly, drivers *are* often highly portable, similarly to any
other code in the kernel. The same chip can be driven in the same way
when it is found on a different kind of bus attached to a different CPU.

But Bart has the valid point that no single machine contains all the
drivers that there are.

And some devices, even if their drivers are portable in principle,
are found only in some kinds of machines. E.g. I think only PC's
have a text console. Or certain Intel chips for USB.

A lot of kernel contributions come from SoC vendors, where you have
not only architecture support but board support. A large number of
different boards fall under the same architecture, e.g. 32 bit ARM.
Yet they have features that are entirely board specific. The code
will never be compiled other than by someone building the kernel
for that specific board. That code could use ARM inline assembly; ther
ewill never be a version of that board that isn't ARM, so it doesn't
matter.

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

On 2023-07-14, Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> However, none of the code needs to be /widely/ portable. All targets
>> have 32-bit int, 8-bit char, either 32-bit or 64-bit pointers, use ASCII
>> basic character sets, and have many other aspects in common.
>
> I suppose one can argue pretty endlessly about the true
> meaning of "portable code". How many platforms must it run
> on in order to quality as portable? I think there is no
> single correct answer to that question.

If you don't qualify "portable" somehow, like by listing the kinds
of platforms supported, then it means maximally portable.

You open yourself to being roasted for the code assuming ASCII,
8 bit chars, pointers being all equal sized and all that.

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

Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> A lot of kernel contributions come from SoC vendors, where you have
> not only architecture support but board support. A large number of
> different boards fall under the same architecture, e.g. 32 bit ARM.
> Yet they have features that are entirely board specific. The code
> will never be compiled other than by someone building the kernel
> for that specific board. That code could use ARM inline assembly; ther
> ewill never be a version of that board that isn't ARM, so it doesn't
> matter.

Thanks! It is clear to me that my understanding about those things
was completely non-existent... I only recently realized that even my
television might run Linux now, so the level of my ignorance is high
concerning many important issues.

br,
KK

On 2023-07-14, Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
> 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.

This is simply untrue. Undefined behavior is one of the main areas
of vendor extension.

Formally, undefined behavior means that ISO C provides no definition
of behavior. That doesn't mean nobody else provides no definition
of behavior.

A strict interpretation of ISO C is possible under which the use of
any functions that are not in ISO C, and not in the program (i.e. not
defined somewhere in a translation unit of the program) are undefined
behavior. If you use a function called read(), but haven't written
that yourself, and the program translates, links and executes anyway,
that is thanks to undefined behavior.

Merely including a nonstandard header like <unistd.h> is also undefined
behavior. The header is not defined by the program, so there are two
possibilities:

1. The header is not found, which is a diagnosable error.

2. The header is found, necessarily outside of the program, and
replaced by its content. But that content is unknown; it is not
specified by ISO C. The implementor has to document what it is;
e.g. that it provides a POSIX implementation with a <unistd.h>
header. A different implementor, who hates POSIX users and their
programs, could document that #incluce <unistd.h> wipes the disk and
powers down the machine; that would be ISO C conforming.

Secondly, there can be undefined behaviors according to ISO C for
which we can infer a definition anyway, in spite of not having
a documented definition from a vendor.

If we have the source code to a compiler or library (or are otherwise
able to reverse engineer those tools), we can study what the actual
behavior is. We might find that the undefined construct is handled in
such a way that no undefined behavior takes place in the implementation,
and that the construct is handled according to some meaningful rules. If
we freeze that toolchain source code (or else keep monitoring new
releases for regressions), we will get those reliable behaviors.

We can infer definedness of behavior of the object code. Even though
a[i] = i++ is undefined, once we obtain an object file, we can
disassemble it, and find no undefined behavior at the machine level. We
can reverse-engineer it to determine the specification of actual
behavior, and find it to be consistent and reliable. (And then, we can
change the source code so that it achieves that same actual behavior
(possibly even identical object code) in a defined way: a good strategy
for eliminating ambiguity, while reducing the risk of breaking behaviors
relied on by unknown downstream users.)

We can infer definedness of behavior by certain reasoning which leads
to the conclusion that, certain technolology being what it is, it
is not possible for the behavior to go astray.

For instance, if we know that translation units are compiled in
complete isolation from each other, and if we know that translated
files do not retain any information about type (such as the names of
structures and structure members) then we can conclude that two
structure types which have the same shape in different translation
units are de facto compatible.

If one translation unit has functions that accept a "struct point { int
x, y; }", we can link it with another translation unit which declares
the type as "struct cell { int a, b; }" and calls the functions using
that type. ISO C says it is undefined, but it's not possible to write
a program which demonstrates a problem, under a given object file
and linking technology.

For that matter, we could make it "struct cell { long a, b; }" if
the type int and long have the same representation. All that matters
is that we don't break the ABI. But the concept of ABI is outside of
ISO C.

Mixed langauge programming is udefined. If you make program with
C modules and Fortran modules, it's neither a well-defined C program,
nor a well-defined Fortran program.

So the topic of undefined behavior is broad and nuanced; it's not
just a simple category of "bad thing that must never happen",

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

On 2023-07-14, David Brown <david.brown@hesbynett.no> wrote:
> On 14/07/2023 14:08, Kalevi Kolttonen wrote:
>> David Brown <david.brown@hesbynett.no> wrote:
>>> However, none of the code needs to be /widely/ portable. All targets
>>> have 32-bit int, 8-bit char, either 32-bit or 64-bit pointers, use ASCII
>>> basic character sets, and have many other aspects in common.
>>
>> I suppose one can argue pretty endlessly about the true
>> meaning of "portable code". How many platforms must it run
>> on in order to quality as portable? I think there is no
>> single correct answer to that question.
>>
>
> Certainly "portable" has different meanings to different people.

I would hope that "portable" has *all* those meanings simultaneously to
every person gathered here. I understand that both as

- being capable of running on computers found in retrocomputing museums,
as well as Arduinos, and supercomputers.

- running on Windows, Mac and a few Unix-likes.

- and other possibilities.

Different definitions for different situations.

The word does exclude something that runs on exactly one installation
of one machine. Everything else is portable to some extent.

E.g. most well-behaved 80386 code is portable to Core i9.

Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> If you don't qualify "portable" somehow, like by listing the kinds
> of platforms supported, then it means maximally portable.

I see. Is the meaning more formally defined somewhere in an
exact way? Or is it just common knowledge?

My programming skills are so poor that I am 100% convinced I
could not write maximally portable C code. I have too many
incorrect assumptions and would be sure to rely on e.g. some
Implementation Defined behavior. This is no joke but that's
just the way it is. I do not blame C for this - it is entirely
my fault.

> You open yourself to being roasted for the code assuming ASCII,
> 8 bit chars, pointers being all equal sized and all that.

It is sad, but sometimes I take it for granted that the chars are
always exactly eight bits. This is so even though I realize that
it is no more "right" than other choices.

br,
KK

Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> On 2023-07-14, Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
>> Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>> In article <u8qqpv$3v3pg$1@dont-email.me>,
>>> Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
> The Rust rhetoric is that C++ is bad too, and C++ has great tools for
> avoiding manual memory management. You can easily write a program
> in C++98 that you can just about prove that has no memory leaks or
> use-after-free.

Did the Rust folks have this crazy attitude against C++
right from the start when the language was released, and when
everyone was raving about it? If so, I may have read about
it then, but have forgotten it.

Unfortunately I may even have believed it back then. Some of the
Rust features seemed to be improvements over C, but after all,
I thought that you could achieve safe enough code with C
provided that you are careful. What is more, as I am a pretty
old and lazy man now, I did not want to spend my any part of
my life learning Rust.

Anyway, I never realized that the ISO C++ committee has managed
to make C++ that much better. That sounds fantastic.

> There is no shortage of easy-to-use languages which avoid memory leaks
> and use-after-free. You're not going to convince their users to switch
> to Rust, where they have to deal with unfamiliar restrictions on the
> propagation of pointers through the program.

That makes sense.

br,
KK

Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> If we look at the POSIX specification for Awk, it basically waves its
> hands in the area of numeric safety. Unless noted otherwise, Awk
> expressions just follow C. Situations like division by zero or overflow
> are therefore undefined behavior in Awk.

It is awful but I did not know that AWK programs could have undefined
behaviour. I thought that division-by-zero's consequence would be to
always terminate the program.

> If you're writing an Awk implementation in C, in order to be conforming
> to POSIX in the area of arithmetic, you don't have to do anything
> special. Your + operator can just pull out some numbers out of the
> operand nodes, and blindly hand them down to the C + operator without
> any checks. The problem has been punted to the programmer writing the
> Awk script.

That's so terrible.

> This is the sort of thing that Rust is striking at: to be able
> to write programs with happy paths in which there is implicit safety
> for the unhappy inputs.

OK.

> Problem is we already have plenty of languages which do that, that
> are nice to program in and efficient. That's why Rust needs this
> marketing positioning as a C and C++ replacement. It's not a compelling
> replacement for anything managed, especially if it has a decent
> compiler. You will not convince users of managed languages that it's bad
> to be able to send an object anywhere in a program, and have multiple
> references to it.

I am trying to think very hard back, but I don't remember hearing
that the Rust folks claimed that it is supposed to replace C++. My
current understanding was that it was a *C language* replacement
or at least, an improvement in some areas when compared to C.

Thanks for providing correct information.

br,
KK

Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> - being capable of running on computers found in retrocomputing museums,
> as well as Arduinos, and supercomputers.

It is amazing that some people can actually write
code that is so widely portable. It is a pretty
mind-boggling fact that it runs so many different
platforms!

I guess code like that has good chance of surviving
for a long time.

br,
KK

Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> On 2023-07-14, Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
>> 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.
>
> This is simply untrue. Undefined behavior is one of the main areas
> of vendor extension.

Oh no! What have I been thinking!

> Formally, undefined behavior means that ISO C provides no definition
> of behavior.
That I knew...

> That doesn't mean nobody else provides no definition
> of behavior.

....and that I did not! So foolish of me, this is terrible.
I have had serious delusions about the proper meaning for many
years without ever even realizing it.

> A strict interpretation of ISO C is possible under which the use of
> any functions that are not in ISO C, and not in the program (i.e. not
> defined somewhere in a translation unit of the program) are undefined
> behavior. If you use a function called read(), but haven't written
> that yourself, and the program translates, links and executes anyway,
> that is thanks to undefined behavior.

The amount of my ignorance really hurts. Delusions are a horrible
thing to have.

> Merely including a nonstandard header like <unistd.h> is also undefined
> behavior. The header is not defined by the program, so there are two
> possibilities:
>
> 1. The header is not found, which is a diagnosable error.
>
> 2. The header is found, necessarily outside of the program, and
> replaced by its content. But that content is unknown; it is not
> specified by ISO C. The implementor has to document what it is;
> e.g. that it provides a POSIX implementation with a <unistd.h>
> header. A different implementor, who hates POSIX users and their
> programs, could document that #incluce <unistd.h> wipes the disk and
> powers down the machine; that would be ISO C conforming.
>
> Secondly, there can be undefined behaviors according to ISO C for
> which we can infer a definition anyway, in spite of not having
> a documented definition from a vendor.

Got it.

> If we have the source code to a compiler or library (or are otherwise
> able to reverse engineer those tools), we can study what the actual
> behavior is. We might find that the undefined construct is handled in
> such a way that no undefined behavior takes place in the implementation,
> and that the construct is handled according to some meaningful rules. If
> we freeze that toolchain source code (or else keep monitoring new
> releases for regressions), we will get those reliable behaviors.

I am not at all sure whether I got it or not. Not blaming you, though.

> We can infer definedness of behavior of the object code. Even though
> a[i] = i++ is undefined, once we obtain an object file, we can
> disassemble it, and find no undefined behavior at the machine level. We
> can reverse-engineer it to determine the specification of actual
> behavior, and find it to be consistent and reliable. (And then, we can
> change the source code so that it achieves that same actual behavior
> (possibly even identical object code) in a defined way: a good strategy
> for eliminating ambiguity, while reducing the risk of breaking behaviors
> relied on by unknown downstream users.)

Man, that's too complicated for me.

> We can infer definedness of behavior by certain reasoning which leads
> to the conclusion that, certain technolology being what it is, it
> is not possible for the behavior to go astray.

As a more general conclusion, that makes a bit more sense to me.

> For instance, if we know that translation units are compiled in
> complete isolation from each other, and if we know that translated
> files do not retain any information about type (such as the names of
> structures and structure members) then we can conclude that two
> structure types which have the same shape in different translation
> units are de facto compatible.

Does that mean some kind of isomorphism between the two structure
types?

> If one translation unit has functions that accept a "struct point { int
> x, y; }", we can link it with another translation unit which declares
> the type as "struct cell { int a, b; }" and calls the functions using
> that type. ISO C says it is undefined, but it's not possible to write
> a program which demonstrates a problem, under a given object file
> and linking technology.

Well I guess it can work since the names are not important, it all
depends on the identical shape...?

> For that matter, we could make it "struct cell { long a, b; }" if
> the type int and long have the same representation. All that matters
> is that we don't break the ABI. But the concept of ABI is outside of
> ISO C.

I got it.

> Mixed langauge programming is udefined. If you make program with
> C modules and Fortran modules, it's neither a well-defined C program,
> nor a well-defined Fortran program.

I got it, too.

> So the topic of undefined behavior is broad and nuanced; it's not
> just a simple category of "bad thing that must never happen",

I am shocked and mildly amused by my horrendous delusions. Your
explanation was indeed broad yet detailed. My deluded view was
that consisting of "bad thing that must never happen". I was
also *way too sure* that my view was correct... So pathetic.

Many thanks for your time and setting the record straigth.

Why does wisdom take so long to achieve... :-(

br,
KK

kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
[...
>> This is simply untrue. Undefined behavior is one of the main areas
>> of vendor extension.
>
> Oh no! What have I been thinking!
>
>> Formally, undefined behavior means that ISO C provides no definition
>> of behavior.
>
> That I knew...
>
>> That doesn't mean nobody else provides no definition
>> of behavior.
>
> ...and that I did not! So foolish of me, this is terrible.
> I have had serious delusions about the proper meaning for many
> years without ever even realizing it.
>
>> A strict interpretation of ISO C is possible under which the use of
>> any functions that are not in ISO C, and not in the program (i.e. not
>> defined somewhere in a translation unit of the program) are undefined
>> behavior. If you use a function called read(), but haven't written
>> that yourself, and the program translates, links and executes anyway,
>> that is thanks to undefined behavior.
>
> The amount of my ignorance really hurts. Delusions are a horrible
> thing to have.

[...]

Learning something shouldn't be painful.

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

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Learning something shouldn't be painful.

It should not be, but when you realize that you have
been a delusional fool for several years, you really
cannot be very proud of that. Not only it, but I
am also guilty of *spreading false information*.

br,
KK

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.

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

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

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

Po Lu <luangruo@yahoo.com> wrote:
> Not strictly conforming? Easy: any code that assumes
> char is 8 bits wide, or that int can hold values
> larger than 32766.

Thanks, I see. I am pretty sure that the latter
is what most programs do.

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

The "strict conformance" seems unattainable.

br,
KK

piątek, 14 lipca 2023 o 14:46:51 UTC+2 fir napisał(a):
> piątek, 14 lipca 2023 o 14:29:41 UTC+2 Kalevi Kolttonen napisał(a):
> > fir <profes...@gmail.com> wrote:
> > > imo you write a lot of nonsenses in this thread (many belifs not much real)
> > > to teh extent i somewhat feel sorry i stated the question - i forgot that quite
> > > usulally people when some wtate soem question not give answer but produce
> > > a stream of nonsenses.. i thought maybe i will learn something on this
> > > rust maybe (this one i cant learn) instead nonsenses on c..but well you may
> > > continue ofc
> > First of all, I guess you are some kind of a programmer, but
> > you have serious problem with your spelling. Your posts are
> > absolutely awful to read. Try spell checking of some kind
> > and learn to write proper English.
> >
> > Second, what exactly is the point of your emotional outburst?
> >
> > If you think that I write "nonsense", then please point out the
> > errors. It is incredibly stupid to rant about "nonsense" without
> > providing any kind of reasoning. Your post is just worthless garbage.
> >
> you just produce a lot of nonreal belifs and not real points - in discussions here
> many people with time i guess more used to real points.. i dont want to talk on
> c here as i talked on it for 2 decades..the question was more like if ruest can really outhrone
> c and say if there are some real points /reasons related to that
>
> howewer crowd of programmers often works like you do - its more driven by blifs and
> nonsenses (as in kase of pony++) than real points..so lack of real points may not be deciding
> sadly

so the answer is probably may (like probably any low-lewel compiled language could) but probably will not doo.. hovever i guess when some amount of helpfull language additions will appear such new language may outthrone c then - probably...wchich may be pity as c unside his faults (like this passing via pointer, no multiply values return and to wack support for modularisation/header stuff, also no vector arithmetic and macros who allow to make chaos and so on) has very strong core unseen imo in any other alnguege i seen...
we will see

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.

Paul N <gw7rib@aol.com> wrote:
> 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.

I see, thanks. That would satisfy the requirements I gave.

However, saying "just like other bugs" somehow seems to
give the impression that there would be many bugs that
could satisfy the requirements.

Finding a single example is a very good thing, but it
would be more convincing if there were more examples.

br,
KK

On 14/07/2023 23:35, Kalevi Kolttonen wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>> If you don't qualify "portable" somehow, like by listing the kinds
>> of platforms supported, then it means maximally portable.
>
> I see. Is the meaning more formally defined somewhere in an
> exact way? Or is it just common knowledge?
>
> My programming skills are so poor that I am 100% convinced I
> could not write maximally portable C code. I have too many
> incorrect assumptions and would be sure to rely on e.g. some
> Implementation Defined behavior. This is no joke but that's
> just the way it is. I do not blame C for this - it is entirely
> my fault.
>
>> You open yourself to being roasted for the code assuming ASCII,
>> 8 bit chars, pointers being all equal sized and all that.

These things should not be a problem. Keep your pointers as pointers of
compatible type - there is rarely a good reason for wanting to convert a
pointer-to-int to a pointer-to-float, and certainly not for mixing data
pointers and function pointers. Think about what your pointers are
pointing at, and use that as the basis for types. And if you ever think
you need to mess with pointer types, you are probably better using
memcpy/memmove.

Use "char" to hold characters, and never use it for anything else, then
its size doesn't matter, nor does the character encoding. The only
other use for any kind of "char" should be "unsigned char" and its
pointers, which is the C type for low-level memory access. (It should
have been called "byte", to match the standard's term, but it's far too
late for that now.)

For integer types, prefer the types from <stdint.h>. They let you give
more explicit size information and support efficient code generation
across a wide range of targets.

>
> It is sad, but sometimes I take it for granted that the chars are
> always exactly eight bits. This is so even though I realize that
> it is no more "right" than other choices.
>

There is really only two areas where CHAR_BIT is greater than 8. One is
a few dinosaur mainframes, and the other is DSP devices. It is rare
that anyone needs to write code that is portable to such targets.

Generally if your code really depends on something like the size of
CHAR_BIT, it is already limited in its portability by things you are
doing, such as OS system calls.

On 15/07/2023 00:56, Kalevi Kolttonen wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Learning something shouldn't be painful.
>
> It should not be, but when you realize that you have
> been a delusional fool for several years, you really
> cannot be very proud of that. Not only it, but I
> am also guilty of *spreading false information*.
>

In the C standards, the term "undefined behaviour" is defined as:

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

So extensions to C are undefined behaviour in respect to the C standard,
but defined behaviour in respect to the implementation. As far as the
standard is concerned, and therefore for the C language in general,
signed integer overflow is undefined behaviour. However, if you are
coding for "gcc -fwrapv", then the behaviour is fully defined by the
implementation.

So "undefined behaviour" can mean "not defined by the C standards", or
it can also mean "not defined by the C standards, the implementation's
documentation, and any other standards, manuals, or references relevant
to the program in question". It is important to be clear what you mean
by the term at the time (I am not always good enough at that myself).
Here in comp.lang.c, the default for all terms is the definition in the
C standards. But sometimes the second meaning (or a variation of it) is
more relevant.