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: 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: 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/09 Message-ID: <873814384snz@genesis.demon.co.uk>#1/1 X-Deja-AN: 288830899 References: <34557f2b.1934172@news.mindspring.com> <63qkp9$bqr$3@darla.visi.com> <63r2sv$rgm$1@helios.crest.nt.com> <878820761snz@genesis.demon.co.uk> <63t1j9$md8$1@helios.crest.nt.com> 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 879117415 15127 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-09T00:00:00+00:00 List-Id: In article Dan.Pop@cern.ch "Dan Pop" writes: ... >>Is a strictly conforming program required to deal with the possibility >>that EOF might not actually be an indicator of neither an error, nor >>the end of input? > >Can a strictly conforming program perform *any* kind of I/O? Yes. > You cannot >predict the behaviour of the system from the text of the standard. Yes you can, however that behaviour depends on input from the environment. Error returns from I/O functions constitute a form of input from the environment. > Part >of the definition of "strictly conforming program" says: > > It shall not produce output dependent on any unspecified, undefined, or > implementation-defined behavior... However that doesn't mean that a strictly conforming program has to produce the same output every time you run it. If that were true a program which wrote output derived from rand() could not be strictly conforming (and it can). >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 (*). It only has undefined behaviour where its argument is not a valid pointer to a stream. What it actually does in any particular circumstance will depend on input from the environment, and that includes whether it generates an end-of-file or error indication. * - there are various forms of implementation-defined behaviour specified generally for files and streams, e.g. in section 7.9.2 and 7.9.3. You may have a valid argument relating to those but that needs to be argued on a case by case basis, I'm referring above to getc() specifically as defined in section 7.9.7.5. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com -----------------------------------------