This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch, libfortran] PR44931 For INPUT_UNIT, INQUIRE NAME= should not return "stdin"
- From: Tobias Burnus <burnus at net-b dot de>
- To: Thomas Koenig <tkoenig at netcologne dot de>
- Cc: Jerry DeLisle <jvdelisle at verizon dot net>, gfortran <fortran at gcc dot gnu dot org>, gcc patches <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 25 Jul 2010 11:39:46 +0200
- Subject: Re: [patch, libfortran] PR44931 For INPUT_UNIT, INQUIRE NAME= should not return "stdin"
- References: <4C4B8BA3.2070202@verizon.net> <4C4BFD27.806@net-b.de> <1280049543.4506.3.camel@linux-fd1f.site>
Thomas Koenig wrote:
> Tobias Burnus wrote
>> Besides, I wonder whether using "" as string is better than using the
>> default std{in,out,err} in case ttyname fails. (This happens for
>> instance if the standard I/O redirected to a file or pipe.)
>>
> For Linux, we could return /proc/self/fd/1 for standard output (0 and 2
> correspondingly). This appears to work, as this little program shows:
>
Well, I think using /dev/std{in,out,err} is more portable than
/proc/self/fd/{0,1,2}. However, the question is whether those device
files are just common or truly ubiquitous on non-Windows GCC platforms;
I fear they are just common. I have checked the File Hierarchy Standard
it it does not specify anything under /dev/*. One could (on non-Windows)
of course check the existence of "/dev/std*" and if it does not exist
fall back to ttypname and if it also fails (or HAS_TTYNAME is not
defined) fall back to "". But the question is whether one should do so
much effort - most of the time one simply uses the units without
INQUIREing the filename - to (re)open the standard I/O streams.
(Side note: The 0,1,2 numbers are defined in POSIX; they are the values
of the unistd.h's symbolic constants STD{IN,OUT,ERR}_FILENO.)
Tobias