On 2025-04-10, bart <
bc@freeuk.com> wrote:
On 10/04/2025 23:18, Janis Papanagnou wrote:
On 10.04.2025 17:12, bart wrote:
On 10/04/2025 15:33, Scott Lurndal wrote:
bart <bc@freeuk.com> writes:
On 10/04/2025 12:28, Keith Thompson wrote:
bart <bc@freeuk.com> writes:
[...]
Someone, not anyone but the all-knowing Tim, said: "and those types
are not compatible, because the two struct tags are different."
>
Do you agree with that? Or is there something more to making two types
be incompatible?
>
I don't recall the exact discussion
>
It stems from this, a reply from DB dated: "Tue, 8 Apr 2025 16:50:56
+0200". (About half way down there is some quoted code of mine.)
>
It concerned two struct types in different translations units, which
needed to be compatible for the test program to work corectly.
>
I said they were compatible enough. David said they were entirely
compatible. Tim said "No they are not". Three different opinions.
>
If you pretend not to understand the C standard, you can argue
about it forever.
>
It's been explained to you more than once, but really, just read
the flippin standard and stop arguing.
>
Fucking hell.
>
Three people have said three different things. They can't all be right.
>
But according to you, only one of them is wrong: me, even though the
other two have made exactly opposite claims!
>
So to you it's not about who's right and who's wrong; you are just
CONSTANTLY having a go at me personally for reasons that are nothing to
do with the subject. That is persecution.
>
In fact you don't really care about the topic (if you're even aware of
it). So, FUCK YOU.
>
As for reading the standard, since that is this group's favourite
subject, then why does the group even exist? Since every possible
question can be answered there.
"I don't recall the exact discussion", and less the context of any
formulation in any of the many posts. I also don't understand what
your goal is. As I see it some posters tried to explain aspects of
the topic to you, and they feel that you didn't understand it but
are instead arguing just for the argument. Your post seems to show
a desire that you want one (or two) of these posters to be wrong.
It was suggested to you to refer to the standard document to clear
the topic since there's obviously an unsolvable communication issue
between the participants.
I basically do agree with your perception of this newsgroup and its
purpose. But...
*If* you're really interested in the topic, and since all the other
posters obviously gave up to continue explaining their sight to you,
why don't you accept that suggestion and read the standard document
to have clarity about the topic? [FYI; this was a rhetoric question.]
>
I've read the document, or the relevant section. According to that, DB
was wrong, and TR was half-right.
>
Neither of them is willing to back down, while no one else is willing to
back me up: KT will not say anything against his mates, and SL hasn't
really got a clue about the topic, but he never misses a change to put
the boot in when I'm already on the ground.
These persecution complexes are pointless. What backs you up is
chapter-and-verse citations with solid analysis, if required. That's it.
If you don't want to read standards, go to notebooklm.google.com
create a workspace there, and upload the documents into it.
Then you can ask the friendly AI questions about it.
Let me try it. Okay, I gave it C90, draft C99 and the current
workign draft N3301. I have those three documents in the workspace.
Let's try a question to the AI:
What changed in the concept of two struct types being compatible in
C90, C99 and the current draft version of C?
The answer is long, but looks pretty good. You don't see it in the
copy and paste, but in the workspace chat window, it has links to
citations from the documents I uploaded to check the facts.
Here is the answer:
The concept of compatibility between two struct types has evolved across
C90, C99, and the current draft version of C. Here's a breakdown of
the key changes:
C90 Standard:
In C90, as described in, two structure types declared in separate translation
units are considered to have **compatible types** if they meet the following
criteria:
* They have the **same number of members**.
* The members have the **same names**.
* The corresponding members have **compatible types**.
* For structures, the members must be declared in the **same order**.
* For structures or unions, any **bit-fields** must have the **same widths**.
It's important to note that C90 primarily focused on the structural
similarity of the types in terms of their members when declared
separately. All declarations referring to the same object or function
were also required to have compatible types. A structure declaration
introduced a new type within a translation unit, and this type was
incomplete until the closing brace of the definition.
C99 Standard:
C99 introduced the crucial concept of **tags** for determining
compatibility between structure, union, or enumeration types declared
in separate translation units. The rules for compatibility became:
* If one type is declared with a **tag**, the other must be declared
with the **same tag**.
* If both are **complete types**, they must have:
* A **one-to-one correspondence** between their members.
* Each pair of corresponding members declared with **compatible
types**.
* If a member has a name, the corresponding member must have the
**same name**.
* For structures, corresponding members must be declared in the
**same order**.
* For structures or unions, corresponding **bit-fields** must
have the **same widths**.
* For enumerations, corresponding members must have the **same
values**.
C99 emphasized that for structure, union, or enumerated types declared
in different scopes or using different tags, they declare **distinct
types**. Even declarations without a tag declared distinct types. This
shift towards tag-based compatibility provided a stronger mechanism
for ensuring type safety across different compilation units.
Current C Draft (n3301.pdf):
The current draft of the C standard further refines the rules for
structure type compatibility:
* For two **complete structure, union, or enumerated types declared
with the same tag** to be compatible:
* There must be a **one-to-one correspondence** between their
members with **compatible types**.
* If one member has an **alignment specifier**, the other must
have an **equivalent alignment specifier**.
* Corresponding members must have the **same name**.
* For structures, corresponding members must be in the **same
order**.
* For unions declared in the same translation unit,
corresponding members must be in the **same order**.
* Corresponding **bit-fields** must have the **same widths**.
* For enumerations, corresponding members must have the **same
values**, and if one has a **fixed underlying type**, the other must
have a **compatible fixed underlying type**.
* The draft introduces the concept that **anonymous structures
and unions** are considered regular members, and their types are
compatible if their members fulfill the preceding requirements.
* For structure, union, or enumerated types declared in **separate
translation units**, they are compatible in the following cases:
* Both are declared **without tags** and fulfill the
member-based requirements.
* Both have the **same tag** and are **completed** somewhere in
their respective translation units, fulfilling the member-based
requirements.
* Both have the **same tag**, and **at least one** of the two
types is **not completed** in its translation unit.
The current draft continues to emphasize tag-based compatibility
but adds nuances like the consideration of alignment specifiers and
explicitly addresses anonymous structures and unions. The summary of
changes from C99 mentions "**improved tag compatibility rules, enabling
more types to be compatible with other types**", indicating a trend
towards a more flexible yet still type-safe system. Similar to C99,
declarations in different scopes or with different tags still declare
distinct types.
-- TXR Programming Language: http://nongnu.org/txrCygnal: Cygwin Native Application Library: http://kylheku.com/cygnalMastodon: @Kazinator@mstdn.ca
do { quit; } else { }
Re: do { quit; } else { }