2022-01-21 at 18:14 +0100, David Brown wrote:
> > Entirely possible, yes, since I am not checking every line of my
> > code against the ANSI/ISO 9899-1990 reference book. :)
>
> You can use "-std=c90 -Wpedantic" to give warnings on most
> non-standard code. (If you are interested, of course.)

I know, and I use, but it's still quite tolerant. Even -Wall hides a
fair number of warnings. It's why lately I don't use gcc at all and
prefer relying on clang with its very cool -Weverything.

Mateusz

2022-01-21 at 12:11 -0500, James Kuyper wrote:
> Many (most? all? - I haven't bothered to check.) of those are not gcc
> extensions, they're part of the POSIX standard library.

They are still extensions of C89 (mostly picked out from C99), hence
why I use -std=gnu89 in practice instead of the more puritan -std=c89.

Mateusz

2022-01-21 at 17:23 GMT, Scott Lurndal wrote:
> >You are of course right, but that's not really the point. Let me
> >provide one example. In C99, it is legal to declare a variable that
> >is not at the top of the scope. Fine, but *I* don't like it, as I
> >find that it encourages sloppy programming.
>
> That hasn't been my experience.
>
> In fact, there are valid arguments for moving the
> declaration closer to the use, particularly in functions
> that may exit before using an initialized declaration.
>
> Either via a basic block (stand-alone or as part of a
> conditional or looping construct) or using C++/C99 features.

If you have such need, then it is likely that your functions are really
long. Maybe there are good reasons for it, but in my experience it is
more often than not the sign of a function that would better be
exploded into more, smaller, more specialized functions. I often miss it
myself, and I see it only when I realize that I have to scroll three
screens of text to figure out what the rowcount variable is about.

Mateusz

On 1/21/22 12:28 PM, Mateusz Viste wrote:
> 2022-01-21 at 12:11 -0500, James Kuyper wrote:
>> Many (most? all? - I haven't bothered to check.) of those are not gcc
>> extensions, they're part of the POSIX standard library.
>
> They are still extensions of C89 (mostly picked out from C99), hence
> why I use -std=gnu89 in practice instead of the more puritan -std=c89.

They are not compiler extensions, because they're not associated with
the compiler, nor are they associated with C99. A fully conforming
implementation of C running on a POSIX platform should accept the
following code even when running in strict C89 mode, without relying
upon any extensions:

#define _POSIX_C_SOURCE 2
#include <stdio.h>
int main()
{ FILE * file = popen("", "");
return 0;
}

Mateusz Viste <mateusz@xyz.invalid> writes:
>2022-01-21 at 17:23 GMT, Scott Lurndal wrote:
>> >You are of course right, but that's not really the point. Let me
>> >provide one example. In C99, it is legal to declare a variable that
>> >is not at the top of the scope. Fine, but *I* don't like it, as I
>> >find that it encourages sloppy programming.
>>
>> That hasn't been my experience.
>>
>> In fact, there are valid arguments for moving the
>> declaration closer to the use, particularly in functions
>> that may exit before using an initialized declaration.
>>
>> Either via a basic block (stand-alone or as part of a
>> conditional or looping construct) or using C++/C99 features.
>
>If you have such need, then it is likely that your functions are really
>long.

What does early exit (e.g. parameter validation) have to do
with overlong functions?

2022-01-21 at 18:06 GMT, Scott Lurndal wrote:
> What does early exit (e.g. parameter validation) have to do
> with overlong functions?

What does parameter validation have to do with the position where
variables are declared?

Perhaps you could post a (very short) example of what you mean?
"function that may exit before using an initialized declaration" is
something that I handle as below, that's why I do not understand why
it's an argument for where what is declared. But show me your way
please so I can understand your point of view.

char *fn(int a) {
char *res = NULL;

if (a < 1) goto GAMEOVER;
res = malloc(a);
if (res == NULL) goto GAMEOVER;

return(res);

GAMEOVER:
free(res);
return(NULL);
}

Mateusz

Mateusz Viste <mateusz@xyz.invalid> writes:
>2022-01-21 at 18:06 GMT, Scott Lurndal wrote:
>> What does early exit (e.g. parameter validation) have to do
>> with overlong functions?
>
>What does parameter validation have to do with the position where
>variables are declared?
>
>Perhaps you could post a (very short) example of what you mean?
>"function that may exit before using an initialized declaration" is
>something that I handle as below, that's why I do not understand why
>it's an argument for where what is declared. But show me your way
>please so I can understand your point of view.
>
>char *fn(int a) {
> char *res = NULL;
>
> if (a < 1) goto GAMEOVER;

So the initialization of res executes unnecessary instructions
to zero 8 bytes on the stack. Moving the declaration after the if statement
reduces the instruction count in that path. In certain functions, that can
make a difference in performance.

I once believed as you do, but the benefits of placing the
declaration closer to the use has many benefits and few
downsides.

And I've seen some pretty long functions that are not easily
amenable to factorization into smaller functions for structural
or performance reasons.

On 21/01/2022 18:25, Mateusz Viste wrote:
> 2022-01-21 at 18:14 +0100, David Brown wrote:
>>> Entirely possible, yes, since I am not checking every line of my
>>> code against the ANSI/ISO 9899-1990 reference book. :)
>>
>> You can use "-std=c90 -Wpedantic" to give warnings on most
>> non-standard code. (If you are interested, of course.)
>
> I know, and I use, but it's still quite tolerant. Even -Wall hides a
> fair number of warnings. It's why lately I don't use gcc at all and
> prefer relying on clang with its very cool -Weverything.
>

"-Wall" does not "hide" any warnings - it enables warnings. The name is
a bit of a misnomer - if you think of it as "enable warnings that all
reasonable code will pass without complaint", you have a better view
than if you think it enables all warnings. Remember, gcc is used as a
system compiler on many OS's, and has to strike a balance between
complaint-free compilation of existing (perhaps decades old) code that
has been used successfully with old compiler versions, and giving
helpful feedback to developers to aid them write correct code.

"-Wextra" enables many more warnings - with most developers disagreeing
about some of the warnings, but not agreeing on which ones they disagree
about. So expect some fine-tuning to suit your particular preferences
and needs. (For my own use, I start with "-Wall -Wextra" and have a
number of other options that I enable or disable.)

"-Wpedantic" is more specific - it attempts to be strict about warning
on anything that the C standards say should have a diagnostic, as well
as the use of any gcc extensions (if you have picked a non-extended
standard).

You might also like "-Wc90-c99-compat", which will warn about using
anything from C99 that was not in C90.

(No warning system is ever 100% free from false positives or false
negatives.)

clang's "-Weverything", as I understand it, was never intended to be
useful with real code. It is primarily for testing purposes.

Mateusz Viste <mateusz@xyz.invalid> writes:

> 2022-01-21 at 18:06 GMT, Scott Lurndal wrote:
>> What does early exit (e.g. parameter validation) have to do
>> with overlong functions?
>
> What does parameter validation have to do with the position where
> variables are declared?
>
> Perhaps you could post a (very short) example of what you mean?
> "function that may exit before using an initialized declaration" is
> something that I handle as below, that's why I do not understand why
> it's an argument for where what is declared. But show me your way
> please so I can understand your point of view.
>
> char *fn(int a) {
> char *res = NULL;
>
> if (a < 1) goto GAMEOVER;
> res = malloc(a);
> if (res == NULL) goto GAMEOVER;
>
> return(res);
>
> GAMEOVER:
> free(res);
> return(NULL);
> }

As is so often the case with made-up examples, this raises more
questions than it answers. fn seems to me to be this:

char *fn(int a) {
if (a > 0)
return malloc(a);
return 0;
}

or, as I'd write it,

char *fn(int a) { return a > 0 ? malloc(a) : 0; }

Maybe there was some implied use of res before returning, so the
variable would be needed:

char *fn(int a) {
if (a > 0) {
char *res = malloc(a);
if (res) {
/* make use of res here before returning */
return res;
}
}
return 0;
}

but again, no need to initialise res anywhere but at the start of a
block.

Avoiding C99 mixed declarations and statements will, sometimes, require
an object to be initialised where it would not otherwise need to be, but
this code is not an example of that.

--
Ben.

2022-01-21 at 20:53 +0100, David Brown wrote:
> "-Wall" does not "hide" any warnings - it enables warnings.

Yes, but not "all" of them. Some (many!) are still hidden. And I
understand the reasons, I just do not agree with them.

> clang's "-Weverything", as I understand it, was never intended to be
> useful with real code. It is primarily for testing purposes.

Perhaps, nonetheless *I* use it extensively in "real" code and I'm very
happy with it. Of course I do have to disable a few annoying warnings
sometimes (like the one about struct padding), but I prefer enabling all
and hand-pick what to ignore, rather than enabling a vague set of
defaults and then wonder what possibly I am missing.

The advantage of -Weverything is that when I upgrade clang, I get all
the newly added cool warnings immediately, without the need to study
clang's changelog in the matter. If I don't like the new additions - no
problem, I can easily disable them.

> You might also like "-Wc90-c99-compat", which will warn about using
> anything from C99 that was not in C90.

Sounds nice, sadly clang does not know it.

Mateusz

scott@slp53.sl.home (Scott Lurndal) writes:

> [...] I've seen some pretty long functions that are not easily
> amenable to factorization into smaller functions for structural
> or performance reasons.

Can you post an example or two of those? Ideally one of each, one
where structure impedes refactoring and one where performance
impedes refactoring.

Mateusz Viste <mateusz@xyz.invalid> writes:

I'm responding in several parts to help keep the various
aspects separate.

> 2022-01-21 at 05:51 -0800, Tim Rentsch wrote:
>
>> I'm curious to know what extensions, if any, from the gnu
>> additions you make use of.
>
> That's an interesting question that I was unable to answer from the top
> of my head. It has been so long that I code in gnu89 that I wasn't able
> to tell what exactly is non-vanilla-C89 in the set of C features I use.
> To answer your question I took a couple of my projects and switched
> them from -std=gnu89 to -std=c89 to identify the gnu89 extensions that
> I use. [.. list to be addressed in subsequent followup ..]

That was interesting, thank you. Can I ask you to repeat the
experiment with -std=c89 -pedantic-errors (and no other warnings
or errors enabled) to see if that yields any additional items?
Also if it isn't too much bother, with -std=c99 -pedantic-errors.
I am most curious to see if anything else turns up (in either
of the tests).

Mateusz Viste <mateusz@xyz.invalid> writes:

(Again I am responding in several parts to help keep the various
aspects separate.)

> 2022-01-21 at 05:51 -0800, Tim Rentsch wrote:
>
>> Also, I'm curious to know what extensions, if any, from the gnu
>> additions you make use of.
>
> [...] Here is [what was found]:
>
> __uint128_t (also uint64_t / uint32_t / uint8_t but it seems gcc
> tolerates those even in c89 mode, as long as stdint.h is included)
> struct timeval
> struct timespec
> DT_DIR / DT_REG
> PATH_MAX
>
> clock_gettime() / CLOCK_MONOTONIC
> select() / fd_set / FD_SET() / FD_ZERO() / FD_ISSET()
> strcasecmp()
> getaddrinfo() / freeaddrinfo() / struct addrinfo / gai_strerror()
> inet_aton()
> mrand48()
> snprintf() / vsnprintf()
> strdup()
> realpath()
> chroot()
> fileno()
> popen() / pclose()
> setenv() / unsetenv()
> vsyslog()

I think almost all of these can be made available, and fairly
easily, without having to resort to -std=gnuXX or general use of
any #defines of _XOPEN_SOURCE or similar symbols.

My usual practice is to put POSIX-related interfaces in a separate
file (eg, posix.h and posix.c), with only posix.c turning on any
needed extra functionality by using #define _XOPEN_SOURCE or
whatever.

Most of the interfaces listed above can be made available directly
through a posix.h header and used in standard-conforming C code. I
had no trouble making such a header for things like strdup, chroot,
setenv, and almost all the rest.

The macros for numeric constants cannot be supplied directly but
it isn't difficult to work around that aspect in various ways.

The various struct types can be used but only in pointer form
rather than directly. It's easy to work around that, if perhaps
somewhat tedious, by providing an abstract interface for those
types in posix.h (and posix.c implementing it).

The one problem child is select() and friends. My suggestion
there is to make a slightly higher level interface and used
that rather than using select() directly.

The motivation for doing all this is to get a program that is
almost exclusively purely standard conforming. The big problem
with using magic #defines or -std=gnuXX is like the proverbial
saying about a box of chocolates: you never know what you're
going to get. Worse, it can and sometimes does change between
different compiler releases. Localizing all that stuff to a
single .c file reduces the surface area of exposure and also
makes it easy to identify what non-standard interfaces are
being used and where.

2022-01-21 at 17:32 -0800, Tim Rentsch wrote:
> That was interesting, thank you. Can I ask you to repeat the
> experiment with -std=c89 -pedantic-errors

In fact that was the case already, albeit I use -pedantic in lieu of
-pedantic-errors to avoid stopping early if possible.

> Also if it isn't too much bother, with -std=c99 -pedantic-errors.

I didn't see any new errors. There was a lot less errors/warnings
overall, which is not surprising since c99 brings some of the
extensions present in gnu89. The fact that there was less warnings made
me spot two that I hadn't noticed earlier (although they are present
in both -c89 and -c99):

DT_LNK
initgroups()

So to answer your question: no, -c99 did not result in any new errors
compared to -c89. I wonder, though - why did you think it could? Isn't
c99 a superset of c89? The only possible reason I see is that when
compiling in -c89, make could abort earlier since it will stop at the
first module file in error, hence some of the C files won't even be
looked at. Is that what you thought about?

Mateusz

On 21/01/2022 22:22, Mateusz Viste wrote:
> 2022-01-21 at 20:53 +0100, David Brown wrote:
>> "-Wall" does not "hide" any warnings - it enables warnings.
>
> Yes, but not "all" of them. Some (many!) are still hidden. And I
> understand the reasons, I just do not agree with them.
>
>> clang's "-Weverything", as I understand it, was never intended to be
>> useful with real code. It is primarily for testing purposes.
>
> Perhaps, nonetheless *I* use it extensively in "real" code and I'm very
> happy with it. Of course I do have to disable a few annoying warnings
> sometimes (like the one about struct padding), but I prefer enabling all
> and hand-pick what to ignore, rather than enabling a vague set of
> defaults and then wonder what possibly I am missing.
>
> The advantage of -Weverything is that when I upgrade clang, I get all
> the newly added cool warnings immediately, without the need to study
> clang's changelog in the matter. If I don't like the new additions - no
> problem, I can easily disable them.

You seem to imagine that compiler warnings invariably indicate a
problem, and that disabling (or not enabling) a warning hides errors in
your code. That is simply not true.

Some warnings cover things that are very probably a mistake. And some
handle things that were allowed in older C standards but are no longer
acceptable according to current standards - but the compiler by default
accepts them for convenience of using old code.

Others, however, are very much a matter of style and preference,
according to the needs of the programmer and the code. I, for example,
/do/ enable "-Wpadded" for my own code - but I do not expect the
majority of other users to want it.

I am a big fan of warning flags and static error checking in general.
But blinding saying "enable everything" is no more helpful than blindly
disabling everything. Either you have to write convoluted and strange
code to avoid tripping any warnings, or your compiler output will be
swamped with warning messages that don't indicate a real problem.

The situation gets even worse if you use more powerful third-party
linters without understanding them and picking the features and warnings
that make sense for your usage.

>
>> You might also like "-Wc90-c99-compat", which will warn about using
>> anything from C99 that was not in C90.
>
> Sounds nice, sadly clang does not know it.
>

clang and gcc each have their pros and cons.

2022-01-22 at 13:05 +0100, David Brown wrote:
> You seem to imagine that compiler warnings invariably indicate a
> problem, and that disabling (or not enabling) a warning hides errors
> in your code. That is simply not true.

You are mistaken, I'm not imagining anything. I use -Weverything
because I like that the compiler warns me about things that he finds
odd. Sometimes it's an annoyance, but then it's easy to shut it by
instructing him not to check this specific warning. Other times it helps
finding a bug that would otherwise require a human to track it down.
Recent example: I got a warning about a shadowed variable (and it was
indeed a mistake). This warning is not present in -Wall nor -Wextra.

> Others, however, are very much a matter of style and preference,
> according to the needs of the programmer and the code. I, for
> example, /do/ enable "-Wpadded" for my own code - but I do not expect
> the majority of other users to want it.

That is definitely *not* a matter of style or preference. There are
situations where automatic struct padding is harmful, typically when
using said struct to communicate with other implementations. Such
padding might not occur on one compiler or architecture, but occurs on
another. Warning about that in this context is very much helpful.
Majority of my code does not rely on exact struct size and alignment,
hence for these scenarios I disable this check. But again - it's not at
all about style, it's strictly about what the structs are to be used
for, and this is something the compiler cannot guess.

> But blinding saying "enable everything" is no more helpful than
> blindly disabling everything.

I don't think that I ever said that I "blindly enable everything".

Mateusz

On 1/22/22 7:53 AM, Mateusz Viste wrote:
> 2022-01-22 at 13:05 +0100, David Brown wrote:
>> You seem to imagine that compiler warnings invariably indicate a
>> problem, and that disabling (or not enabling) a warning hides errors
>> in your code. That is simply not true.
>
> You are mistaken, I'm not imagining anything. I use -Weverything
> because I like that the compiler warns me about things that he finds
> odd. Sometimes it's an annoyance, but then it's easy to shut it by
> instructing him not to check this specific warning. Other times it helps
> finding a bug that would otherwise require a human to track it down.
> Recent example: I got a warning about a shadowed variable (and it was
> indeed a mistake). This warning is not present in -Wall nor -Wextra.
>
>> Others, however, are very much a matter of style and preference,
>> according to the needs of the programmer and the code. I, for
>> example, /do/ enable "-Wpadded" for my own code - but I do not expect
>> the majority of other users to want it.
>
> That is definitely *not* a matter of style or preference. There are
> situations where automatic struct padding is harmful, typically when
> using said struct to communicate with other implementations. Such
> padding might not occur on one compiler or architecture, but occurs on
> another. Warning about that in this context is very much helpful.
> Majority of my code does not rely on exact struct size and alignment,
> hence for these scenarios I disable this check. But again - it's not at
> all about style, it's strictly about what the structs are to be used
> for, and this is something the compiler cannot guess.
>
>> But blinding saying "enable everything" is no more helpful than
>> blindly disabling everything.
>
> I don't think that I ever said that I "blindly enable everything".
>
>
> Mateusz
>

That one may not be, but there are some that are purely stylistic, and
different implementations enforce different styles.

One big class is 'redundant' parentheses. Some implementations consider
some operations to have 'unnatural' precedence, and will advise adding
parentheses to make that explicit, while others will warn that those
parentheses aren't needed and are just redundant.

2022-01-22 at 08:31 -0500, Richard Damon wrote:
> One big class is 'redundant' parentheses. Some implementations
> consider some operations to have 'unnatural' precedence, and will
> advise adding parentheses to make that explicit, while others will
> warn that those parentheses aren't needed and are just redundant.

Yes, I know those and they are indeed about style, or even "code
religion". In the same register are the warnings about fall-through
case statements in a switch (I do not disable these warnings, though, as
95% of my switches are meant NOT to fall-through, and for the rest of
cases I write a proper comment next to it so clang is happy - and I
find it's actually a very good practice).

Anyway - yes, you are right, but David chose a very unfortunate example
and I was responding specifically to that.

Mateusz

On 22/01/2022 15:53, Mateusz Viste wrote:
> 2022-01-22 at 08:31 -0500, Richard Damon wrote:
>> One big class is 'redundant' parentheses. Some implementations
>> consider some operations to have 'unnatural' precedence, and will
>> advise adding parentheses to make that explicit, while others will
>> warn that those parentheses aren't needed and are just redundant.
>
> Yes, I know those and they are indeed about style, or even "code
> religion". In the same register are the warnings about fall-through
> case statements in a switch (I do not disable these warnings, though, as
> 95% of my switches are meant NOT to fall-through, and for the rest of
> cases I write a proper comment next to it so clang is happy - and I
> find it's actually a very good practice).
>
> Anyway - yes, you are right, but David chose a very unfortunate example
> and I was responding specifically to that.
>

The choice of whether or not you want a warning on extra padding on
structs is a matter of style and the type of code you are writing.

Yes, sometimes it matters if there is unexpected padding in your
structs. Yes, sometimes it does /not/ matter. Neither situation
/requires/ the warning, and neither requires that the warning is disabled.

If you need to be sure of that a struct is the size you expect and need,
you can add padding manually and use _Static_assert (or a macro-based
alternative for older C standards) to check the size at compile-time.
Some care is always needed if the code must be portable, as type sizes
and alignments may vary according to the target.

If you don't care about the padding and find that the warning is being
triggered, you can still add the padding manually, or ignore the
warning, or disable it temporarily. (gcc and clang have pragmas for that.)

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> [...] I've seen some pretty long functions that are not easily
>> amenable to factorization into smaller functions for structural
>> or performance reasons.
>
>Can you post an example or two of those? Ideally one of each, one
>where structure impedes refactoring and one where performance
>impedes refactoring.

Probably not without violating various non-disclosure or employment
agreements. In most cases, they were in bare-metal performance
critical code (operating systems, hypervisors) in C and C++.

One in particular is the code to handle page table walks in
an ARM64 processor simulator. Another was handling the fork()
system call in a unix-derived MPP operating system. Both in C++.

See, for example, the pseudocode for AArch64.S1Translate in
ARM's DDI0487G_b on page J1-8110.

The C++ version of that is templated to handle both S1 and S2 table walks.

Mateusz Viste <mateusz@xyz.invalid> writes:

> 2022-01-21 at 17:32 -0800, Tim Rentsch wrote:
>
>> That was interesting, thank you. Can I ask you to repeat the
>> experiment with -std=c89 -pedantic-errors
>
> In fact that was the case already, albeit I use -pedantic in lieu of
> -pedantic-errors to avoid stopping early if possible.
>
>> Also if it isn't too much bother, with -std=c99 -pedantic-errors.
>
> I didn't see any new errors. There was a lot less errors/warnings
> overall, which is not surprising since c99 brings some of the
> extensions present in gnu89. The fact that there was less warnings made
> me spot two that I hadn't noticed earlier (although they are present
> in both -c89 and -c99):
>
> DT_LNK
> initgroups()

Both of these are amenable to the posix.h scheme I mentioned in
my earlier posting. Also, after a bit more investigation, I
discovered select() is not the problem I thought it was; an
interface for select() can be provided in the same way as the other
functions, including FD_CLR etc (although for clients these will
be function calls rather than macros).

> So to answer your question: no, -c99 did not result in any new errors
> compared to -c89. I wonder, though - why did you think it could? Isn't
> c99 a superset of c89? [...]

My question was mostly about whether -pedantic would add anything.
However, there are constructs that are legal in C89/C90 but in C99
are constraint violations. There aren't many of these, and mostly
I expect they would not come up, but I thought it worth asking the
question.

> The only possible reason I see is that when
> compiling in -c89, make could abort earlier since it will stop at the
> first module file in error, hence some of the C files won't even be
> looked at. Is that what you thought about?

No, I was unconsciously assuming that you would manage your
build process well enough so that there wouldn't be any
problems along these lines.

Richard Damon <Richard@Damon-Family.org> writes:

[regarding various warning options and program style]

> That one may not be, but there are some that are purely stylistic,
> and different implementations enforce different styles.
>
> One big class is 'redundant' parentheses. Some implementations
> consider some operations to have 'unnatural' precedence, and will
> advise adding parentheses to make that explicit, while others will
> warn that those parentheses aren't needed and are just redundant.

Personally I would like to see a compiler option that warns
in /all/ cases of redundant parentheses.

Mateusz Viste <mateusz@xyz.invalid> writes:

(Again I am responding in several parts to help keep the various
aspects separate. This posting is the last of three.)

> 2022-01-21 at 05:51 -0800, Tim Rentsch wrote:
>
>> Can you say what you think the downside is of using C99? If
>> there are parts of C99 you don't like you can always just not
>> use them.
>
> You are of course right, but that's not really the point. Let me
> provide one example. In C99, it is legal to declare a variable that
> is not at the top of the scope. Fine, but *I* don't like it, as I
> find that it encourages sloppy programming. If I'm allowed to use
> something and it appears to be easier on the short term, I will most
> probably abuse it. Yes, I am a feeble human. C89 is a way to keep
> my laziness in check: all variables have to be at the top of the
> scope so I can see them upfront. If it starts to be messy, then it
> is because my scope needs to be refactored.

I share your distaste for mixing declarations and code, including
the part about sometimes being tempted to use it. Despite that,
I find C99 a non-trivial improvement over C89/C90. There are a
few constructs (not many, just a few) that are legal in C89/C90
(mainly for historical reasons) but require warnings in C99, and
that's good. Beyond that, C99 has compound literals, designated
initializers, more liberal rules for initializing structs and
arrays, // comments, long long integer types, and a variety of
other useful additions. Yes I know you can get some of these
under -std=gnu89, but then you get all sorts of other stuff that
is unknown and purely under the whim of GNU or clang or whoever.
I've been bitten in the past by letting in these extra and
unknown options, and it caused some difficulties. These days my
C code is strictly limited to standard-conforming code unless
there is a specific deliberate exception, and those are always
restricted to as narrow a scope as feasible. For me the benefit
of not allowing any non-standard functionality in the code
definitely outweighs the inconvenience of being tempted to use
intra-code declarations.

To be explicit the above is not meant as an argument to convince
you. I am however interested in whatever reactions you might
have.

> That's only one simple example, but I hope it conveys the larger
> idea.

I have looked through the list of changes between C90 and C99 and
don't see anything else that looks objectionable. Can I ask you
to provide a more comprehensive list? I really am at a loss to
know what sorts of things you wouldn't like and also would be
tempted to use.

On 1/22/22 03:57, Mateusz Viste wrote:
....
> So to answer your question: no, -c99 did not result in any new errors
> compared to -c89. I wonder, though - why did you think it could? Isn't
> c99 a superset of c89?

No. It come close, but there were several changes that could negatively
affect strictly conforming C89 code:

* Removal of implicit int.
* In C89, it was implementation-defined whether integer division rounded
toward 0 or toward negative infinity; in C90, it's required to round
toward 0.
* // comments can change the interpretation of certain unlikely
combinations, that were previously used as a way of detecting whether
you were translating the code as C or as C++:
* New rules for the types of integer constants and the integer
promotions can change the results of certain expressions.
* return without expression not permitted in function that returns a
value (and vice versa)'
* 'restrict' used to be an unreserved name, and as such could be used in
user code. Now it's a keyword.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 1/22/22 03:57, Mateusz Viste wrote:
> ...
>
>> So to answer your question: no, -c99 did not result in any new errors
>> compared to -c89. I wonder, though - why did you think it could? Isn't
>> c99 a superset of c89?
>
> No. It come close, but there were several changes that could negatively
> affect strictly conforming C89 code:
>
> * Removal of implicit int.
> * In C89, it was implementation-defined whether integer division rounded
> toward 0 or toward negative infinity; in C90, it's required to round
> toward 0.
> * // comments can change the interpretation of certain unlikely
> combinations, that were previously used as a way of detecting whether
> you were translating the code as C or as C++:
> * New rules for the types of integer constants and the integer
> promotions can change the results of certain expressions.
> * return without expression not permitted in function that returns a
> value (and vice versa)'
> * 'restrict' used to be an unreserved name, and as such could be used in
> user code. Now it's a keyword.

Good list.

In addition, C89/C90 allows implicit function declaration, but
C99 does not. Also, in C99 'inline' is a keyword, but was not
in C89/C90.