Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!ukma!uflorida!novavax!proxftl!twwells!bill From: bill@twwells.uucp (T. William Wells) Newsgroups: comp.std.c Subject: Re: Implementation-defined Message-ID: <237@twwells.uucp> Date: 5 Dec 88 02:43:43 GMT References: <22536@watmath.waterloo.edu> Reply-To: bill@twwells.UUCP (T. William Wells) Organization: None, Ft. Lauderdale Lines: 28 In article <22536@watmath.waterloo.edu> jagardner@watmath.waterloo.edu (Jim Gardner) writes: : The important point about the term "implementation-defined" : is that it applies to *behavior*. It is used in connection : with code whose syntax and use is correct, but whose behavior : can vary from machine to machine. Right. But the point I'm making is that there are things in the standard which are called "implementation defined" which *determine* what use is correct, e.g., int x; enum foo x; Whether using `enum foo' is correct or not depends on something implementation defined: which type enum foo is compatible with. The problem seems to stem from the fact that "implementation defined" is of behavior, but the use in this case is of semantics. Again, I believe that the stated definition of "implementation defined" is incomplete; the standard frequently labels things to be implementation defined which are not behaviors. And for those things, the restrictions on "implementation defined", that the construct in question be correct and that the implementation be required to accept it, do not apply. --- Bill {uunet|novavax}!proxftl!twwells!bill