home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / c / 12440 < prev    next >
Encoding:
Text File  |  1992-08-17  |  2.8 KB  |  71 lines

  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!gatech!concert!sas!mozart.unx.sas.com!sasghm
  3. From: sasghm@theseus.unx.sas.com (Gary Merrill)
  4. Subject: Re: Pointer/address reluctance
  5. Originator: sasghm@theseus.unx.sas.com
  6. Sender: news@unx.sas.com (Noter of Newsworthy Events)
  7. Message-ID: <Bt54D0.CFn@unx.sas.com>
  8. Date: Mon, 17 Aug 1992 18:22:12 GMT
  9. References: <l8kteaINNp2c@exodus.Eng.Sun.COM> <14807@ksr.com> <mcdonald.206@aries.scs.uiuc.edu>
  10. Nntp-Posting-Host: theseus.unx.sas.com
  11. Organization: SAS Institute Inc.
  12. Lines: 57
  13.  
  14.  
  15. In article <mcdonald.206@aries.scs.uiuc.edu>, mcdonald@aries.scs.uiuc.edu (J. D. McDonald) writes:
  16.  
  17. |> 
  18. |> However, in fact pointers **are** addresses of a sort, and the real
  19. |> programmer nees to understand them if they are to do general programming in
  20. |> C.
  21. |> 
  22. |> This can, in fact, be proven:
  23. |> 
  24. |> 1) General programming includes all the programming that can, and is,
  25. |>    done in C
  26. |> 
  27. |> 2) Some C programming is for interaction with devices, for example,
  28. |>    direct control of devices from programs and/or device drivers if an OS
  29. |>    uses such beasties.
  30. |> 
  31. |> 3) Some devices use memory mapped magic addresses
  32. |> 
  33. |> 4) IF these can be addressed from C, which is usually the case (for example,
  34. |>    C code running in   "unhosted" mode at the highest privilege level),
  35. |>    then the usual way to address them  is by actually coding the proper bits
  36. |>    into an integral variable (or in rare cases the integral part of a union)
  37. |>    and casing to a pointer.
  38. |> 
  39. |> QED.
  40. |> 
  41. |> 
  42. |> Of course, there are some individuals who aren't interested in such 
  43. |> things ..  or aren't trusted enough to do it.
  44. |> 
  45. |> Doug McDonald   
  46.  
  47. If you need to understand them, you need to understand them a little
  48. better.  While there is a (sometimes very) close relationship between
  49. addresses and pointers in C, they are not the same.  Consider, for
  50. example, the fact that there are some memory models for the 8086
  51. where a pointer (say a function pointer) is two bytes in size, but
  52. the address it represents is four bytes in size.  The Lattice P
  53. model had this feature, and our mainframe C compiler implements
  54. a similar scheme as well.  So pointers aren't even necessarily the
  55. *same size* as addresses.
  56.  
  57. This brings up the point that there is no requirement for all
  58. pointers to be the same size.  It is not uncommon for function
  59. pointers to be a different size from data pointers.  Does this
  60. mean or require that the underlying machine supports two different
  61. kinds of addresses?  Hardly.
  62.  
  63. In addition, of course, as a previous poster pointed out, a pointer
  64. comes with the additional semantic baggage concerning the size of
  65. the pointed-to object.
  66.  
  67. -- 
  68. Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
  69. SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / (919) 677-8000
  70. sasghm@theseus.unx.sas.com ... !mcnc!sas!sasghm
  71.