From owner-freebsd-hackers Fri May 3 12:57:12 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA07760 for hackers-outgoing; Fri, 3 May 1996 12:57:12 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA07752 for ; Fri, 3 May 1996 12:57:08 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id FAA15358; Sat, 4 May 1996 05:47:03 +1000 Date: Sat, 4 May 1996 05:47:03 +1000 From: Bruce Evans Message-Id: <199605031947.FAA15358@godzilla.zeta.org.au> To: imp@village.org, rpt@miles.sso.loral.com Subject: Re: stdio problem Cc: freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >: The "assumption" that 'fd 0 == stdin at entry to main()' is no longer >: valid! >It *MUST* be valid. It is how Unix works. The *SHELL* sets these >things up, No, the parent process sets things up. >so how does one find out what to use if 0 isn't it? Using stdin is in the state that it would be in if it were opened by fdopen(STDIN_FILENO, "r"). This state is [f]closed if the file is closed or unreadable. >stdio isn't an answer here, because I must be able to find this out >w/o ever touching stdio. fcntl(STDIN_FILENO, F_GETFL). >When main() is entered 0, 1, and 2 are already open *BY*THE*SHELL* >that fork/exec'd the program. stdio doesn't actually do an open(2) on >0, 1, 2. It merely maps them to std* to 0, 1, 2. It's broken. It has to do what fdopen() would do. >It has no way of >knowing what to open so must always use 0, 1, and 2. I'd be very very >surprised if you could come up with a program where fileno(stdin) != >0. Please post it. fileno(stdin) == STDIN_FILENO is specified by POSIX, at least if stdin hasn't been freopen'ed. >C++ static object constructors should be able to access stdin, et al. >Any C++ implementation that does not allow this is broken and should >be fixed. The fdopen()s should probably be done in an early constructor. The current approach is better suited to producing small (< 1K) executables. Bruce