home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / c / 13304 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  3.4 KB

  1. Path: sparky!uunet!cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!dog.ee.lbl.gov!horse.ee.lbl.gov!torek
  2. From: torek@horse.ee.lbl.gov (Chris Torek)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: sscanf? What am I doing wrong?
  5. Date: 7 Sep 1992 19:12:43 GMT
  6. Organization: Lawrence Berkeley Laboratory, Berkeley
  7. Lines: 69
  8. Message-ID: <26147@dog.ee.lbl.gov>
  9. References: <1992Aug31.154655.15737@magnus.acs.ohio-state.edu> <1992Sep3.134259.14601@microware.com>
  10. Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
  11. NNTP-Posting-Host: 128.3.112.15
  12.  
  13. [given]
  14. >>  char partA[20];
  15. >>  char tran[] = "transmit";
  16. >>  if (partA==tran) ...
  17.  
  18. In article <1992Sep3.134259.14601@microware.com> adam@microware.com
  19. (Adam Goldberg) writes:
  20. >partA and tran are both POINTERS to some number of characters.
  21.  
  22. Well, no.  The variables `partA' and `tran' are each arrays,
  23. specifically, `array 20 of char' and `array 9 of char' respectively.
  24.  
  25. >The if statement (partA == tran) is checking if the POINTERS are equal...
  26.  
  27. This, however, is correct, by The Rule:
  28.  
  29.     In a value context, an object of type `array N of T' is converted
  30.     to a value of type `pointer to T' by locating the first element of
  31.     that array, i.e., the one with subscript 0.
  32.  
  33. In this case, both partA and tran are in value contexts, both are
  34. objects of type `array N of char' (their N's differ, but N is dropped
  35. along the way so this does not matter), and so both become values of
  36. type `pointer to char', namely &partA[0] and &tran[0] respectively.
  37.  
  38. >clearly they're not, unless you did something previously like
  39. >partA = tran.
  40.  
  41. Since partA is an array, which is not (per ANSI C terminology) a
  42. `modifiable lvalue', such an assignment is illegal.  In any case, the
  43. programmer may not alter the address of an object---the address of each
  44. object is a matter for the compiler and/or machine to arrange, and the
  45. programmer has no say in this.  (Aside, that is, from machine-dependent
  46. tricks like mixing C and assembly.)  The C language further guarantees
  47. that for any two different objects X and Y of the same type, &X != &Y.
  48. This means that we can be certain that partA != tran, and that the
  49. code inside the `if' will *never* run.
  50.  
  51. (There are even stronger guarantees when you start casting to
  52. common superset pointer types such as `void *', but then the rules
  53. get complicated since (void *)&foo.x can be equal to (void *)&foo.y,
  54. and so forth.)
  55.  
  56. >What you (probably) want to do is something like this:
  57. >   if(strcmp(partA, tran)==0)
  58.  
  59. Right.  Alternatively, one can make one (or both) of the variables
  60. `char *' and then set one or both to the same pointer value, so that
  61. they compare equal.
  62.  
  63. If you want to understand C expressions, you must learn three basic
  64. elements:
  65.  
  66.     - objects versus values (or `lvalues' vs `rvalues');
  67.     - the type system;
  68.     - the rules for converting objects to values, and for making
  69.       values compatible.
  70.  
  71. (Some people lump all of these together under `the type system', but I
  72. prefer to separate them.)  Once you have these down, you should be able
  73. to determine the `object'- or `value'-ness of any expression, along
  74. with its type.  If you can then find the value, you can predict exactly
  75. what that expression means, or know that it is impossible to say (e.g.,
  76. if the value is `uninitialized' or garbage').
  77.  
  78. And then you are reading to start on side effects. :-)
  79. -- 
  80. In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
  81. Berkeley, CA        Domain:    torek@ee.lbl.gov
  82.