Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| Path | csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail |
|---|---|
| From | Keith Thompson <kst-u@mib.org> |
| 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 | <ln37j6wu7n.fsf@kst-u.example.com> (permalink) |
| References | <15ea8d6d-0173-491c-b6b5-b1c57dd61769@googlegroups.com> <236c25a6-8c18-4082-ab3a-86eb55fb2408@googlegroups.com> <nvfoa6$lsu$1@dont-email.me> <lnfun8zffj.fsf@kst-u.example.com> <5e06af91-eec8-42cd-87c4-99d2b448de84@googlegroups.com> <lnbmxwzab8.fsf@kst-u.example.com> <ba811315-30c5-49f8-b4c6-1a733e7a0ab2@googlegroups.com> <lnpomcxhlt.fsf@kst-u.example.com> <108db18d-12c1-4eaa-afc9-59e7c0ca7798@googlegroups.com> <lnr36rw0aq.fsf@kst-u.example.com> <3c58680e-35cb-4c1f-b53f-91d8d3fbf2f9@googlegroups.com> <ln7f8ix12l.fsf@kst-u.example.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 |
Show key headers only | View raw
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 <http://www.ghoti.net/~kst>
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"
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
scanf used for to get a line asetofsymbols@gmail.com - 2016-11-01 01:50 -0700
scanf used for to get a line asetofsymbols@gmail.com - 2016-11-01 01:55 -0700
Re: scanf used for to get a line mark.bluemel@gmail.com - 2016-11-01 03:55 -0700
Re: scanf used for to get a line "Charles Richmond" <numerist@aquaporin4.com> - 2016-11-03 11:23 -0500
Re: scanf used for to get a line Keith Thompson <kst-u@mib.org> - 2016-11-03 09:38 -0700
Re: scanf used for to get a line supercat@casperkitty.com - 2016-11-03 10:08 -0700
Re: scanf used for to get a line Keith Thompson <kst-u@mib.org> - 2016-11-03 11:29 -0700
Re: scanf used for to get a line supercat@casperkitty.com - 2016-11-03 14:37 -0700
Re: scanf used for to get a line Keith Thompson <kst-u@mib.org> - 2016-11-03 16:34 -0700
Re: scanf used for to get a line supercat@casperkitty.com - 2016-11-04 10:21 -0700
Re: scanf used for to get a line Keith Thompson <kst-u@mib.org> - 2016-11-04 11:46 -0700
Re: scanf used for to get a line supercat@casperkitty.com - 2016-11-04 15:04 -0700
Re: scanf used for to get a line Keith Thompson <kst-u@mib.org> - 2016-11-04 16:44 -0700
Re: scanf used for to get a line supercat@casperkitty.com - 2016-11-04 17:13 -0700
Re: scanf used for to get a line Keith Thompson <kst-u@mib.org> - 2016-11-04 19:12 -0700
Re: scanf used for to get a line supercat@casperkitty.com - 2016-11-05 14:10 -0700
Re: scanf used for to get a line Keith Thompson <kst-u@mib.org> - 2016-11-05 14:22 -0700
Re: scanf used for to get a line Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-15 10:57 -0800
Re: scanf used for to get a line supercat@casperkitty.com - 2016-11-15 12:05 -0800
Re: scanf used for to get a line jameskuyper@verizon.net - 2016-11-15 14:01 -0800
Re: scanf used for to get a line Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-16 10:54 -0800
Re: scanf used for to get a line Richard Damon <Richard@Damon-Family.org> - 2016-11-21 18:01 -0500
Re: scanf used for to get a line supercat@casperkitty.com - 2016-11-21 15:44 -0800
Re: scanf used for to get a line asetofsymbols@gmail.com - 2016-11-03 13:35 -0700
Re: scanf used for to get a line Keith Thompson <kst-u@mib.org> - 2016-11-03 13:50 -0700
Re: scanf used for to get a line ImperiusDamian <damianblack.wolf@gmail.com> - 2016-11-05 16:10 -0400
Re: scanf used for to get a line Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-01 11:39 +0000
Re: scanf used for to get a line asetofsymbols@gmail.com - 2016-11-01 05:47 -0700
Re: scanf used for to get a line Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-01 15:05 +0000
Re: scanf used for to get a line asetofsymbols@gmail.com - 2016-11-02 01:42 -0700
csiph-web