Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: One over another: (*structp).component structp->component Date: Fri, 06 Nov 2015 11:10:32 -0800 Organization: None to speak of Lines: 89 Message-ID: References: <69d66e0c-4b66-4921-842d-e7754b5f3c68@googlegroups.com> <3e5fb9e7-6d8b-4e07-855d-392ff9d11caa@googlegroups.com> <4942e280-cd7c-49f3-bd3a-25bb03967fbf@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="13227"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18LTZI/d4Y67oPYEtlWjINv" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:dBPbUbVKthpivBPldQ0nsBW3FbM= sha1:fgQ+VqIppDYPcXdvBaUwShHmN6k= Xref: csiph.com comp.lang.c:75157 supercat@casperkitty.com writes: > On Friday, November 6, 2015 at 10:02:07 AM UTC-6, Keith Thompson wrote: >> The change I suggest (treating numeric overflow as an error) >> would only define behavior that is currently undefined. Any code >> that depends on that undefined behavior, or on what a particular >> implementation does, is already broken. Such code probably already >> handles input errors (like reading "xyz" when it's expecting an >> integer). > > The difficulty is that there may be existing programs which are > reliant upon the target implementation's scanf terminating the program > to prevent it from proceeding with seemingly-valid-but-wrong input; > even if your proposal would provide a means by which incorrect input > could be detected, existing code may not recognize that. I'm skeptical that such programs exist in any significant numbers. Examples would be welcome. If they do, then that *might* be a reason not to go with my proposal to treat numeric overflow as a detectable error. But I suggest that backward compatibility would be the *only* valid reason to consider either staying with the current definition or adopting yours. And again, it would affect only programs whose behavior is currently undefined. If you want to write a program that reads an integer from a text stream and terminates if it's outside the range of the target type, you can already do that by calling fgets() followed by one of the strto*() functions, calling abort() if necessary. Depending on *scanf() to do that for you would be foolish. (And aborting on bad input is rarely a good idea anyway.) In the one implementation I've tried, a numeric overflow resulted in the value -1 being assigned to the variable, with no indication that there was a problem. A hypothetical program that assumes abnormal termination would misbehave. For that matter, can you cite an existing implementation in which numeric overflow in *scanf() causes termination of the calling program? If, as I tentatively suspect, there are no such implementations, then there can be no programs that depend on such behavior. If you were designing a formatted text input function from scratch, would you even consider making the behavior on numeric overflow either undefined, implementation-defined, or unspecified? The strto*() functions (which I believe were added to the language after *scanf() already existed) have well defined behavior on overflow. Why should *scanf() be different? > It's too bad many people don't understand the former historical > semantic significance of Undefined Behavior. C wasn't designed to be > a language for writing machine-independent code--it was designed to be > a family of dialects that could be used to write code for many varied > individual machines, which would provide a variety of features which > could be useful for a variety of kinds of programs which had to meet a > variety of needs. C intentionally makes it possible both to write portable code and to write non-portable system-specific code. This goes back at least to K&R1, 1978, which lists 4 different target systems, at least one of which was chosen specifically to be as different from the PDP-11 as possible. I can think of no good reason for the *scanf() functions to be restricted to non-portable usage. > Some programs were required never to produce seemingly-valid-but-wrong > output in case of things like numeric overflow; if the program > couldn't produce correct output, it needed to terminate abnormally > rather than produce wrong output. Then it's too bad that C has *never* required a program to terminate abnormally on an error (barring an explicit call to abort() or something similar). (C11's Annex K says that an implementation has a default runtime constraint handler; it may or may not cause the program to exit or abort.) [...] A side note. I've noticed that the text in most of your articles is quite close to 80 columns, which means it goes past 80 columns when it's quoted (triggering a warning from my newsreader). Would it be difficult for you to format your text to, say, 72 columns? (I often use `fmt -70` myself.) -- 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"