Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #26096

Re: scanf()

From Keith Thompson <kst-u@mib.org>
Newsgroups comp.lang.c
Subject Re: scanf()
Date 2012-09-07 15:02 -0700
Organization None to speak of
Message-ID <lnehmdsd8e.fsf@nuthaus.mib.org> (permalink)
References (4 earlier) <13a134c9-5a13-4ad8-a59d-227aa68e94c3@googlegroups.com> <ln1ujduy1j.fsf@nuthaus.mib.org> <7337238e-c54d-496a-a29f-c96799218e81@googlegroups.com> <lnwr15t0i1.fsf@nuthaus.mib.org> <kfnvcfpfs67.fsf@x-alumni2.alumni.caltech.edu>

Show all headers | View raw


Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>>  Keith Thompson:
>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>>> 
>>>> There are worse possibilities than wrong results.  If the input includes
>>>> something like "1.0e999999999", the behavior is undefined.
>>>> 
>>> But what is the program meant to do with such an input value? UB is probably the
>>> best thing that can happen to it.
>>
>> That's absurd.  Undefined behavior means that whatever the *worst*
>> thing is, it can happen, whether that's crashing the program, or
>> continuing to execute quietly with bad data, or reformatting your
>> hard drive.  [snip elaboration]
>
> It doesn't.  I admit that's often a useful way of thinking about
> undefined behavior, but that isn't what the term actually means
> (and I'm sure I'm not saying anything you don't already know).
> When the Standard says "undefined behavior", that means it
> imposes no requirements:  as far as the Standard is concerned,
> anything goes and everything is acceptable.
>
> But, the Standard isn't the only force operating here.  There is
> also the compiler that was used;  the operating system within
> which the program is being run;  possibly multiple levels of
> those if the program is being run in a virtual environment;  the
> physical hardware that the program is being run on;  and, going
> all the way to the bottom, the physical universe we all live in.
> Any one of those levels could serve to limit or define the set of
> potential behaviors available.
>
> So, at the same time that I agree that thinking of undefined
> behavior as meaning "anything can happen", I would argue that it's
> also important to keep in mind the actual implications of undefined
> behavior, which can be a positive in some circumstances.  I might
> not have chosen his phrasing, but the basic point Malcolm is making
> is essentially correct - "undefined behavior" is never really
> "undefined", but rather defined by elements and forces outside the
> sphere of what the Standard chooses to address.  Not knowing what
> defines the behavior or what the definition is doesn't mean they
> don't exist.

Yes, but the consequences can still be *really really bad*.

For any behavior that a computer system can possibly exhibit,
within the obvious limitations imposed by physics, logic, and the
design and construction of that system, it's possible in principle
for a C program whose behavior is undefined to exhibit that behavior.

Examples: If your operating system contains code that can reformat
a hard drive, and the system's protections are imperfect, it's
entirely possible (though admittedly unlikely) that undefined
behavior could cause your hard drive to be reformatted.  Consider a
function pointer whose value is corrupted, so it points to the code
in the `reformat_hard_drive()` routine just *after* the "Are you
sure?" prompt.

Compiler optimizations that *assume* defined behavior are a rich
source of unexpectedly bad consequences of undefined behaivor.

And deliberate exploitation of UB by malware can also have nasty
consequences.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"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


Thread

scanf() Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2012-08-06 20:58 +0000
  Re: scanf() Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-06 17:29 -0400
    Re: scanf() Keith Thompson <kst-u@mib.org> - 2012-08-06 14:40 -0700
  Re: scanf() James Kuyper <jameskuyper@verizon.net> - 2012-08-06 17:39 -0400
  Re: scanf() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-06 22:49 +0100
    Re: scanf() Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2012-08-07 18:37 +0000
      Re: scanf() James Kuyper <jameskuyper@verizon.net> - 2012-08-07 15:01 -0400
      Re: scanf() Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-07 15:03 -0400
      Re: scanf() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-07 20:51 +0100
      Re: scanf() John Bode <jfbode1029@gmail.com> - 2012-08-09 14:00 -0700
        Re: scanf() Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-11 03:08 -0700
          Re: scanf() Keith Thompson <kst-u@mib.org> - 2012-08-11 10:40 -0700
            Re: scanf() Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-11 13:34 -0700
              Re: scanf() "BartC" <bc@freeuk.com> - 2012-08-11 23:04 +0100
              Re: scanf() James Kuyper <jameskuyper@verizon.net> - 2012-08-11 19:20 -0400
              Re: scanf() Keith Thompson <kst-u@mib.org> - 2012-08-11 17:30 -0700
                Re: scanf() Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-11 20:41 -0400
                Re: scanf() Keith Thompson <kst-u@mib.org> - 2012-08-11 18:13 -0700
                Re: scanf() Keith Thompson <kst-u@mib.org> - 2012-08-11 18:16 -0700
                Re: scanf() Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-11 21:32 -0400
                Re: scanf() Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-12 04:07 -0700
                Re: scanf() James Kuyper <jameskuyper@verizon.net> - 2012-08-12 08:03 -0400
                Re: scanf() Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-12 06:41 -0700
                Re: scanf() Keith Thompson <kst-u@mib.org> - 2012-08-12 13:39 -0700
                Re: scanf() Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-12 14:20 -0700
                Re: scanf() Keith Thompson <kst-u@mib.org> - 2012-08-12 16:33 -0700
                Re: scanf() "Heinrich Wolf" <invalid@invalid.invalid> - 2012-08-13 12:22 +0200
                Re: scanf() Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-09-05 00:13 +0300
                Re: scanf() Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 14:18 -0700
                Re: scanf() Keith Thompson <kst-u@mib.org> - 2012-09-07 15:02 -0700
                Re: scanf() Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 17:25 -0700
                Re: scanf() Keith Thompson <kst-u@mib.org> - 2012-09-07 18:35 -0700
              Re: scanf() Seungbeom Kim <musiphil@bawi.org> - 2012-08-12 21:05 -0700
        Re: scanf() Robert Wessel <robertwessel2@yahoo.com> - 2012-08-11 17:37 -0500

csiph-web