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

[Freddie Chopin]

W dniu 2013-11-08 18:16, Gregory Pietsch pisze:
> The only problem with using fiprintf() is that it is non-standard. I've
> seen the error strings printed out with pure write() calls to stderr.
> The fputs/fputc idea is interesting. -- Gregory

You've forgot to CC the list, so I'm including it again.

Yes, fiprintf() is non-standard, but newlib has it, I see no option to 
disable it, so in my opinion it's a safe change.

Using something more low-level (fputs()/fputc() or even write()) seems a 
nice idea, but it will look a bit "wrong". For example take this line, 
longest f[i]printf() call in getopt():

> 			fiprintf (stderr, "%s: option `%s' is ambiguous "
> 				 "(could be `--%s' or `--%s')\n",
> 				 argv[0],
> 				 argv[data->optind],
> 				 longopts[longopt_match].name,
> 				 longopts[optindex].name);

To use fputs()/fputc() you'd need 8 separate calls:

> 	fputs(argv[0], stderr);
> 	fputs(": option `", stderr);
> 	fputs(argv[data->optind], stderr);
> 	fputs("' is ambiguous (could be `--", stderr);
> 	fputs(longopts[longopt_match].name, stderr);
> 	fputs("' or `--", stderr);
> 	fputs(longopts[optindex].name, stderr);
> 	fputs("')\n", stderr);

This is the longest and most complex message - others are smaller, but I 
guess each would take 3-4 calls on average (some messages can probably 
be reworded a bit to be easier to do this way). Fine for me (given the 
huge code space and RAM saving), but I don't know whether it's fine with 
newlib's maintainers (;

Regards,
FCh