home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / std / c / 3442 < prev    next >
Encoding:
Text File  |  1993-01-28  |  3.2 KB  |  72 lines
  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!usenet.ins.cwru.edu!agate!ames!decwrl!pa.dec.com!engage.pko.dec.com!nntpd.lkg.dec.com!jit345.bad.jit.dec.com!diamond
  3. From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
  4. Subject: Re: const qualifier
  5. Message-ID: <1993Jan28.113656.10363@nntpd.lkg.dec.com>
  6. Sender: usenet@nntpd.lkg.dec.com (USENET News System)
  7. Reply-To: diamond@jit.dec.com (Norman Diamond)
  8. Organization: Digital Equipment Corporation Japan , Tokyo
  9. References: <1993Jan28.073947.6951@g2syd.genasys.com.au>
  10. Date: Thu, 28 Jan 1993 11:36:56 GMT
  11. Lines: 59
  12.  
  13. In article <1993Jan28.073947.6951@g2syd.genasys.com.au> andrewc@g2syd.genasys.com.au (Andrew Congdon) writes:
  14. >I have a function which takes a parameter that is a 2 dimensional array
  15. >which it will never modify.  [...]  Except for [one] ANSI C compiler, all
  16. >the ANSI C compilers here complain about the following:
  17. >    extern void fn(const float colours[][3]);
  18. >    static float colours[][3] = { { 1.0, 0.0, 0.0 } };
  19. >    fn2(void) {
  20. >        fn(colours);
  21. >    }
  22. >The complaint is the parameter in the call to fn() does not match the
  23. >prototype.
  24.  
  25. 3.7.1, page 83 lines 23 to 24:  "A declaration of a parameter as 'array of
  26. type' shall be adjusted to 'pointer to type', [...]".
  27.  
  28. The parameter declaration says array (unknown size) of array (size 3) of
  29. const float.  It is adjusted to be pointer to array (size 3) of const float.
  30.  
  31. 3.3.2.2, page 41 lines 21 to 23 (a Constraint):  "Each argument shall have
  32. a type such that its value may be assigned to an object with the unqualified
  33. version of the type of its corresponding parameter."  Now the unqualified
  34. version of a type only deletes the top level of qualification (if the top
  35. level was qualified).  For example, the unqualified version of const pointer
  36. to const is still pointer to const.
  37.  
  38. Thus the unqualified version of the parameter is still pointer to array
  39. (size 3) of const float.
  40.  
  41. The identifier in the argument in the call has type array (size 1) of array
  42. (size 3) of float, and gets converted to be pointer to array (size 3) of float.
  43.  
  44. 3.3.16.1, pages 53 to 54, specifies what may be assigned to what.  This
  45. assignment is not permitted.  The closest possibility would be pointers
  46. to qualified or unqualified versions of compatible types (with a further
  47. condition that is moot here), but array of const is not compatible with
  48. array of non-const.
  49.  
  50. Thus the constraint in 3.3.2.2 is violated.
  51.  
  52. This proves that one of your purported ANSI C implementations is not a
  53. genuine ANSI C implementation (if you invoked it as directed by the vendor).
  54.  
  55. >The compilers seem much happier if the call is changed to:
  56. >        fn((const float (*)[3])colours);
  57.  
  58. The cast specification says pointer to array (size 3) of const float.
  59. This type matches the parameter's type.
  60.  
  61. >[Another implementation's] complaint is at least amusing:
  62. >const.c:9:  error:  In this statement, the referenced type of the
  63. >pointer value "colours" is "array [3] of float", which is not compatible
  64. >with "array [3] of float".
  65.  
  66. The standard requires a diagnostic for the program, but not that the
  67. diagnostic be accurate or meaningful.  Only market forces can do that.
  68. --
  69. Norman Diamond                diamond@jit.dec.com
  70. If this were the company's opinion, I wouldn't be allowed to post it.
  71. Pardon me?  Or do I have to commit a crime first?
  72.