home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / gnu / gcc / bug / 3242 < prev    next >
Encoding:
Internet Message Format  |  1993-01-25  |  1.9 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!jarthur.claremont.edu!jason
  2. From: jason@jarthur.claremont.edu (Jason Merrill)
  3. Newsgroups: gnu.gcc.bug
  4. Subject: Re: Prototype handling bug(?) in 2.3.3
  5. Date: 25 Jan 1993 20:44:23 -0500
  6. Organization: GNUs Not Usenet
  7. Lines: 61
  8. Sender: daemon@cis.ohio-state.edu
  9. Approved: bug-gcc@prep.ai.mit.edu
  10. Distribution: gnu
  11. Message-ID: <9301241911.AA19972@life.ai.mit.edu>
  12. References: <JASON.93Jan21002234@it.claremont.edu>
  13.  
  14. >>>>> bof@midget.saar.de (Patrick Schaaf) writes:
  15.  
  16. > In gnu.gcc.bug you write:
  17. >>And indeed that fragment reproduces the bug (misfeature)?  I was under the
  18. >>impression that you could pass anything you darn well pleased through ().
  19.  
  20. > No, you can't. Assume the following code:
  21.  
  22. > short a, b;
  23.  
  24. > void foobar();
  25.  
  26. > foobar(a,b); /*1*/
  27.  
  28. > void foobar(short bla, short fasel);
  29.  
  30. > foobar(a,b); /*2*/
  31.  
  32. > In the first call to foobar, the shorts will be promoted to int by the
  33. > default promotion rules (the same way floats are converted to doubles),
  34. > thus (on a machine with 2 byte shorts and 4 byte ints) 8 bytes are passed
  35. > to foobar.
  36. > The second call, with the prototype in scope, will not apply default
  37. > promotion rules, and thus passes only the 4 bytes for the 2 shorts.
  38.  
  39. Suppose you have
  40.  
  41. void foobar();
  42.  
  43. ....
  44.  
  45. short a, b;
  46.  
  47. foobar(a,b);
  48.  
  49.  
  50. void foobar(c,d)
  51.     short c,d;
  52. {
  53. ...
  54. }
  55.  
  56. Then are c and d promoted to int as well?  Just curious.
  57.  
  58.  
  59. > You can't write function foobar to correctly accept both types of call.
  60. > IMHO, the compiler is a good one if it warns you about this possible pitfall.
  61.  
  62. I would agree with that.  Unfortunately, the compiler message is an error,
  63. not a warning, so I am forced to comment out the first prototype somehow.
  64. Unfortunately, it is in one of the system headers, which makes that an
  65. annoying task.
  66.  
  67. Hmm...I just looked at the getpwuid man page, and evidently it takes an int
  68. parameter.  I guess the compiler does know best...but I still think it
  69. should be a warning, not an error.
  70.  
  71. Jason
  72.  
  73.  
  74.  
  75.