[PATCH] getopt.c: use integer-only function fiprintf() to save code space

[Craig Howland]

On 11/08/2013 11:57 AM, Freddie Chopin wrote:
> Hello!
>
> If you use getopt() (or any variant of this functionality) it pulls in 
> fprintf() to do output to stderr in case of error. As getopt() does not deal 
> with anything but strings or characters, it's much better to use fiprintf(), 
> which is MUCH smaller than fprintf() - about 2.8kB for _vfiprintf_r() vs. 
> 6.5kB for _vfiprintf_r(), not counting any support data/functions (like 4.5kB 
> _dtoa_r()), ARMv7-M. If your program does not use fprintf() just using getopt 
> increases the size of the executable by 20kB (size of getopt() alone is ~2kB). 
> Let's not forget RAM use, which is smaller in fiprintf().
>
> Actually I think that the output could be done with fputs() and fputc() only, 
> but to do that I'd first like your opinion - there's no actual formatting 
> (like changing the width or whatever), just displaying. This would be a bit 
> clumsy (2-7 calls to fputs()/fputc() in place of single f[i]printf()), but 
> still much MUCH smaller.
>
> Regards,
> FCh
      Since size is the motivation for changing, so what if it is more clumsy?  
On MicroBlaze, _fputs_r is 284 bytes versus 7720 for _vfiprintf_r.  (Quoting the 
size for the object files which include those functions.)  This method could 
also have the potential advantage of not pulling in fiprintf for people who are 
using fprintf--which would be a possible hidden cost of this change. (There is 
also an intermediate case where it could reduce the cost increase from the 
addition of fiprint to the addition of fputs.)
      It's an interesting question as to which approach would be faster.  
(fputs() is much simpler, but the additional function call overhead is hard to 
judge without an experiment.  But I'd guess fputs() would probably be faster, as 
well as smaller.)
      I'd say go all the way.  It would, however rate a comment in the file 
explaining the clumsiness.
                 Craig