home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / c / 19406 < prev    next >
Encoding:
Text File  |  1993-01-08  |  2.0 KB  |  48 lines

  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!uunet.ca!wildcan!sq!msb
  3. From: msb@sq.sq.com (Mark Brader)
  4. Subject: Re: extern: interesting case...
  5. Message-ID: <1993Jan8.073635.354@sq.sq.com>
  6. Summary: some basics about pointers and arrays
  7. Keywords: extern
  8. Organization: SoftQuad Inc., Toronto, Canada
  9. References: <bibhas.726341439@femto.engr.mun.ca> <4311@dozo.and.nl>
  10. Date: Fri, 8 Jan 93 07:36:35 GMT
  11. Lines: 35
  12.  
  13. > char line[80];
  14. > char *linep= line;
  15. > tells the compiler that the object named `linep' is a pointer, pointing
  16. > to an 80 bytes wide piece of memory that can also be refered to as `line'.
  17.  
  18. Actually, `linep' points to the FIRST of the 80 bytes.  However, because
  19. of the way arrays and pointers work in C, that is exactly what you want
  20. if you intend to access the other bytes as well, one by one.  (See Section
  21. 2 of the comp.lang.c FAQ list, and/or any reasonable quality C book.)
  22. In fact, this is so true that people sometimes slip up (or speak loosely)
  23. and *say* that the pointer is pointing to the whole array, as in the
  24. text quoted above.  But it really is not.
  25.  
  26. The reason it points to a BYTE is that its type is "char *" and a char
  27. is always one byte in C.  (This does not necessarily mean 8 bits; it
  28. could be more.)  If we had
  29.  
  30.     int thing[80];
  31.     int *thingp = thing;
  32.  
  33. and if ints are, say, 2 bytes long, then thing is 160 bytes, and thingp
  34. is pointing simultaneously to the first TWO of them.
  35.  
  36. It is probably better to NOT think of pointers in terms of bytes, but
  37. in terms of objects.  Now thing contains 80 ints, and thingp points to
  38. the first of these ints.  See, now there's no difference between int *
  39. and char *, except the substitution of "int" for "char".  And you don't
  40. need to know the number of bytes in an int to understand the code.
  41. -- 
  42. Mark Brader        "It's important not to let the structure of the
  43. Toronto            code determine the functionality of the program ...
  44. utzoo!sq!msb        The desired functionality should be predetermined
  45. msb@sq.com        before the code writing is done."    -- Dave Sill
  46.  
  47. This article is in the public domain.
  48.