home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / c / 16227 < prev    next >
Encoding:
Text File  |  1992-11-09  |  2.9 KB  |  73 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!mcsun!sunic!ugle.unit.no!alf.uib.no!krill!yngvar
  3. From: yngvar@imr.no (Yngvar Foelling)
  4. Subject: Re: The %lf format specifier.
  5. Message-ID: <1992Nov9.175243.16319@alf.uib.no>
  6. Sender: yngvar@krill (Yngvar Foelling)
  7. Organization: Institute of Marine Research.
  8. References: <1992Oct31.163810.8497@alf.uib.no> <1992Nov6.201125.8252@klaava.Helsinki.FI>
  9. Date: Mon, 9 Nov 92 17:52:43 GMT
  10. Lines: 61
  11.  
  12. In article <1992Nov6.201125.8252@klaava.Helsinki.FI>, wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes:
  13. |> yngvar@imr.no (Yngvar Foelling) writes:
  14. |> >My question is: Is the %lf specifier really illegal in printf?  
  15. |> 
  16. |> It is definitely non-standard.
  17. |> 
  18. |> >In that case, why _does_ the standard define specifiers like %hd for
  19. |> >short, when short is always expanded to int?
  20. |> 
  21. |> What happens is that the short value is promoted to an int before the
  22. |> function is called, but the function converts it back before printing it
  23. |> out.  This has implications for at least the u, o, X, and x formats,
  24. |> where the value is actually converted to an unsigned.  For example, if
  25. |> you pass -(short)1 as the argument (which is an OK thing to do), the
  26. |> function gets -1 (a signed int) and convertes it to an unsigned short. 
  27. |> If it couldn't convert it to short, but had to use int, and if ints are
  28. |> longer than shorts, the value printed out would be different. 
  29. |> 
  30. |> Try this on a machine with ints that are larger than shorts:
  31. |> 
  32. |>     printf("%x\n", -1);
  33. |>     printf("%hx\n", -1);
  34. |> 
  35. |> For example, on a two's complement machine with 16-bit shorts and 32-bit
  36. |> longs, the output is:
  37. |> 
  38. |>     ffffffff
  39. |>     ffff
  40. |> 
  41. |> If there were no %hx, it wouldn't be possible to obtain the latter
  42. |> output.
  43. |> 
  44. |> I have no idea why %hd exists, though, unless it is because of
  45. |> orthogonality.
  46. |> 
  47. |> --
  48. |> Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
  49. |>    MS-DOS, you can't live with it, you can live without it.
  50.  
  51. It seems to me that you're passing signed int's while telling printf to expect
  52. unsigned.  While that works in a two's complement environment (the only type
  53. that I've used) I suspect that it will give different results elsewhere.
  54.  
  55. However, I've realized that there is a clear need for %hu, %hx and %ho.  The
  56. programmer can't be expected to know if sizeof (short) < sizeof (int) or not.
  57. So he can't know if unsigned short is expanded to int or unsigned int, to
  58. decide whether to use %d or %u/x/o.
  59.  
  60. Frankly, I was more or less certain that %lf was non-standard.  I was just mad
  61. at Borland for using it in example code with their compilers.
  62.  
  63. I'm also a bit puzzled as to why the ANSI commitee has included so much
  64. redundancy in both the printf and scanf formats (e.g. printf has both %d and %i,
  65. while scanf has %e, %f and %g) that seems to exist only to make them more
  66. similar, while leaving this little detail out.
  67.  
  68. -- 
  69. Yngvar F°lling (yngvar@imr.no)
  70. Institute of Marine Research
  71. Bergen
  72. Norway
  73.