scanf behaviour

[Richard Bos]

The Solaris version makes a fair amount of sense to me as well. C's
fflush() function doesn't *have* to follow the exact semantics of a
toilet.

Just as well; I wouldn't want my computer to sound like that every time
I write a line to a file.

In Solaris, fflush(stdin) discards any buffered input. If C defined a
discard_buffered_input() function, I don't think anyone would object
-- at least not on the same basis on which you object to
fflush(stdin).

Not entirely. However, I would still object, as I would also for
fflush(stdin), on the basis that discarding buffered input is not always
as easy as it seems. There's buffered and there's buffered; there are C
implementation buffers, and there are hardware buffers; IOW, it would
have to be quite strictly circumscribed to be implementable, and it's
not certain how useful such a limited flushing function would be.

Contrast this with an implementation-defined flushing function, which
can be useful for that implementation only, and ignore problems that
would occur on other hardware and/or OSes.

Richard

 

[John Bode]

I've tested "fflush( stdin );" on both WinXP and SunOS boxes it works
without a glitch.

Now try it on MacOS (classic and X), OS/2, AIX, HP-UX, Irix, OpenVMS,
MPE, OS-360, BeOS, embedded systems, etc., and tell us if it works
without a glitch on all of them.

The implementation doesn't define the language. An implementation
*may* choose to do something reasonable for fflush(stdin), but you
cannot rely on that being true for any arbitrary implementation.

 

[Dik T. Winter]

Note that if stdin is connected to a tty or a pipe, fflush is undefined
on Solaris! Solaris defines flushing an input stream only when it can
make sense, i.e. if is seekable (for instance a disk file).

> Not entirely. However, I would still object, as I would also for
> fflush(stdin), on the basis that discarding buffered input is not always
> as easy as it seems. There's buffered and there's buffered; there are C
> implementation buffers, and there are hardware buffers; IOW, it would
> have to be quite strictly circumscribed to be implementable, and it's
> not certain how useful such a limited flushing function would be.

Indeed.

 

[av]

i know i'm for you a ungly troll but what is the reason why it is not
possible (or 'good' for the standard C) to have a buffer of 256 chars
for FILE?
i remember i have a buffer of +-256 chars for FILE object and ungetc
if > +-256 ungetc return fail
what is the problem with all this (have a buffer of 256 chars for FILE
object that all input/output function can to use)[oltre a non essere
"standard C"]? thank you

i would like to say that the buffers that use get, fgetc and
almost all the input fuctions, buffers that are in the "FILE" struct
can be view (from me) in this way

-Size_buf 0 Size_buf
|----------|----------|

where at start "base" pointer point to "0".

if Size_buf>1 (like all my input-file-buffers) => ungetc can
unget more than 2 chars

where is the wrong in all this?
Yes i could unget chars that are not in the original file, but...

for input-output
i have to say i don't use fscanf, or scanf, and i use many
"specializzate" functions getline "like" (for get lines in many ways)
"specializzate" functions for get unsigned, int, double from FILEs
and a "sscanf" function.
for print i use printf like function
and sprintf like function (that use the len of buffer for not allow
programmer to write out of buffer)

 

[Mark McIntyre]

My drivers' manual claims this leads to undefined behaviour. But
I've tested it across both the Atlantic and the English Channel
and it works fine over there.

You *drove* across the atlantic and the english channel? Wow, didn't
your carburettor flood?

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Richard Heathfield]

Mark McIntyre said:

You *drove* across the atlantic and the english channel? Wow, didn't
your carburettor flood?

<grin> Okay, you're forgiven for the time being. That was worth it.

 

[Keith Thompson]

Note that if stdin is connected to a tty or a pipe, fflush is undefined
on Solaris! Solaris defines flushing an input stream only when it can
make sense, i.e. if is seekable (for instance a disk file).

[...]

I hadn't noticed that (I didn't pay a lot of attention to the man page
because I don't particularly need to flush input files).

What I had in mind was something I've done in the past (not in C),
namely:

Print a prompt for user input
Flush input
Read the user's response (from the keyboard)

The point of flushing input is to discard any characters the user
typed before the prompt appeared, for example if the user is familiar
enough with the program to type responses ahead of time, but the
prompt may not be one the user was expecting. (This was possible on
the systems I was using at the time; it may not be practical on more
modern systems.)

But apparently the Solaris fflush() doesn't support this usage. I'm
not sure what the point of flushing an input stream connected to a
disk file would be.

If flushing an input file does make sense on a given system, it should
probably be provided as a separate implementation-defined function.
The fact that Solaris extends an existing standard function causes
confusion. But I think we've established that Solaris does this for
backward compatibility with old SolOS systems that predate the ANSI C
standard (somebody mentioned SunOS 4.1.3, whose default C compiler was
pre-ANSI).

 

[Dik T. Winter]

....
> What I had in mind was something I've done in the past (not in C),
> namely:
>
> Print a prompt for user input
> Flush input
> Read the user's response (from the keyboard)
>
> The point of flushing input is to discard any characters the user
> typed before the prompt appeared, for example if the user is familiar
> enough with the program to type responses ahead of time, but the
> prompt may not be one the user was expecting. (This was possible on
> the systems I was using at the time; it may not be practical on more
> modern systems.)

Yes, but with modern systems it is barely possible to define such a function.
Especially when you are connected to a computer through a network. Should
the computer where the fflush is executed signal the computer from which it
receives its input to also do a fflush? It is possible when the user input
does not go through a whole lot of layers, and that is with modern computers
almost never the case.

 

[Dave Thompson]

(e-mail address removed) wrote:

But since you're here just looking for a positive integer there's
the following alternative:

char buffer[10];
int x ;

do {
printf( "Please enter positive number\n" );
while ( scanf( "%9[^-+0-9]", buffer ) != 0 )
/* empty */ ;

Instead of a loop you can just do /*(void)*/scanf ("%*[-+0-9]");

But ranges like 0-9 in a %[ specifier are impl-def, so technically you
should spell out 0123456789 (or some permutation thereof).

} while ( scanf( "%d", &x ) != 1 || x <= 0 );

- David.Thompson1 at worldnet.att.net