home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / c / 13204 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  3.0 KB
  1. Path: sparky!uunet!olivea!gossip.pyramid.com!pyramid!oracle!unrepliable!bounce
  2. From: wkaufman@us.oracle.com (William Kaufman)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Why should POINTERS be so damn hard to understand ?
  5. Message-ID: <1992Sep4.023823.6902@oracle.us.oracle.com>
  6. Date: 4 Sep 92 02:38:23 GMT
  7. References: <1992Aug27.135946.6622@infonode.ingr.com> <1992Aug28.163724.11581@mccc.edu> <Btx3II.Fyn@multisys.com>
  8. Sender: usenet@oracle.us.oracle.com (Oracle News Poster)
  9. Organization: Oracle Corporation, Redwood Shores CA
  10. Lines: 58
  11. Nntp-Posting-Host: hqsun2.us.oracle.com
  12. X-Disclaimer: This message was written by an unauthenticated user
  13.               at Oracle Corporation.  The opinions expressed are those
  14.               of the user and not necessarily those of Oracle.
  15.  
  16. In article <Btx3II.Fyn@multisys.com> rot@multisys.com (Republic of Taiwan) writes:
  17. ] =In article <1992Aug27.135946.6622@infonode.ingr.com> henders@infonode.ingr.com (Greg Henderson) writes:
  18. ] 
  19. [...Greg posts an array scan and a pointer scan, deleted for brevity...]
  20. ]
  21. ] The presumption here is that the length of int is same as
  22. ] the length of the address space.
  23.  
  24.     How do you mean "address space"?  You mean alignment or the size of
  25. the addressable area of memory considered as an integer?  I don't think
  26. either should mess you up here.
  27.  
  28.     Also, I'm not sure which program you're objecting to.  There are two
  29. here.
  30.  
  31. In article <1992Aug27.135946.6622@infonode.ingr.com> henders@infonode.ingr.com (Greg Henderson) writes:
  32. =
  33. ={
  34. =    int a[1000], *_i;
  35. =
  36. =    for (_i=a;  _i<a+1000; _i++ )
  37. =    *_i = get_some_arbitrary_value();
  38. =}
  39.  
  40.     I assume this is the one, right?  Well, by ANSI (and all pre-ANSI
  41. compilers that I've seen), a[] must be a *contiguous* set of int's, and
  42. _i must get initialized to &a[0].  So after _i++, _i must point to a[1],
  43. no?
  44.  
  45.     The only objection I have is "_i": ANSI says that starting
  46. identifiers with underscores a no-no.  (Unless you're personally writing
  47. the compiler,...)
  48.  
  49. ] If the int is 4 byte long and the address space is 2(or 8 or 3) byte long,
  50. ] the this fell miserably. The second one is not portable.
  51.  
  52.     If by "address space" you mean alignment, then it must be the case
  53. that
  54.         (&a[1] - &a[0])
  55. is 4 (or 8 or 4, by your examples), and
  56.         ((_i = a, ++_i) - &a[0])
  57. must also be 4 (or 8 or 4).
  58.  
  59.     (And, c.l.c fans, quote me no sequence points: the last expression
  60. was just for example, and would be used by no one in their right mind.
  61. It only fails if you don't understand what I mean, not if it doesn't
  62. produce a good run-time value.)
  63.  
  64.     If by "address space" you mean the addressable area of memory,
  65. declaring "int a[1000]" will either succeed (in which case, a[1000] will
  66. point to valid memory), or the program will crash on an "out of stack"
  67. error, or it will fail to compile/link.
  68.  
  69.                                            -- Bill K.
  70.  
  71. Bill Kaufman,          | "...all conscious species are plastic and
  72. Corporate Lackey       |  all plastic species are conscious."
  73. wkaufman@us.oracle.com |                     -- Yew-Kwang Ng
  74.