Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Is %lf allowed in fprintf?
71 views
Skip to first unread message
none Rouben Rostamian
Feb 21, 2013, 4:23:49 PM2/21/13
to
The Foreword of the C99 standard says:
Major changes from the previous edition include:
...
%lf conversion specifier allowed in printf
However, I cannot find a statement to that effect in the
description of fprintf in section 7.19.6.1. Can someone point
me to where the standard says that %lf is allowed in fprintf?
--
Rouben Rostamian
Major changes from the previous edition include:
...
%lf conversion specifier allowed in printf
However, I cannot find a statement to that effect in the
description of fprintf in section 7.19.6.1. Can someone point
me to where the standard says that %lf is allowed in fprintf?
--
Rouben Rostamian
Eric Sosman
Feb 21, 2013, 5:14:27 PM2/21/13
to
"[...] has no effect on a following a, A, e, E, f, F,
g, or G conversion specifier."
"No effect" may not seem worth getting excited about, but in C90
the combination "%lf" had undefined behavior; now it's a no-op.
The Rationale doesn't say why the Committee chose to adopt
this new no-op. I can imagine two plausible reasons: Writing the
C90-undefined "%lf" may have been such a common mistake that it
seemed worth sanctifying, or maybe there was an effort to make
the printf() and scanf() formats a little more similar. That's
just speculation on my part, though; the folks on comp.std.c
might have more accurate information.
--
Eric Sosman
eso...@comcast-dot-net.invalid
none Rouben Rostamian
Feb 21, 2013, 5:24:15 PM2/21/13
to
In article <kg6668$4bm$1...@dont-email.me>,
see that part. Thanks for pointing it out.
> The Rationale doesn't say why the Committee chose to adopt
>this new no-op. I can imagine two plausible reasons: Writing the
>C90-undefined "%lf" may have been such a common mistake that it
>seemed worth sanctifying, or maybe there was an effort to make
>the printf() and scanf() formats a little more similar. That's
>just speculation on my part, though; the folks on comp.std.c
>might have more accurate information.
I assumed that the reason was to make the printf() and scanf()
conversions symmetric. But it's just a guess on my part.
--
Rouben Rostamian
Eric Sosman <eso...@comcast-dot-net.invalid> wrote:
>On 2/21/2013 4:23 PM, none Rouben Rostamian wrote:
>> The Foreword of the C99 standard says:
>>
>> Major changes from the previous edition include:
>> ...
>> %lf conversion specifier allowed in printf
>>
>> However, I cannot find a statement to that effect in the
>> description of fprintf in section 7.19.6.1. Can someone point
>> me to where the standard says that %lf is allowed in fprintf?
>
> It's in 7.19.6.1, paragraph 7:
>
> "[...] has no effect on a following a, A, e, E, f, F,
> g, or G conversion specifier."
>
>"No effect" may not seem worth getting excited about, but in C90
>the combination "%lf" had undefined behavior; now it's a no-op.
I looked that section over and over and somehow did not
>On 2/21/2013 4:23 PM, none Rouben Rostamian wrote:
>> The Foreword of the C99 standard says:
>>
>> Major changes from the previous edition include:
>> ...
>> %lf conversion specifier allowed in printf
>>
>> However, I cannot find a statement to that effect in the
>> description of fprintf in section 7.19.6.1. Can someone point
>> me to where the standard says that %lf is allowed in fprintf?
>
> It's in 7.19.6.1, paragraph 7:
>
> "[...] has no effect on a following a, A, e, E, f, F,
> g, or G conversion specifier."
>
>"No effect" may not seem worth getting excited about, but in C90
>the combination "%lf" had undefined behavior; now it's a no-op.
see that part. Thanks for pointing it out.
> The Rationale doesn't say why the Committee chose to adopt
>this new no-op. I can imagine two plausible reasons: Writing the
>C90-undefined "%lf" may have been such a common mistake that it
>seemed worth sanctifying, or maybe there was an effort to make
>the printf() and scanf() formats a little more similar. That's
>just speculation on my part, though; the folks on comp.std.c
>might have more accurate information.
conversions symmetric. But it's just a guess on my part.
--
Rouben Rostamian
lawrenc...@siemens.com
Feb 22, 2013, 10:52:27 AM2/22/13
to
Eric Sosman <eso...@comcast-dot-net.invalid> wrote:
>
> The Rationale doesn't say why the Committee chose to adopt
> this new no-op. I can imagine two plausible reasons: Writing the
> C90-undefined "%lf" may have been such a common mistake that it
> seemed worth sanctifying, or maybe there was an effort to make
> the printf() and scanf() formats a little more similar. That's
> just speculation on my part, though; the folks on comp.std.c
> might have more accurate information.
Those are the arguments that I remember in favor of it and I don't
>
> The Rationale doesn't say why the Committee chose to adopt
> this new no-op. I can imagine two plausible reasons: Writing the
> C90-undefined "%lf" may have been such a common mistake that it
> seemed worth sanctifying, or maybe there was an effort to make
> the printf() and scanf() formats a little more similar. That's
> just speculation on my part, though; the folks on comp.std.c
> might have more accurate information.
remember that anyone argued against it.
--
Larry Jones
When I want an editorial, I'll ASK for it! -- Calvin
0 new messages