Date: Sat, 4 May 1996 05:47:03 +1000 From: Bruce Evans <bde@zeta.org.au> To: imp@village.org, rpt@miles.sso.loral.com Cc: freebsd-hackers@freebsd.org Subject: Re: stdio problem Message-ID: <199605031947.FAA15358@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>: 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605031947.FAA15358>