Features and standards

[David Lee]

A project which I'm involved in, which is supposed to be reasonably clsoe
to the ANSI-C standard, compiles under 'gcc' but not under Sun Studio.

There are two issues:

1. Parts of the code are handling typical network packets, comprising
header and data, so use declarations of the form:
struct pkt {
int header_thing;
int another_header_thing;
char data[0]; /* lots of data here */
};

with the idea that 'struct pkt' (and 'sizeof(struct pkt)' etc.) are aimed
at processing the header, while the code handling the (non-zero-sized)
'data' would be handed a pointer and then do its own processing. (The
associated packet 'malloc' "sizeof(struct pkt) + <length of data>", which
seems reasonably clean.)

This fails to compile under SunStudio because of the 'data[0]'. K&R
ANSI-C, section A8.6.2 seems quite clear that such failure is correct:
"if the constant expression is present, it must have integral type, and
value greater than 0".

(In other words, that 'gcc' allowing 'data[0]' seems to be a 'gcc'
extension.)

Reducing 'data[0]' to 'data[]' allows it to compile. But I can see the
attraction of 'data[0]' in clearly expressing an intention.

Q1a: Is 'data[0]' allowed by other C standards (C99, etc.)?

Q1b: In K&R ANSI-C, wehre is the meaning of the reduced 'data[]' for such
a context defined? (To confirm that "sizeof(struct pkt)" would be the
same for 'data[0]' and 'data[]'.)



2. A transfer vector of functions declared:
struct OPS ops = {
send: socket_send,
recv: socket_recv,
};

(where "OPS", "socket_send", "socket_recv", etc. are declared earlier).
Those preamble "send:" and "recv:" look strange to me. Simply removing
them allows the code to compile and run everywhere (and to warn if the
declaration and definition deviate from each other). Keeping them causes
compilation failure on SunStudio.

What C standard (if any) permits this (gcc-accepted) syntax?



Thanks in advance!

--

: David Lee I.T. Service :
: Senior Systems Programmer Computer Centre :
: UNIX Team Leader Durham University :
: South Road :
: http://www.dur.ac.uk/t.d.lee/ Durham DH1 3LE :
: Phone: +44 191 334 2752 U.K. :

 

[pete]

David Lee wrote:

Q1a: Is 'data[0]' allowed by other C standards (C99, etc.)?

You can't define a zero size object in standard C.

 

[Eric Sosman]

A project which I'm involved in, which is supposed to be reasonably clsoe
to the ANSI-C standard, compiles under 'gcc' but not under Sun Studio.

There are two issues:

1. Parts of the code are handling typical network packets, comprising
header and data, so use declarations of the form:
struct pkt {
int header_thing;
int another_header_thing;
char data[0]; /* lots of data here */
};

with the idea that 'struct pkt' (and 'sizeof(struct pkt)' etc.) are aimed
at processing the header, while the code handling the (non-zero-sized)
'data' would be handed a pointer and then do its own processing. (The
associated packet 'malloc' "sizeof(struct pkt) + <length of data>", which
seems reasonably clean.)

This is known as "the struct hack." A variation that may
be more widely compilable is to use `char data[1]' and

malloc(offsetof(struct pkt, data) + datalength)

.... but even this is not clean enough to be allowed into the
operating room during surgery.

This fails to compile under SunStudio because of the 'data[0]'. K&R
ANSI-C, section A8.6.2 seems quite clear that such failure is correct:
"if the constant expression is present, it must have integral type, and
value greater than 0".

(In other words, that 'gcc' allowing 'data[0]' seems to be a 'gcc'
extension.)

Reducing 'data[0]' to 'data[]' allows it to compile. But I can see the
attraction of 'data[0]' in clearly expressing an intention.

Q1a: Is 'data[0]' allowed by other C standards (C99, etc.)?

No.

Q1b: In K&R ANSI-C, wehre is the meaning of the reduced 'data[]' for such
a context defined? (To confirm that "sizeof(struct pkt)" would be the
same for 'data[0]' and 'data[]'.)

Don't know about K&R, but the relevant section of the
Standard is 6.7.2.1p16. The construct uses a "flexible
array member," which was introduced in the "C99" Standard.
Note that struct padding is still a concern, even though
it's not likely to arise in this particular case.

2. A transfer vector of functions declared:
struct OPS ops = {
send: socket_send,
recv: socket_recv,
};

(where "OPS", "socket_send", "socket_recv", etc. are declared earlier).
Those preamble "send:" and "recv:" look strange to me. Simply removing
them allows the code to compile and run everywhere (and to warn if the
declaration and definition deviate from each other). Keeping them causes
compilation failure on SunStudio.

What C standard (if any) permits this (gcc-accepted) syntax?

None. Are you sure this isn't a C++ thing (I'm not
acquainted with C++ myself)?

 

[Mark Bluemel]

David Lee wrote:

None. Are you sure this isn't a C++ thing (I'm not
acquainted with C++ myself)?

It's a GCC extension...

http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Designated-Inits.html#Designated-Inits

 

[Mark Bluemel]

On Tue, 11 Mar 2008 13:02:43 +0000，David Lee wrote：

A project which I'm involved in, which is supposed to be reasonably
clsoe to the ANSI-C standard, compiles under 'gcc' but not under Sun
Studio.

There are two issues:

1. Parts of the code are handling typical network packets, comprising
header and data, so use declarations of the form:
struct pkt {
int header_thing;
int another_header_thing;
char data[0]; /* lots of data here */
};

with the idea that 'struct pkt' (and 'sizeof(struct pkt)' etc.) are
aimed at processing the header, while the code handling the
(non-zero-sized) 'data' would be handed a pointer and then do its own
processing. (The associated packet 'malloc' "sizeof(struct pkt) +
<length of data>", which seems reasonably clean.)

This fails to compile under SunStudio because of the 'data[0]'. K&R
ANSI-C, section A8.6.2 seems quite clear that such failure is correct:
"if the constant expression is present, it must have integral type,
and value greater than 0".

(In other words, that 'gcc' allowing 'data[0]' seems to be a 'gcc'
extension.)

Reducing 'data[0]' to 'data[]' allows it to compile. But I can see the
attraction of 'data[0]' in clearly expressing an intention.

Q1a: Is 'data[0]' allowed by other C standards (C99, etc.)?

AFAIK, this is gcc-only.

Q1b: In K&R ANSI-C, wehre is the meaning of the reduced 'data[]' for
such a context defined? (To confirm that "sizeof(struct pkt)" would be
the same for 'data[0]' and 'data[]'.)

It should be the same. IMO, you can treat "data[]" as a standard way
of "data[0]".

2. A transfer vector of functions declared:
struct OPS ops = {
send: socket_send,
recv: socket_recv,
};

(where "OPS", "socket_send", "socket_recv", etc. are declared earlier).
Those preamble "send:" and "recv:" look strange to me. Simply removing
them allows the code to compile and run everywhere (and to warn if the
declaration and definition deviate from each other). Keeping them
causes compilation failure on SunStudio.

What C standard (if any) permits this (gcc-accepted) syntax?

Standard C

By which Wang means C99..

uses this syntax instead.

(later versions of GCC also allow this, see the page I reference
elsethread)

 

[Eric Sosman]

It's a GCC extension...

http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Designated-Inits.html#Designated-Inits

Thanks. C99 has a standardized syntax for this, but
it's not like gcc's. (And the link you provided describes
the gcc-specific syntax as "obsolete.")

 

[Stephen Sprunk]

1. Parts of the code are handling typical network packets, comprising
header and data, so use declarations of the form:
struct pkt {
int header_thing;
int another_header_thing;
char data[0]; /* lots of data here */
};

Congratulations, you've rediscovered the "struct hack".

(In other words, that 'gcc' allowing 'data[0]' seems to be a 'gcc'
extension.)

An obsolete one, according to the GCC manual. C99 officially sanctioned the
'data[]' form for the struct hack and the GCC folks adapted.

Reducing 'data[0]' to 'data[]' allows it to compile. But I can see the
attraction of 'data[0]' in clearly expressing an intention.

data[] means the size of the array is undefined. data[0] means it's of size
zero. You mean the former, not the latter, so don't lie to the compiler.
If it looks odd to you, just think about declaring a function with an array
argument:

int foo(char bar[]);

The empty brackets indicate the size of the array is unknown -- not zero.

Q1a: Is 'data[0]' allowed by other C standards (C99, etc.)?

It's not allowed by ISO C.

Q1b: In K&R ANSI-C, wehre is the meaning of the reduced 'data[]' for such
a context defined? (To confirm that "sizeof(struct pkt)" would be the
same for 'data[0]' and 'data[]'.)

ANSI C (aka C89) is the same as ISO C90. It's not legal there either. I'm
not sure about K&R C, which is pre-ANSI/ISO.

S

 

[Mark Bluemel]

struct OPS ops = {
send: socket_send,
recv: socket_recv,
}; [snip]
What C standard (if any) permits this (gcc-accepted) syntax?
Standard C

By which Wang means C99..

Yes, it should be a new feature of C99 (not check it).

(later versions of GCC also allow this, see the page I reference
elsethread)

I knew this. Here we just concern standard C, right? [/QUOTE]

Well, given that the original poster (David) is clearly using GCC for
some of his development, he may be pleased to know that if he moved to
the C99 syntax, GCC (which is not fully C99 compliant, as far as I'm
aware) will accept it.

Whether the other compiler(s) he's targetting will be C99 compliant
enough to accept this syntax, I don't know.

 

[WANG Cong]

On Tue, 11 Mar 2008 13:02:43 +0000，David Lee wrote：

A project which I'm involved in, which is supposed to be reasonably
clsoe to the ANSI-C standard, compiles under 'gcc' but not under Sun
Studio.

There are two issues:

1. Parts of the code are handling typical network packets, comprising
header and data, so use declarations of the form:
struct pkt {
int header_thing;
int another_header_thing;
char data[0]; /* lots of data here */
};

with the idea that 'struct pkt' (and 'sizeof(struct pkt)' etc.) are
aimed at processing the header, while the code handling the
(non-zero-sized) 'data' would be handed a pointer and then do its own
processing. (The associated packet 'malloc' "sizeof(struct pkt) +
<length of data>", which seems reasonably clean.)

This fails to compile under SunStudio because of the 'data[0]'. K&R
ANSI-C, section A8.6.2 seems quite clear that such failure is correct:
"if the constant expression is present, it must have integral type,
and value greater than 0".

(In other words, that 'gcc' allowing 'data[0]' seems to be a 'gcc'
extension.)

Reducing 'data[0]' to 'data[]' allows it to compile. But I can see the
attraction of 'data[0]' in clearly expressing an intention.

Q1a: Is 'data[0]' allowed by other C standards (C99, etc.)?

AFAIK, this is gcc-only.

Q1b: In K&R ANSI-C, wehre is the meaning of the reduced 'data[]' for
such a context defined? (To confirm that "sizeof(struct pkt)" would be
the same for 'data[0]' and 'data[]'.)

It should be the same. IMO, you can treat "data[]" as a standard way
of "data[0]".

2. A transfer vector of functions declared:
struct OPS ops = {
send: socket_send,
recv: socket_recv,
};

(where "OPS", "socket_send", "socket_recv", etc. are declared earlier).
Those preamble "send:" and "recv:" look strange to me. Simply removing
them allows the code to compile and run everywhere (and to warn if the
declaration and definition deviate from each other). Keeping them
causes compilation failure on SunStudio.

What C standard (if any) permits this (gcc-accepted) syntax?

Standard C uses this syntax instead.

struct OPS ops = {
.send = socket_send,
.recv = socket_recv
};

 

[WANG Cong]

On Tue, 11 Mar 2008 13:02:43 +0000，David Lee wrote：

A project which I'm involved in, which is supposed to be reasonably
clsoe to the ANSI-C standard, compiles under 'gcc' but not under Sun
Studio.

There are two issues:

1. Parts of the code are handling typical network packets, comprising
header and data, so use declarations of the form:
struct pkt {
int header_thing;
int another_header_thing;
char data[0]; /* lots of data here */
};

with the idea that 'struct pkt' (and 'sizeof(struct pkt)' etc.) are
aimed at processing the header, while the code handling the
(non-zero-sized) 'data' would be handed a pointer and then do its own
processing. (The associated packet 'malloc' "sizeof(struct pkt) +
<length of data>", which seems reasonably clean.)

This fails to compile under SunStudio because of the 'data[0]'. K&R
ANSI-C, section A8.6.2 seems quite clear that such failure is correct:
"if the constant expression is present, it must have integral type,
and value greater than 0".

(In other words, that 'gcc' allowing 'data[0]' seems to be a 'gcc'
extension.)

Reducing 'data[0]' to 'data[]' allows it to compile. But I can see
the attraction of 'data[0]' in clearly expressing an intention.

Q1a: Is 'data[0]' allowed by other C standards (C99, etc.)?

AFAIK, this is gcc-only.

Q1b: In K&R ANSI-C, wehre is the meaning of the reduced 'data[]' for
such a context defined? (To confirm that "sizeof(struct pkt)" would
be the same for 'data[0]' and 'data[]'.)

It should be the same. IMO, you can treat "data[]" as a standard way of
"data[0]".

2. A transfer vector of functions declared:
struct OPS ops = {
send: socket_send,
recv: socket_recv,
};

(where "OPS", "socket_send", "socket_recv", etc. are declared
earlier). Those preamble "send:" and "recv:" look strange to me.
Simply removing them allows the code to compile and run everywhere
(and to warn if the declaration and definition deviate from each
other). Keeping them causes compilation failure on SunStudio.

What C standard (if any) permits this (gcc-accepted) syntax?

Standard C

By which Wang means C99..[/QUOTE]

Yes, it should be a new feature of C99 (not check it).

(later versions of GCC also allow this, see the page I reference
elsethread)

I knew this. Here we just concern standard C, right?

 

[Spurious Data]

WANG Cong wrote:
struct OPS ops = {
send: socket_send,
recv: socket_recv,
}; [snip]
What C standard (if any) permits this (gcc-accepted) syntax?
Standard C
By which Wang means C99..

Yes, it should be a new feature of C99 (not check it).

I knew this. Here we just concern standard C, right?

Well, given that the original poster (David) is clearly using GCC for
some of his development, he may be pleased to know that if he moved to
the C99 syntax, GCC (which is not fully C99 compliant, as far as I'm
aware) will accept it.

Whether the other compiler(s) he's targetting will be C99 compliant
enough to accept this syntax, I don't know.

Well, not sure which version he's looking, but he can look here:
http://gcc.gnu.org/c99status.html to see what's supported.

 

[user923005]

A project which I'm involved in, which is supposed to be reasonably clsoe
to the ANSI-C standard, compiles under 'gcc' but not under Sun Studio.

There are two issues:

1. Parts of the code are handling typical network packets, comprising
header and data, so use declarations of the form:
  struct pkt {
     int header_thing;
     int another_header_thing;
     char data[0];  /* lots of data here */
  };

In the usual formation, you would see:
char data[1]; /* The usual 'struct hack' */

I have used it for skiplists {for randomly sized pointer stacks}, but
it is not strictly conforming. From the C-FAQ:

2.6: I came across some code that declared a structure like this:

struct name {
int namelen;
char namestr[1];
};

and then did some tricky allocation to make the namestr array
act like it had several elements. Is this legal or portable?

A: This technique is popular, although Dennis Ritchie has called
it
"unwarranted chumminess with the C implementation." An
official
interpretation has deemed that it is not strictly conforming
with the C Standard, although it does seem to work under all
known implementations. (Compilers which check array bounds
carefully might issue warnings.)

Another possibility is to declare the variable-size element
very
large, rather than very small; in the case of the above
example:

...
char namestr[MAXSIZE];

where MAXSIZE is larger than any name which will be stored.
However, it looks like this technique is disallowed by a
strict
interpretation of the Standard as well. Furthermore, either
of
these "chummy" structures must be used with care, since the
programmer knows more about their size than the compiler does.

C99 introduces the concept of a "flexible array member", which
allows the size of an array to be omitted if it is the last
member in a structure, thus providing a well-defined solution.

References: Rationale Sec. 3.5.4.2; C9X Sec. 6.5.2.1.

 

[David Lee]

On Tue, 11 Mar 2008 13:58:26 +0000，Mark Bluemel wrote：

WANG Cong wrote:
struct OPS ops = {
send: socket_send,
recv: socket_recv,
}; [snip]
What C standard (if any) permits this (gcc-accepted) syntax?
Standard C
By which Wang means C99..

Yes, it should be a new feature of C99 (not check it).

uses this syntax instead.
(later versions of GCC also allow this, see the page I reference
elsethread)

I knew this. Here we just concern standard C, right?

Well, given that the original poster (David) is clearly using GCC for
some of his development, he may be pleased to know that if he moved to
the C99 syntax, GCC (which is not fully C99 compliant, as far as I'm
aware) will accept it.

(Thanks for all the replies. I'll follow them up.)

To clarify:

o In practice the code has been developed primarily under 'gcc' using
ANSI-C as guidance when questions arise about portability etc.

o I'm dabbling with building it under the SunStudio (Solaris) compiler.
(More generally, my role is trying to ensure portability beyond the
Linux/gcc world, even though the major userbase by far is Linux/gcc.)

o SunStudio gave errors in the two areas described. (If our project
were truly ANSI-C, I believe these error messages are correct (our code
wrong); that is, that those two areas were extensions outside and
beyond ANSI-C.)

o Pragmatically I can see the attraction of the existing code (even
though it technically breaks ANSI-C). The people who maintain the code
prefer that attraction over the "letter of the ANSI-C law". (That can
be argued; but we are a community of different and diverse human beings
trying to rub along!)

So the question, in that context, becomes (something like):

o If we changed our "guided by ANSI-C" to (for example) "guided by C99"
would that allow us to keep the existing code (or an equivalent), but
now conforming to some recognised C standard (for example C99)?

Hope that clarifies it.

Whether the other compiler(s) he's targetting will be C99 compliant
enough to accept this syntax, I don't know.

Just about. I'm looking at portability beyond Linux/gcc, so looking for
quotations from any recognised C standards (for example C99) that could
permit the existing code (or close equivalent). Then for any potential
non-gcc compiler we could say "needs to support standard X (e.g. C99)".

(But not C++. This is C.)

--

: David Lee I.T. Service :
: Senior Systems Programmer Computer Centre :
: UNIX Team Leader Durham University :
: South Road :
: http://www.dur.ac.uk/t.d.lee/ Durham DH1 3LE :
: Phone: +44 191 334 2752 U.K. :

 

[Bart van Ingen Schenau]

To clarify:

o In practice the code has been developed primarily under 'gcc' using
ANSI-C as guidance when questions arise about portability etc.

And apparently, some GCC-isms have crept into the code.
The best way to avoid these kinds of problems is to tell the compiler
to follow the language definition.
For GCC, this can be requested with the compiler options -ansi/-
std=c89/-std=c99 (and -pedantic for stricter conformance).

o I'm dabbling with building it under the SunStudio (Solaris) compiler.
(More generally, my role is trying to ensure portability beyond the
Linux/gcc world, even though the major userbase by far is Linux/gcc.)

If you also want portability to non-POSIX platforms, you might
consider adding the Microsoft compiler to the set that the code must
work on.

o SunStudio gave errors in the two areas described. (If our project
were truly ANSI-C, I believe these error messages are correct (our code
wrong); that is, that those two areas were extensions outside and
beyond ANSI-C.)

o Pragmatically I can see the attraction of the existing code (even
though it technically breaks ANSI-C). The people who maintain the code
prefer that attraction over the "letter of the ANSI-C law". (That can
be argued; but we are a community of different and diverse human beings
trying to rub along!)

So the question, in that context, becomes (something like):

o If we changed our "guided by ANSI-C" to (for example) "guided by C99"
would that allow us to keep the existing code (or an equivalent), but
now conforming to some recognised C standard (for example C99)?

In this context, the term ANSI-C is a bit ambiguous.
There are three C standards that have been written or adopted by ANSI
and thus could be called ANSI-C.
There is the original ANSI standard from 1989 and the ISO standards
from 1990 and 1999. Both ISO standards have been adopted by ANSI and
formally superced any previous standard.

In practice, there are very few compilers that conform to the 1999
standard. GCC also does not fully conform, although it implements
large portions of it.
For this reason, I would not require C99 conformance, but rather

Hope that clarifies it.


Just about. I'm looking at portability beyond Linux/gcc, so looking for
quotations from any recognised C standards (for example C99) that could
permit the existing code (or close equivalent). Then for any potential
non-gcc compiler we could say "needs to support standard X (e.g. C99)".

Officially, there is only one C standard, the 1999 version (C99). But
this standard has not been widely implemented. The majority of
compilers still supports the C90 standard.

If you feel that the C99 features that you want/need are widely enough
supported for your purposes, you could just require that the relevant
portions of C99 are supported.

Bart v Ingen Schenau

 

[Ben Bacarisse]

To clarify:

So the question, in that context, becomes (something like):

o If we changed our "guided by ANSI-C" to (for example) "guided by C99"
would that allow us to keep the existing code (or an equivalent), but
now conforming to some recognised C standard (for example C99)?

Hope that clarifies it.


Just about. I'm looking at portability beyond Linux/gcc, so looking for
quotations from any recognised C standards (for example C99) that could
permit the existing code (or close equivalent). Then for any potential
non-gcc compiler we could say "needs to support standard X
(e.g. C99)".

So if I may clarify: the answer is "yes", you need to check that
potential compilers support that two features of C99:

(1) A "flexible array member" as the last member in a structure as
defined in section 6.7.2.1 paragraph 16. The syntax being:

struct X {
/* other members */
T last[];
};

(2) Named "designators" in initializations as defined in section 6.7.8
paragraph 7. The syntax being:

struct Y t = { .member_name = 42 };

 

[Flash Gordon]

David Lee wrote, On 12/03/08 09:26:

Just about. I'm looking at portability beyond Linux/gcc, so looking for
quotations from any recognised C standards (for example C99) that could
permit the existing code (or close equivalent). Then for any potential
non-gcc compiler we could say "needs to support standard X (e.g. C99)".

You should note that Microsoft VC++ (which does include a C compiler)
does not conform to C99.

I would suggest you isolate your non-portable constructs from the rest
of the code. Some of this can be done by pre-processor magic provided by
a header, and some by providing a library that wraps the non-portable
elements. In terms of the struct hack I am specifically thinking you
could do

#include "portability.h"
struch whatever {
...
T hackedarray[S_HACK];
}

Then depending on your target your portability.h file has one of the
following
#define S_HACK /* C99 */
#define S_HACK 0 /* Old gcc */
#define S_HACK 1 /* Neither C99 nor old gcc struct hack */

You can, of course, use conditional compilation to select which define
is active.

Some instances where you would need a library rather than just a header
include if you have good reason for using strdup, strlcpy, strlcat,
networking, graphics etc.

(But not C++. This is C.)

Good, you would be in the wrong place if it was C++

 

[CBFalconer]

.... big snip ...

To clarify:

o In practice the code has been developed primarily under 'gcc'
using ANSI-C as guidance when questions arise about portability
etc.

If you always use gcc with the -ansi -pedantic -W -Wall flags, and
get error/warning free code, the result should port anywhere. To
get C99, rather than C90, behavior replace -ansi with -std=C99.

 

[Richard Heathfield]

CBFalconer said:

If you always use gcc with the -ansi -pedantic -W -Wall flags, and
get error/warning free code, the result should port anywhere.

Sure about that?

me@here> cat foo.c
#include <stdio.h>

int main(void)
{
fflush(stdin); /* DON'T do this at home, folks! */
return 0;
}

me@here> make
gcc -W -Wall -ansi -pedantic -Wformat-nonliteral -Wcast-align
-Wpointer-arith -Wbad-function-cast -Wmissing-prototypes
-Wstrict-prototypes -Wmissing-declarations -Winline -Wundef
-Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings
-ffloat-store -O2 -g -pg -c -o foo.o foo.c
gcc -W -Wall -ansi -pedantic -Wformat-nonliteral -Wcast-align
-Wpointer-arith -Wbad-function-cast -Wmissing-prototypes
-Wstrict-prototypes -Wmissing-declarations -Winline -Wundef
-Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings
-ffloat-store -O2 -g -pg -o foo foo.o -lm

No errors, no warnings. Are you sure that the code should port anywhere?

To get C99, rather than C90, behavior replace -ansi with -std=C99.

No, gcc does *not* conform to C99, no matter what switches you use.

 

[CBFalconer]

CBFalconer said:

Sure about that?

No.

 

[Keith Thompson]

In this context, the term ANSI-C is a bit ambiguous.
There are three C standards that have been written or adopted by ANSI
and thus could be called ANSI-C.
There is the original ANSI standard from 1989 and the ISO standards
from 1990 and 1999. Both ISO standards have been adopted by ANSI and
formally superced any previous standard.

Correct. In spite of this, the term "ANSI C" is still very commonly
used to refer to the language described by the 1989 ANSI C standard or
the 1990 ISO C standard (see, for example, gcc's "-ansi" option).
This is due to historical inertia. People started talking about the
new "ANSI C", as opposed to the older "K&R C", in the late 1980s when
ANSI was still working on the standard, and the usage stuck. (Note
that the term "K&R C" is also out of date; it refers to the language
described in the first edition of Kernighan & Ritchie, which has been
superseded by the second edition, K&R2, which describes the 1989 ANSI
standard language).

Because of this, I try to avoid the term "ANSI C", and instead refer
to C89, C90, C95, or C99. (C95 is C90 plus the 1995 amendment, which
added wide character support.)

Note that the differences between the 1989 ANSI C standard and the
1990 ISO C standard are just cosmetic; they describe the same
language.

[snip]