Re: Meaning of implementation def. behaviour (was: Re: C99 IDE for windows)

Richard Heathfield wrote:
santosh said:

<snip>

3.4.4
1 unspecified behavior
use of an unspecified value, or other behavior where this
International Standard provides two or more possibilities and
imposes no further requirements on which is chosen in any instance

Okay, so let's take the classic example of unspecified behaviour -
order of evaluation. The Standard doesn't impose an ordering of any
kind, and therefore implicitly provides gazillions of possible
orderings. Implementations are free to do what they like, and don't
have to document it.

Hmm, so for this instance of unspecified behaviour the Standard omits
specifying directly one or more possibilities, and thus *all*
possibilities are implicitly specified, subject only to the constraints
and the syntax of the language. Okay, I think I get it.

3.4.1
1 implementation-defined behavior
unspecified behavior where each implementation documents how the
choice is made

By extension, here the Standard provides (possibly a subset of)
infinitely many possibilities, but requires the implementation to
document its choice. For example, for UINT_MAX the Standard requires
that it's an integer constant AND has a value that is at least 65535
AND (IIRC) is a power-of-two-less-one, but that still leaves
infinitely many possibilities.

So, in effect, an implementation must chose one particular value from a
set of values for UINT_MAX implicitly allowed by the Standard, by not
specifying one or more particular values, but simply a limit and some
related rules.

Implementations are perfectly free to
document this choice along lines such as "if the -foo switch is set,
UINT_MAX is 131071, otherwise if -bar is set it's 262143, otherwise
it's 37778931862957161709567".

Wouldn't that actually make them three different implementations, in
effect?

For iscntrl, implementations are free
to specify just about anything they like as a control character, and I
can find no prohibition on this choice being made dynamically, as long
as the rules are clearly specified (i.e. the implementation documents
how the choice is made).

But these rules themselves should remain constant for any single
invocation of the implementation. Is that right.

So by that reasoning, if I'm correct (and I don't think I am),
implementations can specify a "dynamic rule" or a set of such rules
whereby the value of the constants in limit.h can vary from one
instance of time to another, even within a single invocation of the
implementation (by which I'm including both the translation and
execution environment, and the execution of the program image too)? Is
this logic sound?

3.4
1 behavior
external appearance or action

Here "unspecified value" is not defined, as far as I can see. However
for each instance of unspecified behaviour it seems that the Standard
provides all possible courses of action and the implementation is
merely required to choose one course from this list,

But the Standard may, instead of providing all possible courses of
action, define a rule that places a constraint on the choice (or
several such rules). UINT_MAX is a good example of this. As long as
the implementation obeys those rules, it is free to use further rules
of its own, which need not be static ("the value is X") but could
instead be dynamic ("the value is a consequence of the application of
such-and-such rules with such-and-such parameters, subject to the
[normally minimal] limitations imposed by the Standard").

Okay. So unspecified behaviour essentially means that the Standard
either specifies N possibilities (where N >= 2), or specifies one or
more constraints (must they only be constraints?), which when applied
to the construct yield N possible behaviours?

But for each instance of unspecified behaviour, somehow or the other, N
forms of allowable courses of action must be derived, where N must be
two or more. Specifying just one form of behaviour (this then
becomes "defined") or not specifying any behaviour, either directly or
through constraints (undefined behaviour) is not allowed.

<snip>

In light of this interpretation (though I'm sure I've overlooked
something important somewhere),

I think you've overlooked the point that the range of possible
behaviours doesn't actually have to be written down anywhere in the
Standard for it to constitute a valid range. For example, the Standard
doesn't have to say: "The value of UINT_MAX shall be 65535 OR 131071
OR 262143 OR 524287 OR ... [snip infinitely many possibilities]..." -
and a good job too, or it would have to have infinitely many pages.

<snip>

But the forms of behaviour must be derivable, or otherwise, it would be
undefined.

So, in view of all this, how is one, as an implementor, to derive the
valid forms of behaviour for the implementation defined output for
the 'p' type specifier in printf? The final choice of the
implementation must be one from a set of 2 to N choices that the
Standard must specify literally or implicitly through it's constraints.
But what constraints can one apply to this case? Any ideas?

.

Relevant Pages

  • Re: [LONG] Re: Why code completion and early error checking are needed
    ... >> interface declarations for the Standard Libraries. ... That is a language specefication issue. ... There is a significant difference between specifying how to fully implement ... IDE support for C++ and specifying the language in such a way as to remove ...
    (comp.lang.cpp)
  • Re: Portable Generator of visual stimuli
    ... I want to be able to control maximum and minimum interval between the light signal and the total number of signals whithin a standard period of time, ... You are not asking for something that can not be constructed within reasonable price constraints. ... Maybe someone here will design it for you for free but I don't have the time. ... I'd put a pair of LEDs on a glasses frame and power them from the serial or parallel port of your laptop. ...
    (sci.electronics.basics)
  • Re: Draft standards OK for new compiler and libc?
    ... now tell me of a compiler I can use that implements your standard. ... I've read that Comeau C/C++ and Dinkum C99 are advertised as comprising ... has been superceded for 6 years now, without specifying which one, and ...
    (comp.std.c)
  • Re: DEFAULT doesnt work in COALESCE?
    ... Constraints are the standard way to do this, and really should be the way ... >> create default Zero as 0 ... >> (id tinyint not null constraint DF_Test_id default 0 ...
    (microsoft.public.sqlserver.programming)
  • Re: Order of function parameters evaluation
    ... >> void somefunc(int a, int b, int c) ... The standard doesn't talk about a "calling convention" called ... and any method for specifying such a thing is non-standard. ... that invokes undefined behavior to behave in a specified way. ...
    (comp.lang.c)