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

Groups > comp.lang.c > #24322 > unrolled thread

scanf()

Back to article view | Back to comp.lang.c

Contents

  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

Page 1 of 2  [1] 2  Next page →

#24322 — scanf()

Hello

If scanf() fails for a matching error, what can we say about the location 
of the file pointer for subsequent reads from stdin? Could it have read 
on through an indeterminate amount of stdin, or will it always be 
positioned immediately after the last successful conversion from the 
format string?

Regards

[toc] | [next] | [standalone]

#24323

On 8/6/2012 4:58 PM, Edward Rutherford wrote:
> Hello
>
> If scanf() fails for a matching error, what can we say about the location
> of the file pointer for subsequent reads from stdin? Could it have read
> on through an indeterminate amount of stdin, or will it always be
> positioned immediately after the last successful conversion from the
> format string?

     The former.  For example, consider reading with "%e" and
encountering the input "123.4567e+---".  The first ten characters
are a valid prefix for a floating-point number, which is then
spoiled by the eleventh.  Yet scanf() can't simply push the
eleventh character back onto the stream and convert the first
ten: They are valid as a prefix but not as a complete number.
scanf() would have to push back three characters ('-', '+', 'e')
to arrive at something valid, but it has only one character of
push-back to work with.  And, of course, there's simply no way
it can get all the way back to a position before the '1'.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#24326

Eric Sosman <esosman@ieee-dot-org.invalid> writes:
> On 8/6/2012 4:58 PM, Edward Rutherford wrote:
>> If scanf() fails for a matching error, what can we say about the location
>> of the file pointer for subsequent reads from stdin? Could it have read
>> on through an indeterminate amount of stdin, or will it always be
>> positioned immediately after the last successful conversion from the
>> format string?
>
>      The former.  For example, consider reading with "%e" and
> encountering the input "123.4567e+---".  The first ten characters
> are a valid prefix for a floating-point number, which is then
> spoiled by the eleventh.  Yet scanf() can't simply push the
> eleventh character back onto the stream and convert the first
> ten: They are valid as a prefix but not as a complete number.
> scanf() would have to push back three characters ('-', '+', 'e')
> to arrive at something valid, but it has only one character of
> push-back to work with.  And, of course, there's simply no way
> it can get all the way back to a position before the '1'.

And that's not the only problem with using scanf to read numeric data.

Consider reading with "%e" and encountering the input "1.0e9999999".
The behavior is undefined -- and since you're reading from stdin,
there's no way (using scanf alone) to avoid that.

(This was something I really hoped C11 would fix, but it didn't.)

The safe way to read floating-point data from stdin is to read lines
using fgets() (or something similar -- obviously not gets()), and then
parse it using strtod().

-- 
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"

[toc] | [prev] | [next] | [standalone]

#24324

On 08/06/2012 04:58 PM, Edward Rutherford wrote:
> Hello
> 
> If scanf() fails for a matching error, what can we say about the location 
> of the file pointer for subsequent reads from stdin? Could it have read 
> on through an indeterminate amount of stdin, or will it always be 
> positioned immediately after the last successful conversion from the 
> format string?
> 
> Regards
> 

"An input item is defined as the longest sequence of input characters
which does not exceed any specified field width and which is, or is a
prefix of, a matching input sequence.285) The first character, if any,
after the input item remains unread." (7.21.6.2p9).

[toc] | [prev] | [next] | [standalone]

#24327

Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> writes:

> If scanf() fails for a matching error, what can we say about the location 
> of the file pointer for subsequent reads from stdin? Could it have read 
> on through an indeterminate amount of stdin, or will it always be 
> positioned immediately after the last successful conversion from the 
> format string?

No, it can read an unlimited number of characters before reporting a
matching failure.  There are lots of details, but since you are asking
an all-or-nothing question, you probably don't care about them.  A
"worst case" example occurs when processing "%d" -- an unlimited number
of white-space characters can be read before any matching failure can be
reported.  If there is such a failure, the character that causes it
matching failure will pushed back onto the stream, but that's all.

The scanf functions only ever push back at most one character so you
can use that a rule of thumb to imagine what they must consume before
a directive can fail.

For some input patterns %n is an effective solution, but you don't say
what your overall objective is so I can't be sure.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#24353

Ben Bacarisse wrote:

> Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> writes:
> 
>> If scanf() fails for a matching error, what can we say about the
>> location of the file pointer for subsequent reads from stdin? Could it
>> have read on through an indeterminate amount of stdin, or will it
>> always be positioned immediately after the last successful conversion
>> from the format string?
> 
> No, it can read an unlimited number of characters before reporting a
> matching failure.  There are lots of details, but since you are asking
> an all-or-nothing question, you probably don't care about them.  A
> "worst case" example occurs when processing "%d" -- an unlimited number
> of white-space characters can be read before any matching failure can be
> reported.  If there is such a failure, the character that causes it
> matching failure will pushed back onto the stream, but that's all.
> 
> The scanf functions only ever push back at most one character so you can
> use that a rule of thumb to imagine what they must consume before a
> directive can fail.
> 
> For some input patterns %n is an effective solution, but you don't say
> what your overall objective is so I can't be sure.

That's unfortunate, because then there's no way to recover the non-
matching data, as far as I can see.

Wouldn't it be better if scanf() buffered non-matching characters, either 
seemlessly in the background (so that future reads from stdin saw those 
characters) or by returning a pointer to a buffer containing them?

[toc] | [prev] | [next] | [standalone]

#24354

On 08/07/2012 02:37 PM, Edward Rutherford wrote:
> Ben Bacarisse wrote:
> 
>> Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> writes:
>>
>>> If scanf() fails for a matching error, what can we say about the
>>> location of the file pointer for subsequent reads from stdin? Could it
>>> have read on through an indeterminate amount of stdin, or will it
>>> always be positioned immediately after the last successful conversion
>>> from the format string?
>>
>> No, it can read an unlimited number of characters before reporting a
>> matching failure.  There are lots of details, but since you are asking
>> an all-or-nothing question, you probably don't care about them.  A
>> "worst case" example occurs when processing "%d" -- an unlimited number
>> of white-space characters can be read before any matching failure can be
>> reported.  If there is such a failure, the character that causes it
>> matching failure will pushed back onto the stream, but that's all.
>>
>> The scanf functions only ever push back at most one character so you can
>> use that a rule of thumb to imagine what they must consume before a
>> directive can fail.
>>
>> For some input patterns %n is an effective solution, but you don't say
>> what your overall objective is so I can't be sure.
> 
> That's unfortunate, because then there's no way to recover the non-
> matching data, as far as I can see.
> 
> Wouldn't it be better if scanf() buffered non-matching characters, either 
> seemlessly in the background (so that future reads from stdin saw those 
> characters) or by returning a pointer to a buffer containing them?

scanf() was not intended to have that complicated an interface, and it's
far too late to make any changes to its interface now.

If you want to do something like that, the standard library provides you
with the pieces you need to assemble to do it yourself: fgets() from
<stdio.h>  and the strto*() functions from <stdlib.h> are the most
relevant ones.

[toc] | [prev] | [next] | [standalone]

#24355

On 8/7/2012 2:37 PM, Edward Rutherford wrote:
> Ben Bacarisse wrote:
>
>> Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> writes:
>>
>>> If scanf() fails for a matching error, [...] Could it
>>> have read on through an indeterminate amount of stdin, [...]
>>
>> No, it can read an unlimited number of characters before reporting a
>> matching failure.  [...]
>
> That's unfortunate, because then there's no way to recover the non-
> matching data, as far as I can see.

     Right. That's one of the reasons scanf() and its brethren
are difficult to use in "industrial-strength" applications.

> Wouldn't it be better if scanf() buffered non-matching characters, either
> seemlessly in the background (so that future reads from stdin saw those
> characters) or by returning a pointer to a buffer containing them?

     Which part of "indeterminate amount" and "unlimited number"
do you have trouble understanding?  ;-)

     If you need to revisit those characters, you'll need to buffer
them yourself (or fseek() back to them, if the input is seekable).
You'd need to read them into a buffer first, and then apply sscanf()
to the buffer; as Ben suggests, the "%n" specifier may be helpful
in navigating.

     My own preference when parsing input fancy enough to warrant
backtracking is to read it as plain characters (perhaps a line at
a time, if "line" makes sense), store them in a buffer, and pick
them apart with strxxx() functions. Even sscanf() has infelicities.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#24356

Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> writes:

> Ben Bacarisse wrote:
>
>> Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> writes:
>> 
>>> If scanf() fails for a matching error, what can we say about the
>>> location of the file pointer for subsequent reads from stdin? Could it
>>> have read on through an indeterminate amount of stdin, or will it
>>> always be positioned immediately after the last successful conversion
>>> from the format string?
>> 
>> No, it can read an unlimited number of characters before reporting a
>> matching failure.  There are lots of details, but since you are asking
>> an all-or-nothing question, you probably don't care about them.  A
>> "worst case" example occurs when processing "%d" -- an unlimited number
>> of white-space characters can be read before any matching failure can be
>> reported.  If there is such a failure, the character that causes it
>> matching failure will pushed back onto the stream, but that's all.
>> 
>> The scanf functions only ever push back at most one character so you can
>> use that a rule of thumb to imagine what they must consume before a
>> directive can fail.
>> 
>> For some input patterns %n is an effective solution, but you don't say
>> what your overall objective is so I can't be sure.
>
> That's unfortunate, because then there's no way to recover the non-
> matching data, as far as I can see.

You've got good answers already so I'll just indulge in picking a small
nit: you can always get the non-matching data -- it's left in the stream
by definition!  I know what you mean, of course, I just don't know a
good word for it.

To make up for being mean, here's some advice that might help.  If you
want to be able to back-up to the last place a conversion worked, you
might keep track of the stream position (using fgetpos) after every
successful fscanf call.  After every failed one, fsetpos to the last
saved position.

That's no use for sscanf, of course, and it does mean you probably have
to do calls with only one conversion specifier at a time, but it might
be all you need.

> Wouldn't it be better if scanf() buffered non-matching characters, either 
> seemlessly in the background (so that future reads from stdin saw those 
> characters) or by returning a pointer to a buffer containing them?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#24388

On Tuesday, August 7, 2012 1:37:19 PM UTC-5, Edward Rutherford wrote:
> Ben Bacarisse wrote:
> 
> > The scanf functions only ever push back at most one character so you can
> > use that a rule of thumb to imagine what they must consume before a
> > directive can fail.
> > 
> > For some input patterns %n is an effective solution, but you don't say
> > what your overall objective is so I can't be sure.
> 
> That's unfortunate, because then there's no way to recover the non-
> matching data, as far as I can see.
> 

Which is why scanf() is the wrong tool for all but the simplest
input tasks.  Unless I can guarantee that my input is always
well-behaved, I avoid using anything from the *scanf() family.

Use fgets() to consume an entire line, then parse and convert each 
element using tools like strtok(), strtod() strtol(), etc.  

[toc] | [prev] | [next] | [standalone]

#24431

בתאריך יום חמישי, 9 באוגוסט 2012 22:00:49 UTC+1, מאת John Bode:
> 
> Which is why scanf() is the wrong tool for all but the simplest
> input tasks.  Unless I can guarantee that my input is always
> well-behaved, I avoid using anything from the *scanf() family.
> 
It depends on the quality of parsing you want. Let's say we have x, y
co-ordinates in columns.

while(fscanf(fp, "%f %f\n", &x, &y) == 2)
{
   /* assign x and y to arrays */
}

won't catch malformed imput like four columns in a rogue line.
But for many applications, it's probably good enough. If it's a 
bad file, it will fail eventually. A no-one's got an interest in
providing malicious input to deliberately get a wrong result.

[toc] | [prev] | [next] | [standalone]

#24437

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> בתאריך יום חמישי, 9 באוגוסט 2012 22:00:49 UTC+1, מאת John Bode:
>> Which is why scanf() is the wrong tool for all but the simplest
>> input tasks.  Unless I can guarantee that my input is always
>> well-behaved, I avoid using anything from the *scanf() family.
>> 
> It depends on the quality of parsing you want. Let's say we have x, y
> co-ordinates in columns.
>
> while(fscanf(fp, "%f %f\n", &x, &y) == 2)
> {
>    /* assign x and y to arrays */
> }
>
> won't catch malformed imput like four columns in a rogue line.
> But for many applications, it's probably good enough. If it's a 
> bad file, it will fail eventually. A no-one's got an interest in
> providing malicious input to deliberately get a wrong result.

There are worse possibilities than wrong results.  If the input includes
something like "1.0e999999999", the behavior is undefined.

If you can treat the input file as part of the program, so that an error
in the input file is the same as a coding error, then it's probably ok
to use fscanf.  Otherwise ...

-- 
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"

[toc] | [prev] | [next] | [standalone]

#24438

בתאריך יום שבת, 11 באוגוסט 2012 18:40:56 UTC+1, מאת 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.
"Undefined behaviour" means "the C standard imposes no restrictions on the
behaviour of the implementation", not that the behaviour exists in some
ontological state of undefinedness. 

[toc] | [prev] | [next] | [standalone]

#24440

"Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message
news:7337238e-c54d-496a-a29f-c96799218e81@googlegroups.com...
> בתאריך יום שבת, 11 באוגוסט 2012 18:40:56 UTC+1, מאת 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.
> "Undefined behaviour" means "the C standard imposes no restrictions on the
> behaviour of the implementation", not that the behaviour exists in some
> ontological state of undefinedness.

So, you have an application which consists of a user interface and a bunch
of data, much of which has not been committed to disk. It's been running for
several hours, but if the user then chooses a command which reads something
from a file, and accidentally chooses a binary instead of a text file, the
application should just crash with the loss of all data?

You've obviously never had to deal with irate clients on the phone!

(With the routines I use (the C stuff is buried several layers deep so I
couldn't tell you exactly what library functions are used), any non-numeric
input will return 0.0 when trying to read floating point. Anything numeric
but out-of-range such as 1.0e99999999 is read as INF.

Input is always line oriented too (so running into end-of-line while trying 
to read more numbers will just return 0.0. All solid behaviour,
although it's possible some of this is due to a well-behaved version of 
scanf() somewhere.)

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#24443

On 08/11/2012 04:34 PM, Malcolm McLean wrote:
> בתאריך יום שבת, 11 באוגוסט 2012 18:40:56 UTC+1, מאת 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.

In most of my programs, the program is meant to report the fact that it
has run into a problem with the input, and to identify the offending
input and the context in which it occurred (for this particular program
that would mean identifying the line number). In some cases, at the
appropriate level (which is, in general, not the same as the level at
which the problem was detected), it is meant retry the action with
something changed that might prevent or avoid the problem; for this
program, that might mean asking the user to provide the name of a
different file to use as input. UB is almost never on my agenda for the
appropriate response to an error condition.

> "Undefined behaviour" means "the C standard imposes no restrictions on the
> behaviour of the implementation", not that the behaviour exists in some
> ontological state of undefinedness. 

I try my best to avoid having my programs enter a given state unless
their behavior in that state is defined by something (not necessarily
the C standard), and I know what that definition is.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#24446

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> בתאריך יום שבת, 11 באוגוסט 2012 18:40:56 UTC+1, מאת 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.

And before you reject that last possibility, consider this: Is
there code in your operating system that's designed to reformat
a hard drive?  Are you *certain* that an instance of undefined
behavior can't possibly corrupt some function pointer and cause
that code to be invoked?

I admit that feeding "1.0e999999999" to scanf isn't likely to reformat
your hard drive (or I wouldn't have tried it just now), but why take the
risk?  If you use gets() and strtod(), you can at least detect an input
error and abort the program.

> "Undefined behaviour" means "the C standard imposes no restrictions on the
> behaviour of the implementation", not that the behaviour exists in some
> ontological state of undefinedness. 

Nor does it mean "the program is guaranteed to crash with a
meaningful error message".

-- 
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"

[toc] | [prev] | [next] | [standalone]

#24447

On 8/11/2012 8:30 PM, Keith Thompson wrote:
>[...]
> I admit that feeding "1.0e999999999" to scanf isn't likely to reformat
> your hard drive (or I wouldn't have tried it just now), but why take the
> risk?  If you use gets() and strtod(), you can at least detect an input
> error and abort the program.

     Extend your wrist, Keith, whilst I administer the slap.
And I'm rescinding all the gold stars you won last term, too.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#24448

Eric Sosman <esosman@ieee-dot-org.invalid> writes:
> On 8/11/2012 8:30 PM, Keith Thompson wrote:
>>[...]
>> I admit that feeding "1.0e999999999" to scanf isn't likely to reformat
>> your hard drive (or I wouldn't have tried it just now), but why take the
>> risk?  If you use gets() and strtod(), you can at least detect an input
>> error and abort the program.
>
>      Extend your wrist, Keith, whilst I administer the slap.
> And I'm rescinding all the gold stars you won last term, too.

Aarrgghh!

Perhaps my f key isn't working.  Nope, there it is, can't use that
excuse.

Wrist slap humbly accepted -- but I assure it it was a typo, not a
thinko.

-- 
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"

[toc] | [prev] | [next] | [standalone]

#24449

Keith Thompson <kst-u@mib.org> writes:
[...]
> Wrist slap humbly accepted -- but I assure it it was a typo, not a
> thinko.

... but I assure *you* it was a typo ...

http://en.wikipedia.org/wiki/Muphry%27s_law

-- 
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"

[toc] | [prev] | [next] | [standalone]

#24450

On 8/11/2012 9:13 PM, Keith Thompson wrote:
> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>> On 8/11/2012 8:30 PM, Keith Thompson wrote:
>>> [...]
>>> I admit that feeding "1.0e999999999" to scanf isn't likely to reformat
>>> your hard drive (or I wouldn't have tried it just now), but why take the
>>> risk?  If you use gets() and strtod(), you can at least detect an input
>>> error and abort the program.
>>
>>       Extend your wrist, Keith, whilst I administer the slap.
>> And I'm rescinding all the gold stars you won last term, too.
>
> Aarrgghh!
>
> Perhaps my f key isn't working.  Nope, there it is, can't use that
> excuse.
>
> Wrist slap humbly accepted -- but I assure it it was a typo, not a
> thinko.

     A reudian slip, no doubt.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web