From: Rich Salz <[EMAIL PROTECTED]>

rsalz> There are some popular operating systems that don't let you do
rsalz>  FILE* fp = fdopen(getdtablesize(), "r")
rsalz> :)  Those are buggy C libraries -- even Sun has said it's a bug, just
rsalz> that they weren't going to fix it.

????  The above line strikes me as a typical fence-post error on the
part of the application author.  Now, if some other number than what
is returned by getdtablesize() was used, I'd understand a little
better.

(at least, it's my understanding that if getdtablesize() returns 256,
file descriptors 0 through 255 are valid, and if it returns -1, the
code above is bogus anyway)

rsalz> The question is how much work is involved for OpenSSL to be able to work
rsalz> around those bugs?  A quick grep for fopen and fdopen shows a handful of
rsalz> places, and for BIO_new_file shows a few more.

Can it be shown that there are bugs for normal use?  I do not consider
`fdopen(getdtablesize(), "r")' to be normal use...

rsalz> I'd suggest that all fopen and fdopen calls be replaced with BIO's, and
rsalz> that bio/bss_file.c be rewritten to use file descriptors, not FILE*'s,
rsalz> perhaps as a compile-time option.  (This would also remove the FILE* and
rsalz> win32 DLL issues)
rsalz> Anyone looking for a reasonable fgets-style interface on top of
rsalz> open/read can find in on INN... :)

Trust me, using open()/read()/write() and so on has it's own issues on
some operating systems when trying to deal with files that are
basically considered streams by the application but not the operating
systems.  stream functions (fopen() and friends) add a layer that
hopefully solves those issues in a consistent manner...

Also, have you looked at bio/bss_fd.c?

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \      SWEDEN       \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis                -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to