Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: When parameters to printf are in memory |
| Date | 2016-10-01 09:08 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <nsnqsn$lsj$1@dont-email.me> (permalink) |
| References | (5 earlier) <nsjvj1$4c2$1@dont-email.me> <nsk1e9$ai1$1@dont-email.me> <nsk3ic$kh3$1@dont-email.me> <nsmcbv$2cc$1@dont-email.me> <87r3816u6r.fsf@bsb.me.uk> |
On 30/09/2016 20:53, Ben Bacarisse wrote:
> James Harris <james.harris.1@gmail.com> writes:
> <snip>
>
>> If I omit the size checking for now, how about something like this:
>>
>> for (;;) { /* Each pair of non-format, format */
>>
>> /* Copy normal characters straight to the output buffer */
>> while (*src != '%' && *src != '\0') {
>> *dest++ = *src++;
>> }
>> if (*src == '\0') {
>> break;
>> }
>>
>> /* Copy the format string (starting with %) to a format buffer */
>> format = format_buffer;
>> *format++ = *src++;
>> if (*src == '%') { /* If the source has %% */
>> *dest++ = '%';
>> }
>> else { /* A single percent sign, i.e. starting a format spec */
>> for (;;) { /* Until a terminating character */
>> ch = *src++;
>> if (ch == '\0') ....error....;
>> *format++ = ch;
>> if (ch ....is one of the terminating characters....) break;
>> }
>> *format = '\0';
>>
>> /* Format an argument */
>> bytes = sprintf(dest, format, ....current arg ++....);
>
> The trouble with this is that the type might be wrong. I know you are
> not aiming at totally portable code here, but there could be real
> problems when there is a significant mismatch between the array member
> type and the conversion specifier. Worse, you may need to consider the
> length modifier too.
That's always the case in C with varargs, isn't it?
I know some compilers can report type mismatches in the common case of a
printf string literal and some args. But they cannot match in every
case. The va_arg() macro has to have the expected type applied to it.
>> dest += bytes;
>> } /* end else */
>> } /* end for */
>> *dest = '\0';
>>
>> Terminating chars: diouxXeEfFgGaAcsp%
>>
>>> Even there, there are some tricky formats, if you plan to deal with all
>>> of them, such as "%.*s" which requires /two/ operands, one for "*" and
>>> one for "s".
>
> (and %*.*s which needs three)
>
>> Thanks. I wasn't aware of *. I knew I would have to reject n.
>
> I'm not sure why you must reject n. It may not be useful in your
> specific use case, but I think it should work with the above outline
> like any other conversion.
It could be parsed. But for what I want to do there would be no sense in
executing it.
I started down this road basically thinking to use snprintf as an easy
way to plug rendered values into an error message. After all, it's built
for just such an operation. And it is usually easier to use a built-in
facility than writing one from scratch.
But given the complexities of the printf calls (arguments cannot come
from memory, not all conversions supported on all versions of C, issues
over value widths, not extendable, special conversions, no clear
delimiter, etc) a custom solution might be better. It would be more to
think about, and more to write. But possibly less work in the long run,
and more flexible.
--
James Harris
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-29 16:20 +0100
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-29 16:43 +0100
Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-29 20:30 +0100
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-29 21:23 +0100
Re: When parameters to printf are in memory BartC <bc@freeuk.com> - 2016-09-29 22:03 +0100
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-29 22:35 +0100
Re: When parameters to printf are in memory BartC <bc@freeuk.com> - 2016-09-29 23:11 +0100
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-30 19:53 +0100
Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-30 20:53 +0100
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-01 09:08 +0100
Re: When parameters to printf are in memory BartC <bc@freeuk.com> - 2016-10-01 11:15 +0100
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-04 08:32 +0100
Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-01 11:15 +0100
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-04 08:28 +0100
Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-04 09:49 +0100
Re: When parameters to printf are in memory BartC <bc@freeuk.com> - 2016-10-04 11:43 +0100
Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-04 13:42 +0100
Re: When parameters to printf are in memory BartC <bc@freeuk.com> - 2016-10-04 14:03 +0100
Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-04 14:16 +0100
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-04 20:01 +0100
Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-04 20:24 +0100
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-04 20:40 +0100
Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-04 22:51 +0100
Re: When parameters to printf are in memory "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-04 14:25 -0400
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-04 20:31 +0100
Re: When parameters to printf are in memory BartC <bc@freeuk.com> - 2016-09-29 17:03 +0100
Re: When parameters to printf are in memory gazelle@shell.xmission.com (Kenny McCormack) - 2016-09-30 12:20 +0000
Re: When parameters to printf are in memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-30 05:55 -0700
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-30 20:06 +0100
Re: When parameters to printf are in memory gazelle@shell.xmission.com (Kenny McCormack) - 2016-09-30 22:01 +0000
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-01 09:15 +0100
Re: When parameters to printf are in memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-30 23:18 -0700
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-01 09:32 +0100
Re: When parameters to printf are in memory jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-29 18:35 +0200
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-29 19:55 +0100
Re: When parameters to printf are in memory jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-29 21:22 +0200
Re: When parameters to printf are in memory Barry Schwarz <schwarzb@dqel.com> - 2016-09-29 11:20 -0700
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-29 20:08 +0100
Re: When parameters to printf are in memory Lőrinczy Zsigmond <nospam@for.me> - 2016-10-02 20:15 +0200
Re: When parameters to printf are in memory Lőrinczy Zsigmond <nospam@for.me> - 2016-10-02 20:19 +0200
Re: When parameters to printf are in memory gazelle@shell.xmission.com (Kenny McCormack) - 2016-10-02 18:29 +0000
Re: When parameters to printf are in memory Lőrinczy Zsigmond <nospam@for.me> - 2016-10-03 07:04 +0200
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-04 08:36 +0100
Re: When parameters to printf are in memory jacobnavia <jacob@jacob.remcomp.fr> - 2016-10-02 21:27 +0200
csiph-web