X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f X-Recipient: djgpp-workers AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=GvDhX+wxusuVfTfdwfEBOWMjzyrmC/zmqnH1nD+2ge4=; b=MzEJX0KRLCSq6rSry+Jo9O4MXJhxe3tblqYyrHjVs0XLE6dFnda/wVzdlhh1kwcQ4u 1T0q3fs7pgODy1UgHCEm8QxIr5cU7FB+9Q3EQ+ypdl47hZ0fklAgVdTYW/mWIA8I2mp8 Cvddm6JQubeEpZpPxKPTFe1tUU0JL1lN3TKoG4XfvRBPaia/vcIQ4qXwfBiGJKupIT9z 4woIL6bfP4EdqZ/EqCl3pVWsGWFt52+zVlV7ipBeYs5gS0LJyaVtyqQtCJsgSCVS8pyz KvJlyRut1sGxQCotD7Kk1EkABiXAoBcmsDOuZRcOshaoohA2ZAsvBIsfNRnLlUnEaUAF 3oQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GvDhX+wxusuVfTfdwfEBOWMjzyrmC/zmqnH1nD+2ge4=; b=ZTLSRVvGKa1TZMN5w3w4RBFgQShZ8sXF0UHnr521qNWzlCbLCWGJJVGv1oKp8cniJg zDbq7RhGPKo516k+KaZHNUQiZNoeAc4y1RolBSzf6h9PYLFdRUyveoSoVCPceE32oaoD p/UX/fl5v2OA0cwp+PJDPGW4L9h7EKSxeu0SLYKSQGwM4R1lIY4HNyAc4b5KPYiEHaos uXoHnjeeJBdRS3TdxlOY4cX69g95/ufXFkMlszJVBo7BmrH7F0gHTCtUAgSAPS10BddJ I9ait9KxBU/ghntQSnUZze03IcLayS7OznNc4Lbadl2NMSqWyCCcfeuxByer262vczil q5MA== X-Gm-Message-State: AEkoouvGOECQJWgm3/y0ATxPPCapBoEQmHV6gOIBhJHTb7dPvblAsdC/3/dFQbaKCz3DDbu9+gEVZcz+a0gC5g== X-Received: by 10.31.8.147 with SMTP id 141mr28158826vki.33.1470500633929; Sat, 06 Aug 2016 09:23:53 -0700 (PDT) MIME-Version: 1.0 From: "Rugxulo (rugxulo AT gmail DOT com) [via djgpp-workers AT delorie DOT com]" Date: Sat, 6 Aug 2016 11:23:53 -0500 Message-ID: Subject: linking more bloat from ctime.c To: djgpp-workers AT delorie DOT com Content-Type: text/plain; charset=UTF-8 Reply-To: djgpp-workers AT delorie DOT com Hi, guys, (Okay, so this isn't a hugely critical issue, nor a priority, so please don't think I'm complaining. I just wanted to mention it for completeness.) We've already discussed the bloat of ctime.c several times over the years. The most recent discussion was two years ago (2014/04/21), from Ozkan Sezer, titled "ctime.c changes add about 4.5k more size". (I found that entire thread chain by searching my email archives and then further searching on http://www.delorie.com/djgpp/mail-archives/search.cgi with the keywords "+crazy +changes +mktime".) http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-workers/2014/04/21/02:44:35 Here's the real problem: *printf (or, more specifically, doprnt.o). A lot has changed since 2.03p2. One very simple test of mine showed this: (2.03p2): LITE EXE 44,032 SCANF EXE 47,616 PRINTF EXE 51,712 BOTH EXE 55,296 (2.05): LITE EXE 72,192 SCANF EXE 84,480 PRINTF EXE 89,088 BOTH EXE 100,352 Yes, I know, hard drives are cheap. And of course 99% of all C programs actually need and want to use *printf. But, even acknowledging that, I think it's a mistake to link in the full doprnt.o just for a single line in an (here by me) unused routine in ctime.c by default. // === badprint.c begins === /* re: DJGPP 2.05 (DJDEV-/DJLSR205.ZIP) ... I only want a simple call to time(), but that needs gettimeofday(), and gettimeofday() needs mktime() and localtime(), both of which are included inside ctime.o !! We must stop ctime.o from pulling in sprintf()'s (bloated) doprnt.o !! text data bss dec hex filename 10832 2644 14464 27940 6d24 ctime.o 15712 188 8 15908 3e24 doprnt.o sprintf() is called by asctime_r(), which itself is called by asctime(), but ctime() also calls asctime() and ctime_r() also calls asctime_r() !! The single offending sprintf format string is as follows: "%.3s %.3s%3d %02d:%02d:%02d %d\n" This should be easy to simulate without needing to include the full doprnt.o !! */ #include int sprintf(char* buffer, const char* format, ...) { fputs("Someone is calling me??? I'm a (fake) sprintf() stub!!!",stderr); return 0; } // === badprint.c ends === P.S. In one minimal program of mine, the solution I found recently was to not use time() at all (for srand() ), instead relying on (non-standard!) Turbo C's gettime(), which doesn't need all the bloat (since I was already avoiding printf() there as unnecessary). My point is that I assume ctime.c can be "fixed" to not need sprintf() at all, which would be more ideal than either of these kludges, right?