RE: make versionitis? (OpenBSD) QUESTION TO MAINTAINERS IMBEDD ED

[Donn Terry <donnte at microsoft dot com>]

...left EXPLICITLY as implementation defined or unspecified,
once this level of specificity is reached.  The wording, as
was, could be interpreted (given an a-priori mindset) either
way.  Often the standards don't say anything at all, which
is the same as unspecified, but as a standards writer, the
last thing I want to do is leave the possiblity that different
mindsets will lead to different conclusions about what the
standard says.  The interps committee agreed with me that
it WAS potentially ambiguous.  (If silence were always a
good thing, the careful definitions of unspecified, undefined,
and implementation defined wouldn't be needed.  But those
exist for exactly this sort of situation.)

(That is, depending on your mindset, you could read the existing
text as requiring something it didn't; maybe YOU didn't, but
others might, and the standard needs to be as clear as it possibly
can be.)

Donn

> -----Original Message-----
> From: Marc Espie [mailto:espie@quatramaran.ens.fr]
> Sent: Friday, November 10, 2000 3:38 PM
> To: Donn Terry
> Cc: gcc-bugs@gcc.gnu.org
> Subject: Re: make versionitis? (OpenBSD) QUESTION TO 
> MAINTAINERS IMBEDD
> ED
> 
> 
> On Fri, Nov 10, 2000 at 08:58:29AM -0800, Donn Terry wrote:
> > Having been involved in the standards process for quite some time,
> > the key phrase in the interpretation was "the standard does not
> > speak to the issue".  That's the code phrase for "we blew it,
> > it doesn't say, does it?".  (I've written a few of those myself.)
> > The IEEE rules are quite explicit; when the standard doesn't speak 
> > to the issue "no conformance distinction can be made".  That says
> > that implementations can do it either way (or as many ways as they
> > can invent).  It says that applications can't count on anything.  
> 
> Well, I don't even agree.
> In open standards, you often just standardize common 
> practice, and stuff
> you can't agree upon, because distinct prior art exist, is left as 
> implementation-dependent.
> 
> When I'm saying that things are crystal-clear, I mean this: 
> the standard
> does not mention it, there is evidence out there that some 
> conforming stuff
> has differing behavior: the standard doesn't mandate anything.
> 
> Note that lots of standards leave a lot of details open. This 
> does not mean
> that those standards are bad. It just means that, for 
> portability, you can't
> depend on the details. This is good. Makefiles are already 
> fairly powerful
> within the standard, and there are other features MISSING 
> from the standard
> that would be more useful than embedded variables.
>