Date: Sat, 4 May 1996 09:26:07 -0400 (EDT) From: Richard Toren <rpt@miles.sso.loral.com> To: freebsd-hackers@freebsd.org Subject: Re: stdio problem Message-ID: <Pine.SUN.3.91.960504084949.12982B-100000@miles>
next in thread | raw e-mail | index | archive | help
Ok;
I am not a kernel maintainer.. But I am a unix programmer. This all
happened using the CenterLine C++ package on SunOs 4.1.3 about 2.5 years
ago. The following is from memory. One portion of the code I was writing
for the project was the common routine for spawning off a daemon process.
I had collected the combined wisdom from the Sun manuals, Commers TCP
books, and Stevens networking.
In one piece of the code, there were the classic lines to close 0,1,2 and
then create a new set for the child. The rest had to do with the control
terminal and the process group (blah,, blah, blah).
What we found (in just one case) in the child process was that the printf
commands that were to be going to stdout were ending up in our disk log
file. So I did some forensic checking by opening /dev/console, and
printing debug info explicity to the console with fprintf. This was done
in the parent program before any of the daemonizing code was run. The
value of 'fileno(stdin) == 1'. So I just substituted
'fclose(fileno(stdin))' for fclose(0) and everything worked fine.
Looking at what was happening at the program startup (prior to calling
main()) was that the static initializer of a class called AnAtom was
calling the logging class (LogFile) in its static initializer. The static
service in the LogFile class checked to see if it's constructor had been
run. If not, a temporary log file was opened, and later copied into the
real logfile by it's ctor.
In this case, it seemed obvious that LogFile had opened fd 0 before the
crt0 routine had had a chance. I had seen the warning about not making
any assumptions about the ordering of static initializers, and that the
iostream package may noy yet be initialized.
As I said; I am not a kernel maintainer, just a programmer. But NOT
assuming fd 0 == stdin was proven correct and prudent from that point
onward. If different OSs and compilers do things differently, so be it.
But if the system supplies a way to obtain system data through an
abstraction; that would always seem to be the proper (more portable) way
to get it.
====================================================
Rip Toren | The bad news is that C++ is not an object-oriented |
rpt@miles.sso.loral.com | programming language. .... The good news is that |
| C++ supports object-oriented programming. |
| C++ Programming & Fundamental Concepts |
| by Anderson & Heinze |
====================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.960504084949.12982B-100000>