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.3 required=5.0 tests=BAYES_00,INVALID_MSGID, 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: 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 X-Google-Thread: fdb77,4873305131bf4d94 X-Google-Attributes: gidfdb77,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/13 Message-ID: <879381995snz@genesis.demon.co.uk>#1/1 X-Deja-AN: 289069022 References: X-Mail2News-Path: genesis.demon.co.uk Reply-To: fred@genesis.demon.co.uk X-Mail2News-User: fred@genesis.demon.co.uk X-Complaints-To: abuse@demon.net X-Trace: mail2news.demon.co.uk 879385952 16349 fred genesis.demon.co.uk Organization: none 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 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. >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. >>>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. Clause 4 says "A strictly conforming program 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 behavior, and shall not exceed any minimum implementation limit." The question is: what defines what constitutes unspecified, undefined, or implementation-defined behaviour? The answer is: the standard does, in all three cases. 3.16 isn't a carte blanche for lack of definition, it imposes specific requirements for a construct to have undefined behaviour. Those requirements don't turn out to depend on knowing (or not) what input is received from the environment in any particular instance. Simply knowing a program is strictly conforming does not mean you can predict what it will output. 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. I'd agree with you however that it is best to leave floating point out of this. :-) -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com -----------------------------------------