This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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",

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 (;


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]