List of implementation dependent parts of C standard

[embeddedc]

Hi,

Referring to C90, is there somewhere published a list of all parts of
the standard where the behavior is not specified or implementation
dependent?

If not and I want to find all such parts I could search a pdf version
of the standard for keywords such as "implementation dependent" to
highlight the section. Can anybody suggest a complete list of such
keywords to make sure I find all the relevant sections?

Thank you.

 

[Nick Keighley]

Referring to C90, is there somewhere published a list of all parts of
the standard where the behavior is not specified or implementation
dependent?

appendices F.1 and F.3 of X3.159

 

[embeddedc]

appendices F.1 and F.3 of X3.159

Thank you for the information. It seems this document is not easy to
find. Seems ANSI no longer supply the 89 version (not surprising),
https://global.ihs.com can supply hard copy only, and I can get it in
the book "The Annotated ANSI C Standard by Herbert
Schildt". The last seems to be the best choice. Any other options?

 

[Richard Heathfield]

(e-mail address removed) said:

Seems ANSI no longer supply the 89 version (not surprising),
https://global.ihs.com can supply hard copy only, and I can get it in
the book "The Annotated ANSI C Standard by Herbert
Schildt". The last seems to be the best choice.

Provided you ignore the annotations, which are typically Schildtian, that's
the cheapest and best way to get hold of the Standard, although the book
does also contain at least one error in the text of the Standard itself.
The details are on Clive Feather's page, "The Annotated Annotated ANSI C
Standard", http://www.lysator.liu.se/c/schildt.html

 

[embeddedc]

(e-mail address removed) said:



Provided you ignore the annotations, which are typically Schildtian, that's
the cheapest and best way to get hold of the Standard, although the book
does also contain at least one error in the text of the Standard itself.
The details are on Clive Feather's page, "The Annotated Annotated ANSI C
Standard", http://www.lysator.liu.se/c/schildt.html

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

Just to check before I buy - the book contains the appendix F.1 and F.3?

 

[Richard Heathfield]

(e-mail address removed) said:

Just to check before I buy - the book contains the appendix F.1 and F.3?

Oh, good point. I have no idea. Sorry.

 

[Random832]

(e-mail address removed) said:



Provided you ignore the annotations, which are typically Schildtian, that's
the cheapest and best way to get hold of the Standard, although the book
does also contain at least one error in the text of the Standard itself.
The details are on Clive Feather's page, "The Annotated Annotated ANSI C
Standard", http://www.lysator.liu.se/c/schildt.html

Eh. Some of what that page says is a bit off.

} If main() is declared as void, I don't know of any compiler that will
} return 0. Indeed, the standard forbids it to !

The standard forbids no such thing. This is the most serious objection
I have, the rest of this post is just filler.

} if a signal can be raised within a library function (perhaps by an
} external event such as the user pressing a BREAK key), then the signal
} handler must not call that library function.

Is this really true for all library functions?

#include <signal.h>

void abrt(int) {
if(rand()%1) abort();
else _Exit(EXIT_SUCCESS); }
int main() {
signal(SIGABRT,abrt)
srand(time());
abort(); }

} There is no description of mktime and how it can be used to solve
} problems like "what day is 100 days after December 25th 1993 ?"

Is it really legal to add 100 days to a struct tm like this, or is it
just a consequence of the way common implementations work?

 

[Ben Pfaff]

} There is no description of mktime and how it can be used to solve
} problems like "what day is 100 days after December 25th 1993 ?"

Is it really legal to add 100 days to a struct tm like this, or is it
just a consequence of the way common implementations work?

It's standard behavior:

7.23.2.3 The mktime function

Synopsis

1 #include <time.h>
time_t mktime(struct tm *timeptr);

Description

2 The mktime function converts the broken-down time, expressed as
local time, in the structure pointed to by timeptr into a
calendar time value with the same encoding as that of the
values returned by the time function. The original values
of the tm_wday and tm_yday components of the structure are
ignored, and the original values of the other components are
not restricted to the ranges indicated above.267) On
successful completion, the values of the tm_wday and tm_yday
components of the structure are set appropriately, and the
other components are set to represent the specified calendar
time, but with their values forced to the ranges indicated
above; the final value of tm_mday is not set until tm_mon
and tm_year are determined.

 

[embeddedc]

Hi,

Referring to C90, is there somewhere published a list of all parts of
the standard where the behavior is not specified or implementation
dependent?

If not and I want to find all such parts I could search a pdf version
of the standard for keywords such as "implementation dependent" to
highlight the section. Can anybody suggest a complete list of such
keywords to make sure I find all the relevant sections?

Thank you.

On account that appendices F.1 and F.3 of X3.159 are not easy to come
by - changing tact a bit I explain my problem.

I want to document all parts of the standard that are not tightly
defined. I can get this information from C99, but the compiler is
likely neither 100% C99 nor 100% C89 compliant, therefore I also need
the information for the C89 standard.

Changes from C89 to C99 might have removed some of the implementation
dependent parts making C99 a subset of C89. Therefore if I only
document items relevant only C99 but the compiler is not completely C99
compliant I may miss some things.

If the parts of the standard that are implementation dependent are the
same in C89 as C99, or the C89 is a subset of those in C99 then I have
no problem - but how to prove?

Thanks for the comments so far.

 

[Keith Thompson]

Eh. Some of what that page says is a bit off.

} If main() is declared as void, I don't know of any compiler that will
} return 0. Indeed, the standard forbids it to !

The standard forbids no such thing. This is the most serious objection
I have, the rest of this post is just filler.

It depends on what you mean by "return 0". Certainly a program can
return the equivalent of an exit status of 0 to its calling
environment. But it's logically impossible for a void function to
return 0, or any other value. If main is declared as
"void main(void)", it cannot *as a function* return 0. I think that's
what Clive meant; possibly he misunderstood what Schildt meant. (My
copy of Schildt's book isn't handy, or I'd check.)

[..]

 

[Random832]

It depends on what you mean by "return 0". Certainly a program can
return the equivalent of an exit status of 0 to its calling
environment. But it's logically impossible for a void function to
return 0, or any other value. If main is declared as
"void main(void)", it cannot *as a function* return 0. I think that's
what Clive meant; possibly he misunderstood what Schildt meant. (My
copy of Schildt's book isn't handy, or I'd check.)

Implementations can make it do that, though, with appropriate warnings
where necessary.

An implementation which generated the same exact machine code for a void
function, an integer function not returning a value, and an integer
function returning 0 in all cases would, I believe, be 100% conformant.

There's certainly absolutely nothing, in the narrowest sense, preventing
any implementation from treating a main (or any other function, but
that's neither here nor there) returning void, or not returning a value
(either with return; or by reaching the closing brace pre-c99), as if it
had returned 0, which I think was part of Schildt's point.

Now, his point also seemed to be that it was _common_ to do so, which is
incorrect and dangerous, so don't think for a minute that I'm endorsing
Schildt. This is only the case anywhere in the real world in so far as
the exit status is of no importance on some (few) implementations, and
in so far as many implementations return values in a register such that
there will be _something_ in that register even if nothing was placed
there as part of a return statement, therefore not breaking code that
doesn't care what the value was.

But, as always: The standard forbids nothing in undefined cases.

 

[Chris Torek]

But, as always: The standard forbids nothing in undefined cases.

True enough.

So, for a moment, consider the following translation unit:

void foo(void) {
return 0;
}

A C compiler must issue a diagnostic for this translation unit,
because "return" with an expression is "forbidden" (to use the
target word ) in a function whose return type is "void":

6.6.6.4 The return statement

Constraints

[#1] A return statement with an expression shall not appear
in a function whose return type is void. A return statement
without an expression shall only appear in a function whose
return type is void.

(The C90 wording is slightly different, if I remember right, but
still has a constraint against "return <expr>" in a void function
like foo().)

Now, if we change "foo" to "main", the C Standard allows undefined
behavior because of "void main". As I recall, however, there was
a DR on whether undefined behavior releases a compiler from the
requirement to produce "at least one diagnostic" for a translation
unit that contains constraint violations, to which the answer was
"no, the compiler must still produce at least one diagnostic".

Since 6.6.6.4 has the quoted constraints, the translation unit:

void main(void) { return 0; }

must thus also draw a diagnostic.

I think it is not completely unreasonable to phrase "this translation
unit must draw a diagnostic" as "the C standard forbids it", although
the first phrase is better (because it is unambiguous -- the word
"forbid" is not a Technical Standard-ese Term ).

 

[Random832]

I think it is not completely unreasonable to phrase "this translation
unit must draw a diagnostic" as "the C standard forbids it", although
the first phrase is better (because it is unambiguous -- the word
"forbid" is not a Technical Standard-ese Term ).

I didn't say the standard doesn't "forbid" the code, however you define
it.

I said that it does not forbid any behavior on the part of the compiler
(except, of course, for silence, in the particular case you mentioned)

 

[Guest]

But, as always: The standard forbids nothing in undefined cases.

True enough.

So, for a moment, consider the following translation unit:

void foo(void) {
return 0;
}

A C compiler must issue a diagnostic for this translation unit,
because "return" with an expression is "forbidden" (to use the
target word ) in a function whose return type is "void":

6.6.6.4 The return statement

Constraints

[#1] A return statement with an expression shall not appear
in a function whose return type is void. A return statement
without an expression shall only appear in a function whose
return type is void.

(The C90 wording is slightly different, if I remember right, but
still has a constraint against "return <expr>" in a void function
like foo().)

Now, if we change "foo" to "main", the C Standard allows undefined
behavior because of "void main". As I recall, however, there was
a DR on whether undefined behavior releases a compiler from the
requirement to produce "at least one diagnostic" for a translation
unit that contains constraint violations, to which the answer was
"no, the compiler must still produce at least one diagnostic".

DR17 Q3, DR102 and DR105. However, that does not necessarily apply
unless a single part of the code is both undefined and a constraint
violation simultaneously.

 

[jaysome]

Just to check before I buy - the book contains the appendix F.1 and F.3?

The book contains Appendix G.1 and G.3, which are the equivalents to
your F.1 and F.3. It also contains Appendix G.2 ("Undefined
behavior"). Buy it, if you can.