Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: while loop vs do while loop reading from the file issue Date: Tue, 13 Dec 2016 08:27:52 -0800 Organization: None to speak of Lines: 54 Message-ID: References: <52f1c174-6af1-4fda-9ff8-a5e2cf507b5f@googlegroups.com> <8737hv36ta.fsf@bsb.me.uk> <87lgvn1obu.fsf@bsb.me.uk> <874m2b1h03.fsf@bsb.me.uk> <87y3znz1rw.fsf@bsb.me.uk> <878trmxufh.fsf@bsb.me.uk> <87d1gyw8s6.fsf@bsb.me.uk> <87inqpucmw.fsf@bsb.me.uk> <87fultqnuz.fsf@bsb.me.uk> <87bmwgpxbs.fsf@bsb.me.uk> <87mvg0o6hk.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="dfa63d714b7efbf23555ba45297b3f3c"; logging-data="30391"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19DpYYik4vG3sAm2XcBiq3f" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:IG8GAenZReGcj8vjjju5qIOqY6w= sha1:NFOSuj3OlQed/ojY/9lZQxDX3xA= Xref: csiph.com comp.lang.c:99216 BartC writes: > On 13/12/2016 03:25, Ben Bacarisse wrote: > > BartC writes: > > > Also, because your readLn statement ignores errors > > If there's anything wrong then an empty string is produced. Isn't an empty string also a valid result? > At this point, one character is known to be ready, but it's possible the > next line is a billion characters and there are a number of things that > could go wrong before it's read all billion of them: > > * The input buffer gets full, assuming there's no scheme to extend it > > * If there is, then memory is exhausted > > * There is a hard file error. Or disk error. Or network error. > > The thing is, in a program that reads a 20-line configuration file, you > don't really want to deal comprehensively with all those possibilities. And that's where exploits come from. If I can break your program by providing a config file with very long lines, you could have a security hole. > > (or seems to at least > > -- I have no reference material for this language) the translated C does > > so as well. strtofloat and readfloat apparently can't fail > > Fail in what way? Either a bunch of characters contain something that > can be interpreted as a floating point number at the start, or they > don't. If not then I'm happy with a return value of 0.0 (perhaps set > when sscanf returns 0). So you're happy not bothering to distinguish between an invalid floating-point number and a valid floating-point number with the value 0.0. I wouldn't be. > Otherwise, how do you represent several possibilities (parsing error, > range overflow etc) in a floating point return value? (For that matter, > how does atol() do it?) atol() doesn't do it; the ato*() functions don't detect errors. Use the strto*() functions for that. [snip] -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"