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=-1.2 required=5.0 tests=BAYES_00,INVALID_MSGID, PLING_QUERY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1014db,4873305131bf4d94 X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,4873305131bf4d94 X-Google-Attributes: gid103376,public X-Google-Thread: fdb77,4873305131bf4d94 X-Google-Attributes: gidfdb77,public X-Google-Thread: 109fba,4873305131bf4d94 X-Google-Attributes: gid109fba,public From: Dan.Pop@cern.ch (Dan Pop) Subject: Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Date: 1997/11/13 Message-ID: #1/1 X-Deja-AN: 289359088 Sender: news@news.cern.ch (USENET News System) References: <879381995snz@genesis.demon.co.uk> Originator: danpop@ues4.cern.ch X-Nntp-Posting-Host: ues4.cern.ch Organization: CERN European Lab for Particle Physics Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.java.advocacy Date: 1997-11-13T00:00:00+00:00 List-Id: 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. Furthermore, even if I read the implementation's documentation, there is still no guarantee that I can predict the output. >>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. >>>>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"??? >Simply knowing a program is strictly conforming does not mean you can >predict what it will output. Then, it is not strictly conforming. >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 :-) 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. >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). Dan -- Dan Pop CERN, IT Division Email: Dan.Pop@cern.ch Mail: CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland