DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=pUPXbT3JsKGXnJ8uApI1bDnLpzqT7c8izYuac8nY3LzEdjPt/780LlqpkDqgYnFEge
         ZaTbSE6trYLCAlCzUpf8cvMhXwdQK9pFRAz2F9ma7K/ZOEwun2cHtgrKhNzY7axPTVmt
         ohL6BGOXK6WSTq5Lf4iZF228ZG0qwgIYpSqa8=
MIME-Version: 1.0
Date: Sat, 18 Jul 2009 08:26:25 -0500
Message-ID: <93c172b50907180626q4fd57d58h8ac1f502c0cb1a1a@mail.gmail.com>
Subject: mkdir.c -> access.c -> is_exec.c -> xstat.c -> (bloated) ctime.c == 
	not necessarily a good idea (wastes 7k)
From: Rugxulo <rugxulo AT gmail DOT com>
To: djgpp-workers AT delorie DOT com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hey guys,
   I hope I don't describe this incorrectly, and I hope you don't
think I'm wasting your time, but ...

See, I'm trying to recompile the ANSI C .7z decoder (LZMA method only
... aka, 7zdec) from LZMA SDK 9.04. It added mkdir() support, which
means now "x" works (unpack with dirs), hence I don't have to bundle a
.tar inside a .7z anymore. And I'm even using 2.03p2 (smaller) and GCC
2.95.3 since it seems to output smallest (-O -mcpu=i686
-malign-jumps=2 -malign-loops=2 -malign-functions=2), upx
--ultra-brute --small 7zdec.exe, stubx -s 7zdec.exe (D3X is only 10k).
I even hacked out the parts of doprnt.c that aren't %s or %d just to
decrease the size some more (using a local copy, saved approx. 4k).

My previous build (before mkdir was supported), e.g. 4.65, was 42k
with all the above tricks. That's pretty small, I thought.

However, once mkdir() was added to the fold, the size went up 20% (!)
to 52k and yet my OpenWatcom build only increased 1k! Now, I know
DJGPP supports LFNs, but I didn't think that would add 10k extra. So,
several times, I took a look in the map file ("-Wl,-Map", I think).
Yet I never could find anything ... until now.     :-D

For the record, this is the biggest module pulled in:

-rw-r--r--    1 dosuser  root        12436 Jul 18 08:02 ctime.o

But how does mkdir() use this??

Apparently, mkdir() calls access() which calls _is_executable() which
needs _djstat_flags from xstat.c whose _file_time_stamp() function
*always* pulls in mktime() (from ctime.c) even though not used in this
case.

IMHO, the _file_time_stamp() function should be put in a separate .o
module in libc.a for 2.04 final (or whatever) so as not to pull in the
big ol' bloated ctime.o for no good reason.

P.S. I know this is pretty minor and not worth anything to most
people, but size does matter in this case: I wanted to be able to cram
that "old" GCC 2.95.3 EZGCC-ish .7z I made onto a single 1.44 MB
floppy, and I also was picky enough to also want an unpacker on the
same disk, hence I needed something small.

-rw-r--r--    1 dosuser  root      1390638 Jun 27 13:50 ../../dj203/djgpp203.7z

     46468   7/18/2009    7:52:37 AM
c:\Armslurp\temp\moo\7zdec\7zdecdj2.exe      (new 9.04 build)
     52384    6/9/2009    3:34:53 PM   c:\Armslurp\utils\7zdecdj2.exe
                       (old 9.04 build)
     42572    5/23/2009   7:13:04PM
c:\Armslurp\zips\pack\7zdec.old:7zdecdj2.exe   (older 4.65, without
mkdir)


1390638+52384=1443022

In other words, very very close to the limit (~1456000), and I didn't
like that !! Luckily, OpenWatcom 39k build is acceptable since I don't
need LFNs anyways. But hey, this is DJGPP I'm trying to pack, and it
does build its own unpacker, just not ideal in size! So I just had to
look for an answer, DJGPP is too good to ignore.   ;-)

But now I think I found the problem, so I'll keep this in mind. Maybe
you should too.   ;-)