home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 19932 < prev    next >
Encoding:
Internet Message Format  |  1992-12-27  |  2.5 KB
  1. Path: sparky!uunet!spool.mu.edu!agate!ucbvax!lrw.com!leichter
  2. From: leichter@lrw.com (Jerry Leichter)
  3. Newsgroups: comp.os.vms
  4. Subject: re: C pointer question
  5. Message-ID: <9212272214.AA24880@uu3.psi.com>
  6. Date: 27 Dec 92 21:02:43 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 51
  11.  
  12. Sigh.  In an earlier flamey message, I wrote that the two pieces of code,
  13.  
  14.     void foo(char a[])
  15.     {
  16.     bar(a);
  17.     }
  18.  
  19.     and
  20.  
  21.     void foo(char a[])
  22.     {
  23.     bar(&a);
  24.     }
  25.  
  26. were identical.  Wrong, Leichter, wrong.  If you're going to flame, just
  27. flame, don't throw in a quick remark without thinking it through (which is
  28. unlikely in the midst of flaming.)
  29.  
  30. As Neil Readwin has already pointed out to me in a private message (and I'm
  31. sure plenty more people will be pointing it out, too), in fact, the function
  32. "void foo(char a[])" is indistiguishable from "void foo(char *a)" - one of C's
  33. more annoying little hacks.  Despite the appearance of the declaration, "a"
  34. ends up typed as "pointer to char", NOT as "array of char".  (ANSI Standard,
  35. Section 3.7.1 (under Semantics):  "A decla- ration of a parameter as 'array of
  36. type' shall be adjusted to 'pointer to type'.")  So the two definitions ARE
  37. different:  The first passes "a"'s value (foo's argument, of type "char *");
  38. the second passes a pointer to "a" itself (of type "char **").
  39.  
  40. As to the original program that this arose in, the author wrote:
  41.  
  42.     bar wants a char *, foo is passed a char *.
  43.  
  44. If bar wants a char *, then the first piece of code is correct.  The second
  45. passes a char **.  Since it was the second (type-incorrect) code that was
  46. alleged to actually work, my opinion of the level of programming involved here
  47. remains unchanged.
  48.  
  49. (For those who like chapter and verse:  My original comment that, if "a"
  50. really has type "array of T", then "a" is not an lvalue, is correct according
  51. to the ANSI Standard, Section 3.2.2.1:  "Except when it is the operand of the
  52. sizeof operator or the unary & operator ... an lvalue that has type 'array of
  53. type' is converted to an expression that has type 'pointer to type' ... [that]
  54. is not an lvalue."  The exception for unary "&" allows "a" and "&a" to be
  55. almost equivalent.  (Technically, the first has type "pointer to T" while the
  56. second has type "pointer to array of T".  The values are the same, but the
  57. difference in type will be visible as a different scaling value if you add an
  58. integer to these pointers.  This is actually a change from K&R C, where the
  59. exception did not "officially" exist, and where "&a" if allowed was taken to
  60. mean EXACTLY the same thing as "a" itself.))
  61.                             -- Jerry
  62.  
  63.