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: scanf used for to get a line Date: Fri, 04 Nov 2016 16:44:18 -0700 Organization: None to speak of Lines: 72 Message-ID: References: <15ea8d6d-0173-491c-b6b5-b1c57dd61769@googlegroups.com> <236c25a6-8c18-4082-ab3a-86eb55fb2408@googlegroups.com> <5e06af91-eec8-42cd-87c4-99d2b448de84@googlegroups.com> <108db18d-12c1-4eaa-afc9-59e7c0ca7798@googlegroups.com> <3c58680e-35cb-4c1f-b53f-91d8d3fbf2f9@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="068e13fa936d4e49cf562f96621eaf4d"; logging-data="31869"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+YBaF5tLBrkG2rHOX1qlUH" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:jr1y7qoJkH+GSs0PdJussAK52xQ= sha1:LBLG585jIKOl228/10vofvaCeNM= Xref: csiph.com comp.lang.c:95811 supercat@casperkitty.com writes: > On Friday, November 4, 2016 at 1:45:20 PM UTC-5, Keith Thompson wrote: >> supercat writes: >> > The Standard the scenarios in which a newline is encountered, no newline >> > is encountered before enough characters are read, the end of the file is >> > encountered *and no characters have been read into the array*, or a >> > read-error occurs. I see nothing that would characterize EOF as a read >> > error, nor do I see anything that would describe the behavior in case >> > an EOF is encountered after characters have been read. Those factors put >> > together would seem to suggest that nasal demons in such a scenario would >> > not make an implementation non-conforming. >> >> Can you be more specific about the scenario you're talking about? > > Standard input contains some characters followed by EOF, with no intervening > newline. > > The Standard describes behavior in many scenarios, but the only way in which > it could be construed as defining behavior when a file ends with a partial > line would be if such a partial line was considered an error. I don't see > anything in the Standard, however, which would indicate that hitting > end-of-file when the preceding character isn't a newline should be considered > an error condition. N1570 7.21.2p2 says: A text stream is an ordered sequence of characters composed into *lines*, each line consisting of zero or more characters plus a terminating new-line character. Whether the last line requires a terminating new-line character is implementation-defined. If the implementation does require a terminating new-line and a given stream doesn't have one, then my interpretation is that the behavior of reading that stream is undefined. That's unlikely to be a problem in practice. I speculate that it's intended mainly to cater to systems with complex text file formats, where an ill-formed text file might be unreadable. In particular, I believe the new-line is *not* required on Unix-like systems, and probably not on Windows either. Calling fgets() at the end of such a file would just give the last line as a string with no trailing new-line. [...] >> I'd be surprised if scanf() >> were ever designed to trigger a buzzer on any system to which it >> was ported. (Feel free to present a real-world counterexample.) >> It already has error-reporting facilities, and any interactive >> response to an error should be up to the program, not to the >> library routine. > > I don't know if any counter-examples. On the other hand, since the > semantics of scanf make reasonable error-trapping behavior at the > application level awkward, and I don't think it's hard to imagine-- > especially in the days before the Standard--that an implementor might > decide to implement design their "scanf" function in such a way that > scanf("%d %d", &var1, &var2); would be a reasonable way to read two > numbers from the console. Apart from the numeric overflow problem, that *is* a reasonable way to read two numbers from the console (assuming you don't require them to be on the same line). Was that intended to have something to do with the buzzer scanario? [...] -- 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"