Linux 5.15's New "-Werror" Behavior Is Causing A Lot Of Pain

[indepe]

http://www.open-std.org/jtc1/sc22/wg...docs/n1570.pdf
No two signed integer types shall have the same rank, even if they have the same representation.
and
The rank of any unsigned integer type shall equal the rank of the corresponding signed integer type, if any.
Rules in C11 are down right cursed. In fact they first appear in C90 draft.
The no two signed integer types shall have the same rank even if they have the same representation nukes that old C89 synonym rule.

No, it doesn't "nuke" it. Why would you even get the idea it could?

"No two signed integer types shall have the same rank, even if they have the same representation."

That refers for example to long-long-int and long-int on a 64 bit system. They both have the same 64 bit representation, but long-long-int nevertheless has a higher rank.

Simple rule and has nothing to do with synonyms. I think you are completely on the wrong track with your idea that "typedef" types have a different rank. They are the same type, not two types.

That's one of the things that make it so complicated for you. It's complicated, but not that complicated.

[indepe]

Adding to my preceding post above, since on re-reading I noticed this sentence specifically:

Yes typedef in it name says type define as in create new type that is what makes first rule highlighted here apply and that then kicks on to the second comes a problem.

That is exactly what it does NOT say, not for C89 and not for C11. Apparently you missed this part of the C11 definitions:

In chapter 6.7.8 page 137 of the C11 doc http://www.open-std.org/jtc1/sc22/wg...docs/n1570.pdf

A typedef declaration does not introduce a new type, only a
synonym for the type so specified. That is, in the following declarations:
typedef T type_ident;
type_ident D;
type_ident is defined as a typedef name with the type specified by the declaration
specifiers in T (known as T ), and the identifier in D has the type ‘‘derived-declarator-
type-list T ’’ where the derived-declarator-type-list is specified by the declarators of D.

So, to simplify that, if you have:

typedef unsigned long int  my_uli;
my_uli  uvar;

Then uvar is of type unsigned long int (not some other new type).

That misinterpretation has apparently caused you to misinterpret all the other type ranking rules.

[oiaohm]

In chapter 6.7.8 page 137 of the C11 doc http://www.open-std.org/jtc1/sc22/wg...docs/n1570.pdf

A typedef declaration does not introduce a new type, only a
synonym for the type so specified.

Bad news that is not in fact in C90 or the first draft of C11. So real world compilers claiming to be C11 may not have that behaviour. That there is the last draft of C11.

Yes gcc early C11 support is not based off the last draft but the first draft C11.

typedef unsigned long int my_uli;
my_uli uvar;

Then uvar is of type unsigned long int (not some other new type).

So you to be sure this happens you do in fact need to check the standard version. __STDC_VERSION__ yes if you are meant to be in C11 mode and you don't get 201112L out the compiler you have a compiler on some earlier draft to final. Earlier draft supporting compilers can be missing key bits. Yes if that value is "201ymmL" or one of the other C standard placeholders really be worried as this is a person who has implemented the compiler and cannot read a standard to save themselves.

This is a very common mistake people don't check the standard version number to make sure that the assumes they are making are in fact backed by standard the compiler has implemented.

indepe one of the most common mistakes with C is not check you C compilers standard version number/date(__STDC_VERSION__). Yes this leads to some very warped problems what would have been easy to detect by checking the standard version number and noticing its not a formal release version or it some version with some odd ball written error.

[indepe]

Bad news that is not in fact in C90 or the first draft of C11. So real world compilers claiming to be C11 may not have that behaviour. That there is the last draft of C11.

Yes gcc early C11 support is not based off the last draft but the first draft C11.

Bad news? Funny. Why don't you link one of those intermediate drafts?

The typedef meaning has been like that since K&R, and its is in C89, C99, and C11: http://port70.net/~nsz/c/
It's been there since the beginning and it will be there 'til the end.

As you say yourself, anything else doesn't make any sense, and if some intermediate draft forgot to mention it, I doubt any compiler changed because of that, and if it did, that would only say something about that compiler engineer.

So you to be sure this happens you do in fact need to check the standard version. __STDC_VERSION__ yes if you are meant to be in C11 mode and you don't get 201112L out the compiler you have a compiler on some earlier draft to final. Earlier draft supporting compilers can be missing key bits. Yes if that value is "201ymmL" or one of the other C standard placeholders really be worried as this is a person who has implemented the compiler and cannot read a standard to save themselves.

This is a very common mistake people don't check the standard version number to make sure that the assumes they are making are in fact backed by standard the compiler has implemented.

indepe one of the most common mistakes with C is not check you C compilers standard version number/date(__STDC_VERSION__). Yes this leads to some very warped problems what would have been easy to detect by checking the standard version number and noticing its not a formal release version or it some version with some odd ball written error.

It is good practice to check __STDC_VERSION__ or __cplusplus, but not because of typedef. That (still) seems ridiculous.

[oiaohm]

Bad news? Funny. Why don't you link one of those intermediate drafts?

Finding the cause issue not a draft. Its C90 ISO/IEC 9899:1990

The typedef meaning has been like that since K&R, and its is in C89, C99, and C11: http://port70.net/~nsz/c/
It's been there since the beginning and it will be there 'til the end.

Yes most sites don't list C90 same with the other cursed drafts that normally starts from the mistake we will make it cover all existing standards include C90. Yes this is what goes wrong at the start of the C11 process. Hopefully this time it stays dead. Problem is there are still compilers in some distributions in usage that are still busted.

The worst cursed drafts of C standard are all based off C90. Sane drafts start of K&R, C89, C99 Yes C99 started from C89. C11 does the horrible of starting from C90.

The new C standard to follow on after C11 is starting from the final draft of C11 so starting form something saneish. As long as they don't delete anything we will be good. And as long no one starts a new C standard from C90 again.(yes guessed someone mixed up C99 and C90 at the start of C11)

As you say yourself, anything else doesn't make any sense, and if some intermediate draft forgot to mention it, I doubt any compiler changed because of that, and if it did, that would only say something about that compiler engineer.

If you follow the cases of gcc following one of those not fully approved drafts the most common cause is not a compiler engineer but a compiler maintainer.

https://blog.regehr.org/archives/268

This here is the 2010 blog has 2008 example but there have been a quite few other cases. What happens here is the distribution maintainer is cherry picking patches from the pending list and put those patches into the compiler. They see something that says makes the compiler more C90 or C11(early draft of course the person putting up the patch does not write early draft) compatible merge that patch and ruin everyone day using that distribution. Yes that 2008 patch to give more C90 compatibility for the bug in the 2010 blog there that results in 255 being smaller than 1.

Normally these patches manage to screw up the __STDC_VERSION__ values as well.

Yes first recorded time of this is 2008 with the C90 and maintainer screw up . This has been recorded with C11 12 times with gcc and its the same thing distribution maintainer merging patches the upstream has not approved yet resulting in auto conversion being wrong. Of course these problem patches are not getting approved mainline.

So yes we do have another problem here. How to get distribution maintainer not to screw up on these things? No one has a solid answer to this yet.

It is good practice to check __STDC_VERSION__ or __cplusplus, but not because of typedef. That (still) seems ridiculous.

When doing C++ it pays still to check __STDC_VERSION__ as well. Remember these parties who are merge goof ball patches don't normally screw up the __clpusplus value its only the __STDC_VERSION__ they screw up as they attempt to correct this to also match the old out of date draft they have as well. This is kind of why its very important to be checking the __STDC_VERSION__ value.

Hopefully one day we can forgot these problems exist. But not quite yet as there are distributions out there with patches pulled into their compilers that bring the bad C90 standard into the current day.

indepe Yes the reason why it gets hard to find C90 and other screwed up drafts this to hopefully reduce the number of cases of people making and submitting these screw ball patches to reducing the chances of distributions maintainers screwing up.

Yes there is a very solid reason why I am only linking to a correct draft and not linking to the incorrect ones. I am detailing the sections in the correct draft that get screwed up. We don't want to lead people to the totally incorrect drafts there odd that someone will take that incorrect draft as the 100 percent correct way and submit a patch up stream starting the are we lucky punk cycle again. But the knowledge that the stuffed up drafts exist is important and the fact distribution maintainers cherry picking compiler patches are not exactly brilliant at it.

Yes this is a two way tango between those writing incorrect patches for gcc and distribution maintainers result in ruining everyone day. In about a decade all the screwed up C11 gcc and clang compilers where this bad tango has happened should be out of use. I am crossing finger by then we don't screw the C standard draft up again this badly so starting the cycle all over again.

[indepe]

Finding the cause issue not a draft. Its C90 ISO/IEC 9899:1990

Yes most sites don't list C90 same with the other cursed drafts that normally starts from the mistake we will make it cover all existing standards include C90. Yes this is what goes wrong at the start of the C11 process. Hopefully this time it stays dead. Problem is there are still compilers in some distributions in usage that are still busted.

The worst cursed drafts of C standard are all based off C90. Sane drafts start of K&R, C89, C99 Yes C99 started from C89. C11 does the horrible of starting from C90.

So no references or quotes?

Even funnier, considering that people seem to think that C89 and C90 are the same thing, and for C89 we have already seen that typedef "does not introduce a new type":

Wikipedia: https://en.wikipedia.org/wiki/ANSI_C

C90
The same standard as C89 was ratified by the International Organization for Standardization as ISO/IEC 9899:1990, with only formatting changes, which is sometimes referred to as C90. Therefore, the terms "C89" and "C90" refer to essentially the same language.

GCC docu: https://gcc.gnu.org/onlinedocs/gcc/Standards.html

The original ANSI C standard (X3.159-1989) was ratified in 1989 and published in 1990. This standard was ratified as an ISO standard (ISO/IEC 9899:1990) later in 1990. There were no technical differences between these publications, although the sections of the ANSI standard were renumbered and became clauses in the ISO standard. The ANSI standard, but not the ISO standard, also came with a Rationale document. This standard, in both its forms, is commonly known as C89, or occasionally as C90, from the dates of ratification. To select this standard in GCC, use one of the options -ansi, -std=c90 or -std=iso9899:1990; to obtain all the diagnostics required by the standard, you should also specify -pedantic (or -pedantic-errors if you want them to be errors rather than warnings). See Options Controlling C Dialect.

The GCC docu for "Options Controlling C Dialect" describes that 'c89', 'c90', and -ansi all refer to the same dialect.
https://gcc.gnu.org/onlinedocs/gcc/C...ialect-Options

A value for this option must be provided; possible values are
‘c90’
‘c89’
‘iso9899:1990’
Support all ISO C90 programs (certain GNU extensions that conflict with ISO C90 are disabled). Same as -ansi for C code.

Some other website about some C compiler: https://downloads.ti.com/docs/esd/SP...dz0590793.html

C89. Compiling with the --c89 option causes the compiler to conform to the ISO/IEC 9899:1990 C standard, which was previously ratified as ANSI X3.159-1989. The names "C89" and "C90" refer to the same programming language. "C89" is used in this document.

[oiaohm]

So no references or quotes?

Even funnier, considering that people seem to think that C89 and C90 are the same thing, and for C89 we have already seen that typedef "does not introduce a new type":

Wikipedia: https://en.wikipedia.org/wiki/ANSI_C

C90
The same standard as C89 was ratified by the International Organization for Standardization as ISO/IEC 9899:1990, with only formatting changes, which is sometimes referred to as C90. Therefore, the terms "C89" and "C90" refer to essentially the same language.

You have in fact state the problem because people believe they are exactly the same thing when C89 and C90 are really not when you read the standard documents line for line. This here states what was meant to happen when C90 was made that it was just reformatting of C89. One problem the person doing the reformatting managed to delete 3 sentences that did not get put back(will explain this latter but a lot more was deleted first time around). 2 of those sentences are not major problems. One of the sentences is the typedef rule of never make a new type that very problematic being missing.

A compiler implemented to C89 document absolutely will pass for a C90 compiler but the reverse is not true. Yes the GNU documents still write they are the same thing. This what caused the 2008 Ubuntu compiler bug. This is also what caused the goof up at the start of the C11 process.

ISO/IEC 9899:1990 and ANSI X3.159-1989 were meant to be the same. Just the unfortunate case of having to change the ANSI documents format to be ISO documented formatting happened to be screwed up and no one notices straight away the missing pieces in fact no one directly notices for 17-18 years the last 3 missing sentences. Please note the error was noticed in 2007-2008 the missing complete sentences went unnoticed for a hell load of time.

C89 is the sane document and C90 is insane caused by minor human error. Think about it noticing that 3 sentences gone missing out of a document the size of C89 and the formatting has been changed around its quite simple why it will be missed. Yes the believe that C89 and C90 are the same thing is what cases the C11 problem in early drafts as well.

indepe it would be funny if it had not caused much trouble. When the bug was found it explained why there were so many embedded platform C compilers from the 90s had such screwed up type systems as well because they based on the ISO C90 document not the ANSI C89 one. This is basically 18 years of hell before being noticed the first time for what was the real cause. And we still have the problem people still think the two documents of C90 and C89 are in fact the same when they are minor-ally different in a horribly important way.

This is the gremlins of the standards process. ISO C90 is commonly not used as a base for most compilers.

Also to make this more fun there are 3 core versions ISO C90 documents.
ISO/IEC 9899:1990
ISO/IEC 9899:1990/Cor 1:1994
ISO/IEC 9899:1990/Cor 2:1996
Yes Cor 1 and Cor 2 are putting back other parts in the process of reformatting C89 ANSI for ISO standard formatting that were deleted by mistake. Yes the 3 missing sentences I refer to is missing out of all 3 of these ISO documents so the 2 corrections made it better but did not put everything back. Yes Cor in ISO standard is short for the word Corrigenda that basically means document correction in other words they goofed it.

C90 documents is a stack of goof up. Yes you can 2 people arguing over what C90 says and does not say and they both technically be right and wrong at the same time because they have two different versions of the C90 document.

ANSI X3.159-1989 or C89 is nice there is only 1 standard document with no goof ups.

Remember it gets worse you are meant to pay to have the ISO documents.

indepe fun right that gcc don't mention that there are 3 C90 core documents. Yes if that was mentioned I guess alarm bells would have gone straight off in your head of how can 1 document ANSI X3.159-1989 C89 in fact equal 3 different C90 documents if they are meant to be absolutely the same thing. Yes this is as about as stupid as 1 being greater than 255 because the unsigned/signed conversion has been done the wrong way.

The C90 standard documents was sent to print 3 times by ISO body to attempt to fix it. Yes this is also fun that ISO/IEC 9899:1990 the original was with drawn from sale in 1994 and the 1994 one was withdrawn from sale in 1996 because the ISO body knew how goofed they were.

So C90 original documents are cursed. Even worse in the intro prefix on all 4 versions of C90 documents state that it should be absolutely same as ANSI X3.159-1989 or C89 when the document you are holding in you hands is absolutely not the same as C89..

Yes there is a 4 version of C90 that in 1995 added a technical extra from AMD that was not a correction yes it directly based on the 1994 core version that is stuffed.

Yes if you go here https://www.iso.org/standard/17782.html you can see the existence of the broken C90 standard documents yes this link will not allow to see the source documents just that they existed. Yes the fact you have 3 C90 document that are meant to be equal 1 C89 document should really be enough proof that C90 has kind of screwed. Saying that C89 is the same as C90 gets to skip over the fact that ISO C90 documentation is totally screwed up.

[indepe]

One problem the person doing the reformatting managed to delete 3 sentences that did not get put back(will explain this latter but a lot more was deleted first time around). 2 of those sentences are not major problems. One of the sentences is the typedef rule of never make a new type that very problematic being missing.

Ah, so you actually agree with me that in theory, the typedef rule is and always was the same. Except that you say someone got confused about it.

indepe it would be funny if it had not caused much trouble.

Nah, still very funny, believe me.

[oiaohm]

Ah, so you actually agree with me that in theory, the typedef rule is and always was the same. Except that you say someone got confused about it.

Not quite. Typedef rule was always meant to be the same. Other than the fact in the reformatting C90 ISO standard they managed not to include it. Then C11 when they started the drafts started from C90 instead of C89.(yes ouch) then added rank system from C99 that depends on typedef defined to work correctly.

This is not someone getting confused this is someone goofing up a document then having 2 attempt to fix it and not fix it at ISO. Then someone else picks up the ISO C90 document/s read the intro that says it the same as C89 who does not know the typedef rule picks up that incorrect document being C90 and goes down the wrong path leading to patch that will result in compiler doing stupid thing. Yes sometimes says more conforming with C89 when breaking the typedef rule is absolutely not.

Then we have this repeated with the early drafts of C11 except this time the person screwing up is the master Author of C11 who also picks up C90 thinking its the same as C89.

Nah, still very funny, believe me.

I really do wish that C90 and C89 had really been the same for contents of the standard. C90 is the source of headaches. Yes if C90 did not exist or was never wrong then -Wsigned-compare would not need to exist for non (cast) cases. Basically this complete headache goes back C90 at ISO. 30 years later and we sill have compilers with problems from C90 mess up and people submitting patches based on the broken C90 documentation.
Stuffed up standards love refusing to die.

[indepe]

Not quite. Typedef rule was always meant to be the same. Other than the fact in the reformatting C90 ISO standard they managed not to include it. Then C11 when they started the drafts started from C90 instead of C89.(yes ouch) then added rank system from C99 that depends on typedef defined to work correctly.

This is not someone getting confused this is someone goofing up a document then having 2 attempt to fix it and not fix it at ISO. Then someone else picks up the ISO C90 document/s read the intro that says it the same as C89 who does not know the typedef rule picks up that incorrect document being C90 and goes down the wrong path leading to patch that will result in compiler doing stupid thing. Yes sometimes says more conforming with C89 when breaking the typedef rule is absolutely not.

But that's what I mean. You are saying that because of the missing sentence, "someone else" got confused about the rule, someone who didn't really understand the language enough to realize it was a mistake. And that someone thought that typedef meant something else than what it really meant and changed the compiler. And also the people who wrote C11 got confused about it. They all didn't know anymore what typedef really meant. It wasn't as obvious to them as it is to me. So I figured out that can't be right, but the first C11 standards people didn't. Because they were confused. That's what you are saying, right?