From owner-freebsd-hackers Sat May 4 06:28:08 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA05333 for hackers-outgoing; Sat, 4 May 1996 06:28:08 -0700 (PDT) Received: from wdl1.wdl.loral.com (wdl1.wdl.loral.com [137.249.32.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA05328 for ; Sat, 4 May 1996 06:28:06 -0700 (PDT) Received: from miles.sso.loral.com (miles.wdl.loral.com) by wdl1.wdl.loral.com (5.x/WDL-2.4-1.0) id AA25450; Sat, 4 May 1996 06:27:40 -0700 Received: by miles.sso.loral.com (4.1/SSO-SUN-2.04) id AA13034; Sat, 4 May 96 09:26:08 EDT Date: Sat, 4 May 1996 09:26:07 -0400 (EDT) From: Richard Toren X-Sender: rpt@miles To: freebsd-hackers@freebsd.org Subject: Re: stdio problem Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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 | ====================================================