Portable way to printf() a size_t instance

[Lawrence Kirby]

That sounds more like a correct program
or like a conforming program to me,
than like a strictly conforming program.

ISO/IEC ISO/IEC 9899:1999

4. Conformance
3 A program that is correct in all other aspects,
operating on correct data, containing
unspecified behavior shall be a correct program and
act in accordance with 5.1.2.3.

5 A strictly conforming program shall use only those features
of the language and library specified in this International
Standard. It shall not produce output dependent on any
unspecified, undefined, or implementation-defined behavior,
and shall not exceed any minimum implementation limit.
4)
Conforming programs may depend upon nonportable
features of a conforming implementation.

There is no requirement in para 5 that using rand() or time() would
violate. Note specifically that their return values are not
implementation-defined, unspecified or undefined.

Lawrence

 

[pete]

There is no requirement in para 5 that using rand() or time() would
violate. Note specifically that their return values are not
implementation-defined, unspecified or undefined.

Neither are they defined by the C standard.

The return value of rand seems to me to match the description
of unspecified behavior.

C99
3.4.4
1 unspecified behavior
behavior where this International Standard provides
two or more possibilities and imposes no further
requirements on which is chosen in any instance

The two or more possibilities being the return of
any int value from zero to RAND_MAX.

Does behavior need to be labeled "unspecified" in the standard
in order to be recognized as such?

 

[Lawrence Kirby]

On Wed, 15 Jun 2005 17:16:24 +0000, pete wrote:

....

The return value of rand seems to me to match the description
of unspecified behavior.

C99
3.4.4
1 unspecified behavior
behavior where this International Standard provides
two or more possibilities and imposes no further
requirements on which is chosen in any instance

The two or more possibilities being the return of
any int value from zero to RAND_MAX.

However those still fall under the single specification of a
"pseudo-randon integer". Many library function are allowed to return a
success value or a failure code. This doesnt make them unspecified.

Does behavior need to be labeled "unspecified" in the standard
in order to be recognized as such?

Yes. Clause 3 defined "Terms, Definitions and Symbols" used in the
standard. The paragraph above specifies the meaning of the term
unspecified behaviour when it appears in the standard, not conditions
where unspecified behaviour can be inferred. That is also true for the
definitions of implementation-defined behaviour and undefined behaviour
that appear in clause 3. C90 had some specification of when undefined
behaviour occurs in clause 3. Since clause 3 is about definitions of terms
this has been correctly moved to clause 4 in C99.

Annex J lists the cases of Unspecified, Implementation-defined and
undefined behaviour in the standard. While this annex is not normative I
believe it is intended to be exhaustive.

Lawrence

 

[pete]

On Wed, 15 Jun 2005 17:16:24 +0000, pete wrote:

...


However those still fall under the single specification of a
"pseudo-randon integer". Many library function are allowed to return a
success value or a failure code. This doesnt make them unspecified.


Yes. Clause 3 defined "Terms, Definitions and Symbols" used in the
standard. The paragraph above specifies the meaning of the term
unspecified behaviour when it appears in the standard, not conditions
where unspecified behaviour can be inferred. That is also true for the
definitions of implementation-defined behaviour and undefined
behaviour
that appear in clause 3. C90 had some specification of when undefined
behaviour occurs in clause 3.
Since clause 3 is about definitions of terms
this has been correctly moved to clause 4 in C99.

Annex J lists the cases of Unspecified, Implementation-defined and
undefined behaviour in the standard.
While this annex is not normative I
believe it is intended to be exhaustive.

Thank you.

 

[Keith Thompson]

On Wed, 15 Jun 2005 17:16:24 +0000, pete wrote:

...


However those still fall under the single specification of a
"pseudo-randon integer". Many library function are allowed to return a
success value or a failure code. This doesnt make them unspecified.


Yes. Clause 3 defined "Terms, Definitions and Symbols" used in the
standard. The paragraph above specifies the meaning of the term
unspecified behaviour when it appears in the standard, not conditions
where unspecified behaviour can be inferred. That is also true for the
definitions of implementation-defined behaviour and undefined behaviour
that appear in clause 3. C90 had some specification of when undefined
behaviour occurs in clause 3. Since clause 3 is about definitions of terms
this has been correctly moved to clause 4 in C99.

Annex J lists the cases of Unspecified, Implementation-defined and
undefined behaviour in the standard. While this annex is not normative I
believe it is intended to be exhaustive.

I've seen a number of cases in this newsgroup where a construct
invokes undefined behavior because the standard doesn't define its
behavior, not because it explicitly states that it invokes undefined
behavior. This is consistent with the standard's definition of the
term "undefined behavior"; it doesn't require it to be mentioned
explicitly. (Sorry, no examples spring to mind.) I wouldn't be
surprised to see the same kind of thing for unspecified behavior.

I don't have my copy of the standard handy; I'll look at the wording
more carefully later.

 

[Lawrence Kirby]

On Thu, 16 Jun 2005 19:46:17 +0000, Keith Thompson wrote:

....

********** **********


I've seen a number of cases in this newsgroup where a construct
invokes undefined behavior because the standard doesn't define its
behavior, not because it explicitly states that it invokes undefined
behavior.

Note the part of my previous response I highlight above. This happens for
undefined behaviour because the standard explicitly states that it does,
in the part I referred to. The wording (now moved to clause 4p2) is:

"If a ''shall'' or ''shall not'' requirement that appears
outside of a constraint is violated, the behavior is undefined. Undefined
behavior is otherwise indicated in this International Standard by the
words ''undefined behavior'' or by the omission of any explicit
definition of behavior. There is no difference in emphasis among these
three; they all describe ''behavior that is undefined''."

This is what defines WHEN undefined behaviour occurs, rather than defining
what the term means when it appears in the standard, which is what clause
3 does. Note specifically the "or by the omission of any explicit
definition of behavior". The standard contains no similar wording for
unspecified or implementation-defined behaviour. They only occur when
the standard explicitly says so.

This is consistent with the standard's definition of the
term "undefined behavior"; it doesn't require it to be mentioned
explicitly. (Sorry, no examples spring to mind.) I wouldn't be
surprised to see the same kind of thing for unspecified behavior.

However that is not how the standard works.

Lawrence