X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f X-Recipient: djgpp-workers AT delorie DOT com Message-ID: <53555BFD.4000202@gmx.de> Date: Mon, 21 Apr 2014 19:57:17 +0200 From: Juan Manuel Guerrero User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: djgpp-workers AT delorie DOT com Subject: Re: ctime.c changes add about 4.5k more size References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:En99oBnpJmU2Vw5VH1cB7+dJIGCX9cxbQwXfuC76qlKREooS9u9 rENHI37KcfPG/TmOEqThcUycUw1vT1Tg6rZQ/RqU8N0Kr9B0PVfjJHRAGhnxmN1AH9BW0d0 3j4wQsWe6Y+HmXTGsgNEwfQ7IRq5s8TX8yhpcG2oodGTIhV9FVB21s1ZwYNrLlzCH+h2rDW L3fm88zhDZR55QFDPm9rg== Reply-To: djgpp-workers AT delorie DOT com Am 21.04.2014 08:44, schrieb Ozkan Sezer: > Recent(ish) src/libc/ansi/time/ctime.c changes add about 4.5k more > size to the final stripped binary: > > #include > int main () { > return time(NULL); > } > > Linking against v2.04 from 2011-10-01 gives a 91648 bytes a.exe, > whereas linking against v2.04 from 2014-04-20 gives a 96256 bytes > a.exe. (not mentioning at all the crazy sizes themselves which is > irrelevant to the present case at hand.) A "return 0" instead of > a "return time(NULL)" yields a 52736 bytes exe, so ctime.c stuff > is adding about 43k size. > > time() calls gettimeofday() which calls 0x2c and 0x2a dos functions > and calls ctime.c::mktime() where the additional bloat happens. > > Is there no other way of reducing the code size here? > > -- > O.S. The ctime code in v2.04 from 2011-10-01 and before is broken in different ways. It does not make too much sense to go into details but the failures in the code will only become visible to those users that expect full featured time zone support from djgpp as it used to be a decade before. The time zone database format has changed so that the original ctime code of djgpp (code before 2011-10-01) had to be replaced (aka ported) by the ctime code provided by time zone source code. This may have introduced some "bloating" but this bloating is the price to be paid if djgpp shall still provide full featured time zone support. BTW I am working on a port of tzcode2014[b|d].tar.gz. I mention this because this version introduces on new format more that needs to be supported. This will certainly modify ctime code again, probably "bloating" it even more. If someone can optimize the ctime code for speed and size, that changes will always be welcome; but I do not think that optimization for size should be done sacrificing/removing time zone features that other users expect to be provided by djgpp. Regards, Juan M. Guerrero