On Fri, 11 Apr 2025 17:22:37 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
On 2025-04-11, Michael S <already5chosen@yahoo.com> wrote:
On Thu, 10 Apr 2025 17:59:15 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
An understanding of what "compatible types" means.
Bart didn't say that types are compatible or non-compatible.
He said that they are 'compatible enough'. That is not terminology
of C Standard, but terminology of his own. And he seems to
understand it.
In my own translation, 'compatible enough' means that when these
structs are accessed then any sane or even semi-sane compiler will
generate code that will have the same effect as in case of access
through structures with literally identical declarations.
so struct { long x; } and struct { int x; } are compatible enough,
in situations that are portable enough.
I wish they would be, but according to C Standard they are not,
ene when both represent 32-bt signed integer. That's because of
misfeature called 'strong aliasing rules'.
IMO, C would become better without this misfeature.
[...]
Read what people write, not what you think they meant.
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
Read what people write, not what you think they meant.
This rule is a good one for other people too.
Michael S <already5chosen@yahoo.com> writes:
On Fri, 11 Apr 2025 17:22:37 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
On 2025-04-11, Michael S <already5chosen@yahoo.com> wrote:
On Thu, 10 Apr 2025 17:59:15 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
An understanding of what "compatible types" means.
Bart didn't say that types are compatible or non-compatible.
He said that they are 'compatible enough'. That is not terminology
of C Standard, but terminology of his own. And he seems to
understand it.
In my own translation, 'compatible enough' means that when these
structs are accessed then any sane or even semi-sane compiler will
generate code that will have the same effect as in case of access
through structures with literally identical declarations.
so struct { long x; } and struct { int x; } are compatible enough,
in situations that are portable enough.
I wish they would be, but according to C Standard they are not,
ene when both represent 32-bt signed integer. That's because of
misfeature called 'strong aliasing rules'.
IMO, C would become better without this misfeature.
I think this reaction is rather shortsighted. Making this change
would incur several downsides, and offers no significant upside
that I can see.
First it would greatly complicate the language semantics.
Whether a program is meaningful, and if so what the meaning is,
would be much harder to state than it is now.
Second it would imply that whether a program is well-defined is a
lot more dependent on implementation-specific choices than it is
now.
Third, as a consequence of that, it would be harder to write
program verification tools, because they would need to take these
more extensive implementation dependencies into consideration.
Fourth, there would be consequences for program optimization, and
it is hard to dismiss those. Some people may not care about the optimizations losses, but certainly many people want the benefits
of those optimizations.
Fifth, related to the previous point, as a practical matter it would
make getting the optimization benefits back again be nearly
impossible. As things are now, it's easy to have a compiler option
to disable the consequences of strong typing rules, and the result
can still be a conforming implementation. But if the C standard
would prescribe the semantics of cross-type access, then any option
to ignore the implications of that prescription would necessarily
make using said option result in a non-conforming implementation.
To say the last point another way, with things as they are now
developers can choose whether they want to observe the cross-type
access restrictions, or ignore them, and still get a C compiler.
If the effective type rules were discarded, there is no way to
choose the more-optimizing path without getting something that
is not a C compiler.
Given that you can always get what you want either by choosing
an appropriate compiler option (if available) or by using one of
the well-known legal workarounds, I think it's hard to make a
case that getting rid of the effective type restrictions is a
good idea.
On 09.05.2025 17:26, Richard Heathfield wrote:
On 09/05/2025 16:04, Bonita Montero wrote:
Am 09.05.2025 um 17:01 schrieb Scott Lurndal:
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 06.04.2025 um 17:14 schrieb Tim Rentsch:
My impression was that "defer", or something very much like
it, is being considered for inclusion in a future C standard. ...
With C++ you can have defer without extending the language.
This, however is comp.lang.c.
I'm just trying to make it clear that C lacks convenience
and productivity on every level.
Then use something convenient and productive. But please confine your
discussions of your chosen alternative to
comp.lang.your.chosen.alternative instead of dragging them into
comp.lang.c, where we discuss C.
Since some folks feel comfortable in their "C" bubble I understand
that these people might feel annoyed by such posts.
But showing deficiencies (in "C") and providing counter-examples or alternatives from other languages [as done here] should be welcome.
(IMO. YMMV, of course.) [...]
But of course no one forces these annoyed people to read all posts; suggestions had already been given to just skip those inconvenient
threads or subhreads.
For plain integer types, however, I think the argument for making
equal-sized types compatible is a lot stronger. Some compilers
specifically say that they allow aliasing between such types (MSVC,
according to what I have read, have said they never intend to support
"strict aliasing" optimisations). Many software projects (such as
Linux) use "-fno-strict-aliasing". And countless C programmers
mistakenly believe that identically sized integer types are compatible (though I am not advocating for a weaker language simply because some
users misunderstand the rules).
David Brown <david.brown@hesbynett.no> writes:
[...]
For plain integer types, however, I think the argument for making
equal-sized types compatible is a lot stronger. Some compilers
specifically say that they allow aliasing between such types (MSVC,
according to what I have read, have said they never intend to support
"strict aliasing" optimisations). Many software projects (such as
Linux) use "-fno-strict-aliasing". And countless C programmers
mistakenly believe that identically sized integer types are compatible
(though I am not advocating for a weaker language simply because some
users misunderstand the rules).
I think that a lot of C programmers misunderstand what "compatible
types" means. Many seem to think that two types are compatible if
they have the same representation and can be assigned without a cast.
In fact type compatibility is a much stricter concept than that.
Two types are compatible if they are *the same type*, and in a few
other circumstances. For example, char, signed char, and unsigned
char are all incompatible with each other, even though two of them
are guaranteed to have the same representation.
A good way to think about it is that pointers to two types can be
assigned without a cast if and only if the two types are compatible.
For example, int and long objects can be assigned to each other
without a cast, but int* and long* objects cannot.
And changing the language to make int and long conditionally
compatible would (a) make it too easy to write code that's valid
in one implementation but violates a constraint in another, and (b)
would break existing code.
For example, a generic selection cannot
have two associations with compatible types. _Generic with "int:"
and "long:" would become invalid for implementations that make int
and long compatible.
(I wouldn't mind seeing a new form of generic association that
selects the *first* matching type, but that's another can of worms.)
On 09/05/2025 17:54, Janis Papanagnou wrote:
[...]
Comparisons between C and other languages can certainly be on-topic for
a C group. And deficiencies of C are as topical as the language's good points.
However, Bonita's post here - like almost all Bonita's posts in this
group - are not helpful or topical, but merely trolls of "C++ is vastly better than C - look at this line noise to see what you can do in C++".
Consider this about Bonita's post :
[ farraginous list snipped ]
(Note: I'm not saying that the previous post's content is correct,
just that it was obviously meant as an improvement, which could or
not affect evolution of "C" if considered; a point for discussion
[for those who think it's worth].)
It is not at all surprising that people find Bonita's posts in
comp.lang.c annoying, and would be happier if they were restricted to comp.lang.c++. Most people just ignore them, others use killfiles, and
some people optimistically try to persuade Bonita not to write such
posts. I'd be surprised if there was anyone who actually thought they
were a positive contribution to the group.
As a general principle, I agree with you that languages other than C can
at times be relevant and interesting in this group - but in this
specific case, I see no value in Bonita's post.
On 09/05/2025 16:54, Janis Papanagnou wrote:
<snip>
Since some folks feel comfortable in their "C" bubble I understand
that these people might feel annoyed by such posts.
Each newsgroup has a topic. I subscribe to no fewer than ten newsgroups, because I am interested in those ten topics. If you are interested in
C++, you can subscribe to comp.lang.c++ and chat about it all day long
and nobody will bat an eyelid. I have no doubt that many comp.lang.c subscribers are also subscribed to comp.lang.c++. Why not join their
number, and keep the salt in the salt pot and the pepper in the pepper pot?
But showing deficiencies (in "C") and providing counter-examples or
alternatives from other languages [as done here] should be welcome.
Why?
Four important ways that C scores over other languages are:
* Speed
* Simplicity
* Size
* Portability
The more you add, the more likely you are to slow it down, the more
complex you make it, the bigger it gets, and the harder it is to port.
[...]
[...]
But of course no one forces these annoyed people to read all posts;
suggestions had already been given to just skip those inconvenient
threads or subhreads.
This comment sounds like hearing from a neighbor that I shouldn't
mind if his dog shits on my lawn, because I can easily step over
the shit.
Except that here there is a notable difference, in
that it isn't the dog but the dog's owner doing the shitting.
On 09.05.2025 18:26, Richard Heathfield wrote:
On 09/05/2025 16:54, Janis Papanagnou wrote:
<snip>
Since some folks feel comfortable in their "C" bubble I understand
that these people might feel annoyed by such posts.
Each newsgroup has a topic. I subscribe to no fewer than ten newsgroups,
because I am interested in those ten topics. If you are interested in
C++, you can subscribe to comp.lang.c++ and chat about it all day long
and nobody will bat an eyelid. I have no doubt that many comp.lang.c
subscribers are also subscribed to comp.lang.c++. Why not join their
number, and keep the salt in the salt pot and the pepper in the pepper pot?
(You seem to have missed the point; see below.)
But showing deficiencies (in "C") and providing counter-examples or
alternatives from other languages [as done here] should be welcome.
Why?
Four important ways that C scores over other languages are:
* Speed
* Simplicity
* Size
* Portability
The more you add, the more likely you are to slow it down, the more
complex you make it, the bigger it gets, and the harder it is to port.
See; now you're discussing
(in a very principle way) why the other
poster's suggestion makes no sense [to you]. - That was the point.
(And you can always skip questions or suggestions or discussions
you are not interested in.)
On 09.05.2025 19:09, David Brown wrote:
On 09/05/2025 17:54, Janis Papanagnou wrote:
[...]
Comparisons between C and other languages can certainly be on-topic for
a C group. And deficiencies of C are as topical as the language's good
points.
However, Bonita's post here - like almost all Bonita's posts in this
group - are not helpful or topical, but merely trolls of "C++ is vastly
better than C - look at this line noise to see what you can do in C++".
Yes, I understand your dislike. And in this case it's specifically easy
for folks who dislike specific persons or dislike what they say what
they can or should do about that. (And below in your post you formulate
some personal options one may take to not see those people or their contributions any more.)
Consider this about Bonita's post :
[ farraginous list snipped ]
Sure. - But there was no need to analyze or list all that (for me at
least); you may have noticed my statement (and read between the lines;
if it's not obvious I may have formulated that better, I admit.)
I think with a good grain of serenity we could also spare us those
longish threads. Let's individually pick and choose what we like.
On 12.05.2025 20:44, Tim Rentsch wrote:
[...]
But of course no one forces these annoyed people to read all posts;
suggestions had already been given to just skip those inconvenient
threads or subhreads.
This comment sounds like hearing from a neighbor that I shouldn't
mind if his dog shits on my lawn, because I can easily step over
the shit.
This comparison says, unfortunately, a lot more about you than
about anything else.
It was a while back now, but there was a time when I lobbied in this
group for a slight relaxing of topicality rules - not by breaching those rules, but by inviting discussion, cavassing opinions, and collating
them into a show of hands. By an overwhelming majority the group turned
me down. I didn't tell them 'to hell with you, I'll discuss what I damn
well want to, and if you don't like it, tough cheese'; I accepted the group's decision.
There may well be some subscribers here who remember that discussion and might be prepared to corroborate the above.
It was a while back now, but there was a time when I lobbied in this
group for a slight relaxing of topicality rules - not by breaching
those rules, but by inviting discussion, cavassing opinions, and
collating them into a show of hands. By an overwhelming majority the
group turned me down. I didn't tell them 'to hell with you, I'll
discuss what I damn well want to, and if you don't like it, tough
cheese'; I accepted the group's decision.
There may well be some subscribers here who remember that discussion
and might be prepared to corroborate the above.
On 12/05/2025 22:25, Keith Thompson wrote:....
I think that a lot of C programmers misunderstand what "compatible
types" means. Many seem to think that two types are compatible if
they have the same representation and can be assigned without a cast.
Yes. Basically, most C programmers are not particularly aware of the technical definitions of some of the terms in C standards where they
differ from common usage. The word "compatible" in English means that
the things in question can work together or fit together.
On 5/13/25 05:40, David Brown wrote:
On 12/05/2025 22:25, Keith Thompson wrote:...
I think that a lot of C programmers misunderstand what "compatible
types" means. Many seem to think that two types are compatible if
they have the same representation and can be assigned without a cast.
Yes. Basically, most C programmers are not particularly aware of the
technical definitions of some of the terms in C standards where they
differ from common usage. The word "compatible" in English means that
the things in question can work together or fit together.
That's pretty much what it means in C. Two C types are compatible in C
if the C standard *guarantees* that they can work together - that you
can use the types interchangeably. The tricky part is the definition of
which pairs of types the C standard makes those guarantees for.
The key point is that the undefined behavior of code which treats incompatible types as if they were compatible could also be that they
work together, too, depending upon the implementation.
On 5/13/25 05:40, David Brown wrote:
On 12/05/2025 22:25, Keith Thompson wrote:
...
I think that a lot of C programmers misunderstand what "compatible
types" means. Many seem to think that two types are compatible if
they have the same representation and can be assigned without a cast.
Yes. Basically, most C programmers are not particularly aware of the
technical definitions of some of the terms in C standards where they
differ from common usage. The word "compatible" in English means that
the things in question can work together or fit together.
That's pretty much what it means in C. Two C types are compatible
in C if the C standard *guarantees* that they can work together -
that you can use the types interchangeably. [...]
James Kuyper <jameskuyper@alumni.caltech.edu> writes:....
On 5/13/25 05:40, David Brown wrote:
Yes. Basically, most C programmers are not particularly aware of the
technical definitions of some of the terms in C standards where they
differ from common usage. The word "compatible" in English means that
the things in question can work together or fit together.
That's pretty much what it means in C. Two C types are compatible in C
if the C standard *guarantees* that they can work together - that you
can use the types interchangeably. The tricky part is the definition of
which pairs of types the C standard makes those guarantees for.
The key point is that the undefined behavior of code which treats
incompatible types as if they were compatible could also be that they
work together, too, depending upon the implementation.
I suggest that the phrase "work together" is too vague.
On 09/05/2025 15:25, Bonita Montero wrote:
Am 10.04.2025 um 00:07 schrieb Tim Rentsch:
When someone is responding to a post, they are responding ONLY to
the content in the posting they are responing to; not to some
earlier posting in the same thread, not to a different posting
submitted two weeks ago, not to what you meant to say but didn't,
not to thoughts in your head but that you didn't say, but ONLY TO
WHAT IS SAID IN THE POSTING BEING RESPONDED TO.
If you can learn to follow this simple rule everyone in the
newsgroup will be better off, including you.
You're constantly overwhelmed by what people write here. Both in
terms of content and the nature of the discussion. Don't try to
constantly set rules; that seems petty.
Tim's not setting a draconian rule in stone. He's presenting a
perfectly sensible rule of thumb that is based on his decades of
experience of posting to this group. Usenet works best when you snip
the bits you're not replying to, and reply only within the context you
have retained. Nearly all the leading experts in this group nearly
always observe this rule of thumb, because it's simple common sense so
to do.
On what basis do you justify laying down your law for Tim to follow?
On 5/13/25 20:51, Keith Thompson wrote:
James Kuyper <jameskuyper@alumni.caltech.edu> writes:...
On 5/13/25 05:40, David Brown wrote:
Yes. Basically, most C programmers are not particularly aware of the
technical definitions of some of the terms in C standards where they
differ from common usage. The word "compatible" in English means that
the things in question can work together or fit together.
That's pretty much what it means in C. Two C types are compatible in C
if the C standard *guarantees* that they can work together - that you
can use the types interchangeably. The tricky part is the definition of
which pairs of types the C standard makes those guarantees for.
The key point is that the undefined behavior of code which treats
incompatible types as if they were compatible could also be that they
work together, too, depending upon the implementation.
I suggest that the phrase "work together" is too vague.
I was trying to match the wording of the text I was responding to. What
I meant can be made far more precise: the C standard guarantees that two compatible types will work together, in the sense that every case where
the C standard mandates that two types must be compatible in order for something to work, it will work for them.
On 13/05/2025 14:54, Janis Papanagnou wrote:
[...]
I think with a good grain of serenity we could also spare us those
longish threads. Let's individually pick and choose what we like.
No, let's not. Let's - at least occasionally - take some responsibility
and not ignore inappropriate behaviour. I don't want to drag this out,
or overreact - Bonita's posts are not /that/ bad. But be clear on this:
it was not Richard's post berating Bonita that made a long thread branch about topicality, it was /your/ post complaining about his post.
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
On 5/13/25 05:40, David Brown wrote:
On 12/05/2025 22:25, Keith Thompson wrote:...
I think that a lot of C programmers misunderstand what "compatible
types" means. Many seem to think that two types are compatible if
they have the same representation and can be assigned without a cast.
Yes. Basically, most C programmers are not particularly aware of the
technical definitions of some of the terms in C standards where they
differ from common usage. The word "compatible" in English means that
the things in question can work together or fit together.
That's pretty much what it means in C. Two C types are compatible in C
if the C standard *guarantees* that they can work together - that you
can use the types interchangeably. The tricky part is the definition of
which pairs of types the C standard makes those guarantees for.
The key point is that the undefined behavior of code which treats
incompatible types as if they were compatible could also be that they
work together, too, depending upon the implementation.
I suggest that the phrase "work together" is too vague. It's
perfectly reasonable to say that two types that can be assigned to
each other without casts can "work together", and I might even call
them "compatible" if the standard didn't already define the term.
To a first approximation, two types are compatible if they're the
same type. The standard's section on compatible types points to
additional rules for some cases. IMHO the English word "compatible"
suggests a much looser relationship, but we're stuck with the
standard's terminology (and I'm not sure what would be better).
On 13/05/2025 13:55, Janis Papanagnou wrote:
(And you can always skip questions or suggestions or discussions
you are not interested in.)
And if someone urinates in your beer, you can always spit it out, right?
[...]
On 13/05/2025 14:13, Janis Papanagnou wrote:
On 12.05.2025 20:44, Tim Rentsch wrote:
[...]
But of course no one forces these annoyed people to read all posts;
suggestions had already been given to just skip those inconvenient
threads or subhreads.
This comment sounds like hearing from a neighbor that I shouldn't
mind if his dog shits on my lawn, because I can easily step over
the shit.
This comparison says, unfortunately, a lot more about you than
about anything else.
On the contrary, it says a lot more about you who choose to put your own agenda above the group dynamic because other people's opinions don't
matter to you.
[...]
Nobody can stop you posting whatever the hell you like here... except
you. So the question comes down to whether you are an adult with the
capacity for self-control and the will to participate in a way that
observes the customs of the people whose company you have sought, or
whether you are just a spoiled teenager in an adult's body.
The choice is entirely yours.
On 13.05.2025 15:35, Richard Heathfield wrote:
On 13/05/2025 13:55, Janis Papanagnou wrote:
(And you can always skip questions or suggestions or discussions
you are not interested in.)
And if someone urinates in your beer, you can always spit it out, right?
You seem to like (as Tim in another post) disgusting, inappropriate and misleading comparisons.
On 13.05.2025 15:46, Richard Heathfield wrote:
On 13/05/2025 14:13, Janis Papanagnou wrote:
On 12.05.2025 20:44, Tim Rentsch wrote:
[...]
But of course no one forces these annoyed people to read all posts;
suggestions had already been given to just skip those inconvenient
threads or subhreads.
This comment sounds like hearing from a neighbor that I shouldn't
mind if his dog shits on my lawn, because I can easily step over
the shit.
This comparison says, unfortunately, a lot more about you than
about anything else.
On the contrary, it says a lot more about you who choose to put your own
agenda above the group dynamic because other people's opinions don't
matter to you.
I have no agenda
On 14/05/2025 04:23, James Kuyper wrote:
On 5/13/25 20:51, Keith Thompson wrote:
James Kuyper <jameskuyper@alumni.caltech.edu> writes:...
On 5/13/25 05:40, David Brown wrote:
Yes. Basically, most C programmers are not particularly aware of the >>>>> technical definitions of some of the terms in C standards where they >>>>> differ from common usage. The word "compatible" in English means that >>>>> the things in question can work together or fit together.
That's pretty much what it means in C. Two C types are compatible in C >>>> if the C standard *guarantees* that they can work together - that you
can use the types interchangeably. The tricky part is the definition of >>>> which pairs of types the C standard makes those guarantees for.
The key point is that the undefined behavior of code which treats
incompatible types as if they were compatible could also be that they
work together, too, depending upon the implementation.
I suggest that the phrase "work together" is too vague.
I was trying to match the wording of the text I was responding to. What
I meant can be made far more precise: the C standard guarantees that two
compatible types will work together, in the sense that every case where
the C standard mandates that two types must be compatible in order for
something to work, it will work for them.
That's a tautology - the C standard guarantees that two compatible types will work together in situations where the C standard requires that the types are compatible.
On 14/05/2025 04:23, James Kuyper wrote:....
I was trying to match the wording of the text I was responding to. What
I meant can be made far more precise: the C standard guarantees that two
compatible types will work together, in the sense that every case where
the C standard mandates that two types must be compatible in order for
something to work, it will work for them.
That's a tautology - the C standard guarantees that two compatible
types will work together in situations where the C standard requires
that the types are compatible.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 8 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 95:40:06 |
| Calls: | 161 |
| Files: | 21,502 |
| Messages: | 78,438 |