printf format ambiguity

Programming and Web Development Forums - std c - Discussion about C language standards.

Skip to content

printf format ambiguity

std c
Post a reply

    Next

  • 1. Urgent Help!!! 3-D array
    Hi all I am not sure whether, I hv defined this array correctlyor not. How to pass a 3-D array from the main program and access it in the subroutine. for example void main() { ..... float a_slope_n_river_width[250][200][5]; .... /*read values from file*/ .... fn_populate_slope_file ( v_x_pixels, v_y_pixels, a_slope_n_river_width, v_pixel_length); ... ... } void fn_populate_slope_file ( int v_x_pixels, int v_y_pixels, float a_slope_n_river_width[v_x_pixels][v_y_pixels][5], float v_pixel_length ) // Generate slope array { /* Here I want to access the element of three dimensional array */ } This piece of code is not working ... Please let me know the error Thanks in advance Regards Nitin
  • 2. scanf (yes/no) - doesn't work + deprecationerrorsscanf,fopenetc.
    Keith Thompson wrote: > Prior to the ANSI standard, strdup() was commonly part of the C > library, right? Not in the base <string.h>. > Why did the C89 standard include gets() but not strdup()? Because gets() was in the legacy library and strdup() wasn't. Some of us tried to get strdup() adopted for the standard, but there was resistance primarily on the grounds that no other standard function malloc()ed storage and the opposition didn't want to start that as a design trend. > If gets() had been dropped from the standard back in 1989, > would that have been a bad thing; would you have (or did you) argue > for including it? Actually I argued against including it in the first place, but now that it is part of the standardized interface I see no benefit and some harm in its removal.

printf format ambiguity

Postby Chris Croughton » Tue, 11 Jan 2005 05:35:44 GMT 

In ISO/IEC 9899-1999 (N843), section 7.19.6.1 (the fprintf function) describes
the conversion specifications.

Paragraph 6 (flag characters) says:

  0     For d, i, o, u, x, X, a, A, e, E, f, F, g, and G conversions,
        leading zeros (following any indication of sign or base) are 
        used to pad to the field width;
    
Paragraph 8 (conversion specifiers) says:

  e, E  A double argument ... is converted in the style [-]d.ddde+/-dd,
        where there is one digit (which is non-zero if the argument is
        non-zero) before the decimal point character...
        
(The descriptions of g,G and a,A in para 8 are similar.)

So if one has a format specifier of "<%014.4e>", with a parameter of 
-1.2345e2, should the result be: 

  <-0001.2345e+02>
  
or

  <   -1.2345e+02>
  
(the former if para 6 is correct, the latter if para 8 is correct)?
glibc2 v2.2.5 does the latter, my implementation does the former (that's
how I noticed the contradiction in the spec.).

Has this been corrected later?  Neither of the Corrigenda on the ANSI website
mention it (ISO/IEC 9899/Cor1:2001 and ISO/IEC 9899/Cor2:2004).

Chris C
Top

Re: printf format ambiguity

Postby Bjorn Reese » Wed, 12 Jan 2005 05:35:44 GMT 



 >
 > or
 >
 >   <   -1.2345e+02>

Section 7.19.6.1/4 says:

   - Zero or more flags (in any order) that modify the meaning of the
     conversion specification.

So the first result (<-0001.2345e+02>) ought to be correct.

-- 
mail1dotstofanetdotdk
Top

Re: printf format ambiguity

Postby Chris Croughton » Wed, 12 Jan 2005 07:19:42 GMT 

On Mon, 10 Jan 2005 21:35:44 +0100, Bjorn Reese 






OK, I've now tried several other libraries.  The one which fails is
glibc 2.2.5, and only on the a and A specifiers, all of the others
(well, the others I tried don't implement the a,A specifiers at all)
seem to think that you are correct (as does glibc 2.2.5 with f, e and
g).  Since the wording is the same for the a,A specifiers as for the
e,E one, I think it's a bug in glibc.

(The wording in the spec. is still ambiguous, though, because the other
paragraphs imply only one digit before the point...)

Chris C
Top

Re: printf format ambiguity

Postby Thad Smith » Wed, 12 Jan 2005 14:01:09 GMT 






I agree that it may be confusing on first reading, but "modifying the 
meaning", quoted above, makes it clear which interpretation takes 
precedence.  With that context it is not longer ambiguous, IMHO.

Thad
Top

Re: printf format ambiguity

Postby Brian Inglis » Wed, 19 Jan 2005 16:32:23 GMT 

On Mon, 10 Jan 2005 22:19:42 +0000 in comp.std.c, Chris Croughton






7.19.6.1#8 ...

ISTM rephrasing as "one significant digit" makes the intent explicit
and resolves the issue. 

-- 
Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada

 XXXX@XXXXX.COM  	(Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
    fake address		use address above to reply
Top

Similar Threads:

1.printf warning: "format %08x expects format unsigned int ..." 

Andreas Eibach wrote:
> .... but I have an unsigned long value in the printf.
> This warning came when I used gcc 4.x to compile.
> ....
> unsigned long offset = 0;
> ....
> 
> Well OK, an "easy" way would be instead of
> 
> printf ("eof found at offset %08x", offset);
> to do a type cast like

"cast"

> printf ("eof found at offset %08x", (unsigned int) offset);
> 
> Fine, but is this supposed to work for values like 0xFFFFFFFF, which is
> afaik the last possible long value. Unsigned int only goes to 0xFFFF.
>
"08lx" should do the job for unsigned long.

-- 
Ian Collins

2.C99 printf formats (2) 

Hello, I have a new question about printf:
what is the correct output of printf("%#x", 0); ? (or with 0U for the
anal-retentive :)
According to my understanding of the standard, it is undefined
behaviour (the behaviour is defined only for nonzero values), so it
could output anything, including "pi=4".
All the libraries that I know will display "0" like for the %#o case
which is clearly specified.

Regards,
Adrian

3.printf(): giving format to an unsigned long questions 

Hi

I would like to print on a win cmd console a register value,  the value
is an "unsigned long" and have some output like these:

Register: 0x00000000

Tryed with

printf("Register: %#010lx \n", register);
printf("Register: %#08lx \n", register);

but I get 0x000003, only the first 6 values ??? from LSB to MSB,
normally MSBs are cero, but I would like to see them all.

Is there a way to print, hexadecimal, the hole 32 bits and add a nice
0x at the beginning?
I have read some books, googled and couldn't give a solution, any help
or info would be kindly appreciated.

Best Regards

4.Inverse of printf %x format 

I've seen several postings asking this, but no simple, clear answer. My
C language reference book is deficient in this area.

If I

     short i = 0;
     printf(">%2x<",i);

I might resonably expect the following output:

     >0000<

Now, what format code (%?? below) will restore i's value? e.g.

     short i;
     char s[5];
     strcpy(s,"0000");
     sprintf((char *)&i,"%??",s);
     if (i==0) printf(">Hexed again<");

Produces:

     >Hexed again<

Thanks in advance

5.printf format for double 

Is it possible to print a float or double in exponential form with a 0 
before the decimal point?

E.g. 0.1234567E+00 rather than 1.2345670E-01 (using %14.7E) ? As far as I 
understand the format specifies in n1256, this isn't possible, is it?

Bye, Jojo

6. max size for printf() format conversion?

7. Problem with printf formats

8. printf() formatting - stripping zeroes, padding

Post a reply

Return to std c

 

Who is online

Users browsing this forum: No registered users and 40 guest

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group