From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,PLING_QUERY, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fdb77,4873305131bf4d94 X-Google-Attributes: gidfdb77,public X-Google-Thread: 1014db,4873305131bf4d94 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,4873305131bf4d94 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,4873305131bf4d94 X-Google-Attributes: gid103376,public From: fred@genesis.demon.co.uk (Lawrence Kirby) Subject: Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Date: 1997/11/16 Message-ID: <879713346snz@genesis.demon.co.uk> X-Deja-AN: 290001122 References: <879381995snz@genesis.demon.co.uk> X-Mail2News-User: fred@genesis.demon.co.uk X-Complaints-To: abuse@demon.net X-Mail2News-Path: genesis.demon.co.uk X-Trace: mail2news.demon.co.uk 879725646 16791 fred genesis.demon.co.uk Organization: none Reply-To: fred@genesis.demon.co.uk Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.java.advocacy Date: 1997-11-16T00:00:00+00:00 List-Id: In article Dan.Pop@cern.ch "Dan Pop" writes: >In <879381995snz@genesis.demon.co.uk> fred@genesis.demon.co.uk (Lawrence Kirby) > writes: > >>In article Dan.Pop@cern.ch "Dan Pop" writes: >> >>... >> >>>Nope, it cannot. The behaviour of rand() is unspecified. >> >>Show me where the standard says that. If the standard doesn't say explicitly >>that rand() has unspecified behaviour then it doesn't, as far as the >>standard's meaning of the term "unspecified" is concerned. Annex G.1, >>barring errors, lists all cases of unspecified behaviour in the standard. > >Show me where the standard specifies the behaviour of rand(), so that I >can predict the output of the following program without having to compile >and run it: > > #include > #incldue > > int main() > { > printf("%d\n", rand()); > return 0; > } > >If I can't do that, then the program is not strictly conforming. Sorry, you've lost me there. Where does the standard say that the output of a program has to be predictable for it to be strictly conforming? Clause 4 certaintly doesn't say anything like "A strictly conforming program shall not produce output dependent on anything that is not fully specified in this International Standard". What it says is: "A strictly conforming 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 behaviour, and shall not exceed any minimum implementation limit." >Furthermore, even if I read the implementation's documentation, there is >still no guarantee that I can predict the output. True, but not relevant. There is a potential issue relating to the value of RAND_MAX. If this was implementation-defined or unspecified then there would be a reasonable argument that your example is not strictly comforming. However I can't find anything in the standard that makes it either of these. >>>Also code using >>>floating point arithmetic or most of the functions from cannot >>>be strictly conforming. >> >>That is trickier since the output may depend on implementation-defined >>defined aspects, notably the properties of the floating point types >>specified in 5.2.4.2.2. 6.1.2.5 makes the representation of floating >>point types unspecified but I don't see anything else about them that is. >>However floating point is a mess, it is difficult to predict anything >>for certain. > >You can't even predict the result of 1.0 + 1.0 based on the text of the >standard. But, again, predictability isn't a property that the standard ascribes to a strictly conforming program. I'm not quite sure where this idea comes from. Maybe it is a feeling that strict conformance gives maximal portability and in some sense maximal portability suggests precisely reproducible results. That is a false correspondance as far as the standard is concerned. (as an aside I think I could put forward a reasonable proof that 1.0 + 1.0 is predictable, but don't lose sight of the fact that it is the program output, not individual calculations that is the measure of strict conformance). >>>>>It is unspecified (or maybe implementation-defined) when an I/O operation >>>>>fails and if that failure affects the behaviour of your program... >>>> >>>>No, it isn't. The standard states explicitly all cases of unspecified and >>>>implementation-defined behaviour, these terms are very specific. >>>>Only undefined behaviour can result from a lack of definition, and even >>>>then only from a *total* lack of definition (or there is a defect in the >>>>standard). getc() (for example) has no unspecified and no >>>>implementation-defined behaviour (*). >>> >>>You missed the point. >> >>No, this is the point. >> >>> It is undefined when the well defined conditions >>>that lead to the failure of a stdio function occur. >> >>Again, you are using your own definition of a term, not the standard's. >>3.16 describes what undefined behaviour is and when it can occur. The >>situation you describe doesn't fit that description. > >Where did I used the term "undefined behaviour"??? I had to assume that otherwise what you wrote had no relevance to the issue of strict conformance. >>Simply knowing a program is strictly conforming does not mean you can >>predict what it will output. > >Then, it is not strictly conforming. They you have a different definition of what the term "strictly conforming" means compared to the one I see in the standard. These are the full requirements for strict conformance as I see them in the standard: 1. Each translation unit that makes up a program has valid syntax. 2. There are no constraint violations in the program. 3. The program must not exceed any minimum translation limit 4. The program must use only the features of the language and library specified in the standard (I include this since it is specified but it may not add anything not covered by the next 3 requirements, however it is perhaps what gives requirements 1 and 2 the force of strict conformance). 5. The program must not produce output dependent on implementation-defined behaviour. Note that implementation-defined behaviour only exists when there is an explicit requirement in the standard for the implementation to document the behaviour. (3.10) 6. The program must not produce output dependent on unspecified behaviour. Note that unspecified behaviour can only exist where it is stated explicitly in the standard. This is perhaps the most critical point: see the definition of unspecified behaviour in 3.17, particularly the word "explicitly"). 7. The program must not produce output dependent on undefined behaviour. (3.16). The important point here is that while undefined behaviour can exist through a lack of definition, it must be a *total* lack of definition i.e. "for which this standard imposes *no* requirements" (my emphasis). While not normative Annex G is a good reference for this (as well as 5 and 6) with perhaps some further indication of intent. There are separate requirements for conforming implementations but these aren't an issue here. I assert that any program that meets the 7 requirements above is strictly conforming, since these are the only requirements I can find in the standard. >>However if you do know what input a >>strictly conforming program receives you should be able to predict from >>the standard alone what output it generates (although I'm not 100% sure of >>that). From this perspective values returned by rand(), for example, are >>input to the program. > >Chapter and verse, please. According to ANSI Classic 1.2: > > 1.2 SCOPE > > This Standard specifies: > ... > * the representation of input data to be processed by C programs; > ... > >So, if the values of rand are input to the program, the standard must >specify that. As far as I can tell, rand() is not described in the >INPUT/OUTPUT section of the library :-) Whether you choose to treat the values returned by rand() as input to the program or not doesn't affect any of the 7 requirements above so we shouldn't get stuck on this point. I think it is reasonable and useful to consider it as input to the program. >The wording of the standard clearly suggests that ALL the program input >data come from streams, via the stdio functions (it doesn't even include >the getenv() function as a source of program input). If you disagree, >please provide the relevant quotes. OK, if you don't like the term "program input" we'll just have to think of another that can cover file input, argv, errno, rand(), getenv(), time(), clock(), localeconv(), system(NULL) and anything else I've overlooked. Maybe something like "environment derived data". >>I'd agree with you however that it is best to leave >>floating point out of this. :-) > >There is no conceptual difference between the way the standard deals with >floating point and with the rand/srand functions. On the contrary, I'd say >that the description of the sin() function is more precise than that of >rand() (although not precise enough to allow predicting the result of a >sin() call). The question is whether output derived from sin() is dependent on implementation-defined characteristics specified in 5.2.4.2.2. rand() doesn't have such issues (unless I've missed something in the standard relating to RAND_MAX). -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com -----------------------------------------