From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<9607301546.AA17719@clio.rice.edu>
Subject:	Re: USE_LFN woes
To:	eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date:	Tue, 30 Jul 1996 10:46:34 -0600 (CDT)
Cc:	djgpp-workers AT delorie DOT com
In-Reply-To:	<Pine.SUN.3.91.960730180445.660G-100000@is> from "Eli Zaretskii" at Jul 30, 96 06:09:03 pm

> As for the code bloat, `getenv' is already in every image (the start-up
> code calls it), so the add-on is minimal.  But I'll see what can be done
> to make it still smaller. 

It's not just a code bloat issue (this is probably a single variable flag
in putenv()).  It's also a complexity issue - trying to maintain and 
modify the code in the future with all sorts of unknown side effects.
When you add hacks to something like libc to work around bizzare or 
buggy behavior of some app, you are leaving a landmine for some future
change to explode.  Why not just fix EMACS instead of making libc
unfollowable by mortals?  I get ill each time I look at the bss_count
crap.  It didn't add much size, but it certainly made the code
harder to understand.  I would much rather create a "startup" section
and make intialized static variables illegal in the libc (it would also make
the reentrancy stuff easier too).

If making libc unreadable is fair game, lets put the I/O caching 
I wrote for the alpha back in.  On common back to back functions
like opendir/readdir/stat we could cut the mode swaps/dos calls by
a factor of 3.  It made my directory scanning code very fast.  Also
made DJ puke at it's complexity (global flag hell).

(Oh, just ignore me, it's one of those days :-)

- Raw text -