Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: When parameters to printf are in memory |
| Date | 2016-10-01 11:15 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <87y4285q9a.fsf@bsb.me.uk> (permalink) |
| References | (6 earlier) <nsk1e9$ai1$1@dont-email.me> <nsk3ic$kh3$1@dont-email.me> <nsmcbv$2cc$1@dont-email.me> <87r3816u6r.fsf@bsb.me.uk> <nsnqsn$lsj$1@dont-email.me> |
James Harris <james.harris.1@gmail.com> writes:
> 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.
I didn't mean that the user has passed the wrong type -- there's nothing
you can do about that -- I meant the type of whatever "current arg ++"
denotes could be wrong. You suggested that the array might be a union,
but there is no guarantee that passing a union object will work. On
some systems (probably little-endian ones) it might just work (though
not for single-precision float), but it's always going to be
non-portable.
>>> 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.
Can I just check that the 'v' version of the function are not what you
want? The description here does not explain why the data are in an
array of some union type and some people are unaware of them.
> 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.
Very likely.
--
Ben.
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