bill@twwells.uucp (T. William Wells) (12/01/88)
In article <1988Nov28.215053.3129@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: : In article <219@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: : >But it does! The standard says that which one it is compatible with : >is "implementation defined". That implies that it has to be : >documented. : : Yes, but this is not entirely inconsistent with Dennis's suggestion. Oh, I agree; I was only quibbling about the "announce in advance" part. : No; what we have here is a situation in which the legality of such a : program is implementation-defined. It is not improper to fail to translate : an illegal program. "Implementation defined" is kind of wierd here. Implementation defined behavior applies to "a correct program construct...", yet we have the logical contradiction of "implementation defined" being used to determine what a correct program construct *is*. Since this kind of thing occurs throughout the standard, I'm forced to conclude that they intended that some things can be implementation defined to be incorrect, regardless of the stated definition of "implementation defined". --- Bill {uunet|novavax}!proxftl!twwells!bill
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/02/88)
In article <229@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: -In article <1988Nov28.215053.3129@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: -: No; what we have here is a situation in which the legality of such a -: program is implementation-defined. It is not improper to fail to translate -: an illegal program. -Since this kind of thing occurs throughout the standard, I'm forced -to conclude that they intended that some things can be implementation -defined to be incorrect, regardless of the stated definition of -"implementation defined". This is a misreading of the proposed standard. "Implementation defined" does not give license to fail to translate the program. See the final Rationale document.
henry@utzoo.uucp (Henry Spencer) (12/04/88)
In article <9034@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >-: No; what we have here is a situation in which the legality of such a >-: program is implementation-defined. It is not improper to fail to translate >-: an illegal program. >-Since this kind of thing occurs throughout the standard, I'm forced >-to conclude that they intended that some things can be implementation >-defined to be incorrect, regardless of the stated definition of >-"implementation defined". > >This is a misreading of the proposed standard. "Implementation defined" >does not give license to fail to translate the program. See the final >Rationale document. Note that the Rationale is not part of the standard. However, this was sloppy terminology on my part -- I should have said "implementation-specific" or something else that doesn't have a magic meaning in the standard. My point was, it's quite possible to write programs whose legality depends on implementation-defined assumptions. The supplier is required to document the "values of" implementation-defined characteristics, and refusal to compile is not a legal "value" (but see below). However, it is quite possibly to define a program whose individual parts are legal but which in toto is illegal because of implementation-defined characteristics. Dennis's example is a typical case: int x; enum e x; If "enum e" was otherwise legally declared, the type given to x by the second line is implementation-defined, but the compiler is not allowed to refuse to compile it, in isolation. However, whether this is legal in the context of the first line depends on exactly what that type is. Also, returning for a moment to refusal to compile not being an option, the ice is thin here in places. For example, one can write something like "#include x y z" where x, y, and z are macros, and the manner in which the resulting preprocessor tokens between (e.g.) a `<' and a `>' are combined into a single header name is implementation-defined. That means the combination has to happen, somehow. However, there is no guarantee that the combination function will yield useful results. -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/05/88)
In article <1988Dec3.224807.29121@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Also, returning for a moment to refusal to compile not being an option, >the ice is thin here in places. For example, one can write something >like "#include x y z" where x, y, and z are macros, and the manner in >which the resulting preprocessor tokens between (e.g.) a `<' and a `>' are >combined into a single header name is implementation-defined. That means >the combination has to happen, somehow. However, there is no guarantee >that the combination function will yield useful results. I don't see that this example is at all on thin ice. Using the implementation definition, a definite header name must be produced, or else it is illegal syntax. The syntax for #include is spelled out. Also what happens once has a header name is spelled out. How does this differ from #include "foo" ? If no file matching the name exists, it is an incorrect program.
henry@utzoo.uucp (Henry Spencer) (12/06/88)
In article <9064@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >I don't see that this example is at all on thin ice. Using the >implementation definition, a definite header name must be produced, >or else it is illegal syntax. The syntax for #include is spelled out. >Also what happens once has a header name is spelled out.... Consider a more complete example: #define x < #define y stdio.h #define z > #include x y z Since the combination mechanism in the #include is implementation-defined, this might turn into any of the following: #include <stdio.h> #include < stdio . h > #include <\stdio\.\h> #include <forget.it> (The last is arguably unreasonable, but it is not *clear* that the standard actually forbids it.) The point is, the construct is required to be legal but is not required to be useful, which makes it pretty, uh, useless in portable programs. This is actually a bit curious, since elsewhere (the # operator, and arguably the ## operator), exact preservation of the original spelling of tokens is in fact demanded. Was there a reason why a similar demand was considered impractical or undesirable here? -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/07/88)
In article <1988Dec5.181753.1961@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > #define x < > #define y stdio.h > #define z > > #include x y z >Since the combination mechanism in the #include is implementation-defined, >this might turn into any of the following: > #include <stdio.h> > #include < stdio . h > > #include <\stdio\.\h> > #include <forget.it> >(The last is arguably unreasonable, but it is not *clear* that the standard >actually forbids it.) The point is, the construct is required to be legal >but is not required to be useful, which makes it pretty, uh, useless in >portable programs. This is actually a bit curious, since elsewhere (the ># operator, and arguably the ## operator), exact preservation of the >original spelling of tokens is in fact demanded. Was there a reason why >a similar demand was considered impractical or undesirable here? This facility (parameterization of header file names) is not meant to be used portably; in fact it is specifically a hook for porters to use to insert system-specific header file names. The basic problem is that the maximal subspace of possible file names that ALL implementations would support is so small as to be of little practical value. The mapping is intended to be "reasonable", but that is a so-called "quality of implementation" issue. A porter will have to know the specific names to supply for each target environment, which is why the implementation is required to document the mapping. Personally I'm not convinced of the necessity for this, but there were X3J11 members who deal with many exceedingly strange systems who claimed that such a facility was needed. Don't use it unless you have to.