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 19:12:28 -0700 Organization: None to speak of Lines: 79 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> <0d349302-0a98-4fa3-a368-8ac76ca8c546@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="068e13fa936d4e49cf562f96621eaf4d"; logging-data="30530"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/OpFe10eZ5prDwaaCIMrT4" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:339d/SOpgH42zPaDegRpbLI3Yn0= sha1:WBkXssqQtzq3QQIkC2RWC45UFSA= Xref: csiph.com comp.lang.c:95816 supercat@casperkitty.com writes: > On Friday, November 4, 2016 at 6:44:22 PM UTC-5, Keith Thompson wrote: >> supercat writes: >> > 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. > > Does anything in the Standard specify the behavior in the event that the > implementation does not require a newline before EOF, and indeed none > exists? The behavior of what? A stream has no behavior by itself. The behavior of any function that operates on a FILE* is defined by the description of that function. If there's some construct whose behavior you think is not defined in that case, please specify what it is. >> 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. > > Would anything in the Standard guarantee sane behavior, or are you merely > assuming that because it would be silly for implementations to do anything > nasty, implementations won't do anything nasty? See above. > I've certainly seen programs where failure to include a newline after the > last line of a file would cause the program to process the line preceding > the last line twice; I have no idea if they were written in C or some > other language, but certainly line-input routines which behave badly on > files that end with partial lines are not unknown in this world. Yes, some programs have bugs. >> > 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? > > What happens if someone types x, or 12x, or 12 34x, etc.? A smart routine > for an interactive system could validate input as it was typed and reject > invalid characters immediately. I don't know that any implementations > defined their scanf routines to do so, but a routine that did so could > certainly be helpful. Sure. scanf doesn't do that. -- 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"