fflush(stdin) vs fflush(stdout)
Paul Lutus
Yes. You are using a nonstandard function. The point of the thread was to
make this clear. You cannot use fflush(stdin) in standard C or C++. If
someone creates a function that does this, it will turn out to be
non-portable.
--
Paul Lutus
www.arachnoid.com
Alex Vinokur wrote in message <7gok52$mkk$1...@nnrp1.dejanews.com>...
<snip>
Alex Vinokur
"Chris Newton" <ca...@spamfree.cam.ac.uk> wrote:
[snip]
> The standard defines fflush(stdin) to give undefined behaviour.
[snip]
Hi,
============
=== tcflush
============
Now there exists the tcflush () function :
flush non-transmitted output data, non-read input data or both.
See man tcflush on SunOS 5.6 and HP-UX B.10.20.
============
=== But ...
============
The same program was compiled on SunOS and HP-UX 10.
The program contains the tcflush (...) function.
But for some reason the results of the running
on SunOS and HP-UX 10 are different.
The program works OK on SunOS,
but it seems it isn't OK on HP-UX 10.
Does anybody know what is wrong?
Thanks in advance,
Alex
//#########################################################
//------------------- C++ code : BEGIN -------------------
#include <string>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <termios.h>
int main(void)
{
string s1;
while (1)
{
switch (tcflush(0, TCIFLUSH))
{
case 0 :
// OK
break;
case 1 :
cout << "FATAL ERROR : "
<< (strerror (errno))
<< endl;
exit (1);
break; // unused
default :
abort ();
break; // unused
} // switch (tcflush(0, TCIFLUSH))
cout << "Enter : ";
cin >> s1;
cout << "\tValue = " << s1 << endl;
sleep (5);
}
return 0;
}
//------------------- C++ code : END ----------------------
//#########################################################
//------------------- Running Results : BEGIN -------------
//------------------- SunOS -------------------------------
//=== Running ====
%a.out
Enter : aaaaa // aaaaa is input data
Value = aaaaa
bbbbb // bbbbb is input data
ccccc // ccccc is input data
Enter : ddddd // ddddd is input data
Value = ddddd
cntrl-c
//=== Conclusion ====
The data, received but not read, are flushed : bbbbb, ccccc
//------------------- SunOS -------------------------------
//------------------- Running Results : END ---------------
//#########################################################
//------------------- Compiler & System ------------------
//------------------- SunOS -------------------------------
g++ -v : gcc version egcs-2.91.57 19980901
(egcs-1.1 release)
uname -a : SunOS <nodename> 5.6 Generic_105181-09
sun4m sparc SUNW,SPARCstation-5
//---------------------------------------------------------
//#########################################################
//#########################################################
//------------------- Running Results : BEGIN -------------
//------------------- HP-UX -------------------------------
//=== Running ====
%a.out
Enter : aaaaa // aaaaa is input data
Value = aaaaa
bbbbb // bbbbb is input data
ccccc // ccccc is input data
Enter : Value = bbbbb // ???
Enter : Value = ccccc // ???
Enter : ddddd // ddddd is input data
Value = ddddd
cntrl-c
//=== Conclusion ====
No data are flushed.
//------------------- HP-UX -------------------------------
//------------------- Running Results : END ---------------
//#########################################################
//------------------- Compiler & System ------------------
//------------------- HP-UX -------------------------------
g++ -v : gcc version 2.8.1
aCC : HP aC++ B3910B A.01.06
HP aC++ B3910B A.01.01 Support Library
Note! The same results were obtained using both g++ and aCC.
uname -a : HP-UX <nodename> B.10.20 A 9000/847
1410304272 two-user license
//---------------------------------------------------------
//#########################################################
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Alex Vinokur
> make this clear. You cannot use fflush(stdin) in standard C or C++. If
> someone creates a function that does this, it will turn out to be
> non-portable.
I am not using fflush(stdin). My program contains the tcflush (...) function.
Plese see original message. The link is :
http://www.dejanews.com/[ST_rn=bg]/threadmsg_bg.xp?AN=474187850&fmt=raw
Alex
Paul Lutus
Yes! A nonstandard function. The point of my message was to alert you to the
fact that this nonstandard function is nonportable. That is why it works on
some compilers, but doesn't work on other compilers. It is not part of
standard C or C++.
--
Paul Lutus
www.arachnoid.com
Alex Vinokur wrote in message <7gorr4$tmn$1...@nnrp1.dejanews.com>...
<snip>
Martin Ambuhl
>
> In article <LpRX2.1104$YB4....@news2.giganews.com>,
> "Paul Lutus" <nos...@nosite.com> wrote:
> > << Does anybody know what is wrong? >>
> >
> > Yes. You are using a nonstandard function. The point of the thread was to
> > make this clear. You cannot use fflush(stdin) in standard C or C++. If
> > someone creates a function that does this, it will turn out to be
> > non-portable.
> [snip]
>
Wake up. Non-standard is non-standard. Why should POSIX functionality be given
a priviledged position denied the various DOS/Windows compilers that provide
users some action they might want with fflush(stdin)?
--
Martin Ambuhl (mam...@earthlink.net)
Note: mam...@tiac.net will soon be inactive
Martin Ambuhl
> Now there exists the tcflush () function :
> flush non-transmitted output data, non-read input data or both.
>
> See man tcflush on SunOS 5.6 and HP-UX B.10.20.
>
> ============
> === But ...
> ============
> The same program was compiled on SunOS and HP-UX 10.
> The program contains the tcflush (...) function.
>
> But for some reason the results of the running
> on SunOS and HP-UX 10 are different.
As you know, the tc* functions are POSIX, not ANSI. The necessary header is
<termios.h> is not a standard C or C++ header. All this suggests strongly that
you should be posting this to unix, hp, or sun newsgroup, rather than here.
Posix-specific functionality is just as much off topic as MsWindows-specific
functionality is.
Alex Vinokur
"Paul Lutus" <nos...@nosite.com> wrote:
> << I am not using fflush(stdin). My program contains the tcflush (...) >>
>
> Yes! A nonstandard function. The point of my message was to alert you to the
> fact that this nonstandard function is nonportable. That is why it works on
> some compilers
tcflush and others function are not functions of compiler)
> , but doesn't work on other compilers.
> It is not part of
> standard C or C++.
> --
I don't think
the different results of using tcflush (...) on SunOS and HP-UX
have to do with the fact
that the tcflush (...) function is a nonstandard one.
Yes, tcflush (...) is a nonstandard function.
But according to
man tcflush on SunOS and
man tcflush on HP-UX
the results of using tcflush (...) must be the same ones.
Example of using tcflush see in original message. The link is :
http://www.dejanews.com/[ST_rn=bg]/threadmsg_bg.xp?AN=474187850&fmt=raw
Thanks,
Alex
##################################################################
############## SunOS information (BEGIN) #########################
##################################################################
SunOS 5.6
Last change: 29 Dec 1996
##################################################################
man tcflush contains the following information :
================================================
NAME
tcflush - flush non-transmitted output data, non-read input
data or both
SYNOPSIS
#include <termios.h>
int tcflush(int fildes, int queue_selector);
DESCRIPTION
Upon successful completion, tcflush() discards data written
to the object referred to by fildes (an open file descriptor
associated with a terminal) but not transmitted, or data
received but not read, depending on the value of
queue_selector:
o If queue_selector is TCIFLUSH it flushes data received but
not read.
[snip]
RETURN VALUES
Upon successful completion, 0 is returned. Otherwise, -1 is
returned and errno is set to indicate the error.
[snip]
##################################################################
############## SunOS information (END) ###########################
##################################################################
##################################################################
############## HP-UX information (BEGIN) #########################
##################################################################
Hewlett-Packard Company
HP-UX Release 10.20: July 1996
##################################################################
man tcflush contains the following information :
================================================
NAME
tcsendbreak(), tcdrain(), tcflush(), tcflow() - tty line control
functions
SYNOPSIS
#include <termios.h>
[snip]
int tcflush(int fildes, int queue_selector);
[snip]
DESCRIPTION
[snip]
tcflush() discards data written to fildes but not transmitted, or data
received but not read, depending on the value of queue_selector:
+ If queue_selector is TCIFLUSH, data received but not read is
flushed.
[snip]
RETURN VALUE
Upon successful completion, a value of zero is returned. Otherwise, a
value of -1 is returned and errno is set to indicate the error.
[snip]
##################################################################
############## HP-UX information (END) ###########################
##################################################################
Martijn Lievaart
>
>I don't think
>the different results of using tcflush (...) on SunOS and HP-UX
>have to do with the fact
>that the tcflush (...) function is a nonstandard one.
>
>Yes, tcflush (...) is a nonstandard function.
>But according to
> man tcflush on SunOS and
> man tcflush on HP-UX
>the results of using tcflush (...) must be the same ones.
>
>Example of using tcflush see in original message. The link is :
>http://www.dejanews.com/[ST_rn=bg]/threadmsg_bg.xp?AN=474187850&fmt=raw
>
tcflush() is non-standard, so it may launch an ICBM as far as this newsgroup
is concerned. Please post posix questions to a posix group.
Martijn
--
My reply-to address is intentionally set to /dev/null
reply to <newsgroupname> at greebo.orion in nl
Paul Lutus
compiler) >>
Yes, they are, entirely. They can be placed in any compiler, on any
operating system. It is the compiler, not the operating system, that
supports or doesn't support a particular C or C++ language function.
--
Paul Lutus
www.arachnoid.com
Alex Vinokur wrote in message <7gpe77$c9r$1...@nnrp1.dejanews.com>...
<snip>
Dalibor Carapic
wrote in <wNZX2.1453$Xs1.1...@news1.giganews.com>:
><< (operating systems - ?; tcflush and others function are not functions of
>compiler) >>
>
>Yes, they are, entirely. They can be placed in any compiler, on any
>operating system. It is the compiler, not the operating system, that
>supports or doesn't support a particular C or C++ language function.
>
Alright so what you are saying is that all POSIX functions are in the compiler
and not in the operating system? Right...
Try using tcflush with non POSIX compliant system.
--
_______________________________________________________________________
Dalibor Carapic - Homepage: http://www.foi.hr/~dcarapic
Martijn Lievaart
>On Wed, 5 May 1999 08:50:50 -0700, Paul Lutus <nos...@nosite.com>
> wrote in <wNZX2.1453$Xs1.1...@news1.giganews.com>:
>
>><< (operating systems - ?; tcflush and others function are not functions
of
>>compiler) >>
>>
>>Yes, they are, entirely. They can be placed in any compiler, on any
>>operating system. It is the compiler, not the operating system, that
>>supports or doesn't support a particular C or C++ language function.
>>
>
>Alright so what you are saying is that all POSIX functions are in the
compiler
>and not in the operating system? Right...
>
Nooooooo, just that the tcflush() call surely is in a library somewhere. And
that library comes with the compiler. That tcflush() may in turn call the
tcflush systemcall on a posix system or something else on another system is
outside the scope of this discussion.
You confused posix systemcalls with C/C++ library calls that are an
interface to those systemcalls.
HTH,
Dalibor Carapic
wrote in <7gs08k$h...@news3.euro.net>:
>>>Yes, they are, entirely. They can be placed in any compiler, on any
>>>operating system. It is the compiler, not the operating system, that
>>>supports or doesn't support a particular C or C++ language function.
>>>
>>
>>Alright so what you are saying is that all POSIX functions are in the
>compiler
>>and not in the operating system? Right...
>>
>
>Nooooooo, just that the tcflush() call surely is in a library somewhere. And
>that library comes with the compiler. That tcflush() may in turn call the
>tcflush systemcall on a posix system or something else on another system is
>outside the scope of this discussion.
>
>You confused posix systemcalls with C/C++ library calls that are an
>interface to those systemcalls.
>
The library with interfaces to system API does not come with the
compiler.
Martijn Lievaart
> wrote in <7gs08k$h...@news3.euro.net>:
>
>>>>Yes, they are, entirely. They can be placed in any compiler, on any
>>>>operating system. It is the compiler, not the operating system, that
>>>>supports or doesn't support a particular C or C++ language function.
>>>>
>>>
>>>Alright so what you are saying is that all POSIX functions are in the
>>compiler
>>>and not in the operating system? Right...
>>>
>>
>>Nooooooo, just that the tcflush() call surely is in a library somewhere.
And
>>that library comes with the compiler. That tcflush() may in turn call the
>>tcflush systemcall on a posix system or something else on another system
is
>>outside the scope of this discussion.
>>
>>You confused posix systemcalls with C/C++ library calls that are an
>>interface to those systemcalls.
>>
>
>The library with interfaces to system API does not come with the
>compiler.
>
Hmm, my unix is getting rusty. You might be right, I might be and maybe
we're both partially right. Try for instance installing gcc on a non-Linuc
platform, I think it'll use it's own libraries. I can imagine that the line
blurs where the manufacturer of the unix is the manufacturer of the compiler
and I can imagine systems where you are absolutely correct.
However, as I said, it's all a bit rusty so I was talking from memory. In
restrospect I might be completely wrong. For most platforms I am sure I am
right, but unix and c might have another relationship to each other than on
other platforms.
However as this gets very off-topic for alt.comp.lang.learn.c-c++, let's
just leave it at that, whoever is right.