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: from "Eli Zaretskii" at Jul 30, 96 06:09:03 pm Content-Type: text > 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 :-)