home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / c / 19485 < prev    next >
Encoding:
Text File  |  1993-01-09  |  2.6 KB  |  70 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: Problem with Turbo-C: calculating with pointers 
  5. Message-ID: <1993Jan10.024536.29542@sq.sq.com>
  6. Organization: SoftQuad Inc., Toronto, Canada
  7. References: <1993Jan7.112219.578@reks.uia.ac.be> <726524790snz@panache.demon.co.uk>
  8. Date: Sun, 10 Jan 93 02:45:36 GMT
  9. Lines: 59
  10.  
  11. Reminder: it is neither necessary, nor preferred, nor desirable to
  12. quote an ENTIRE article when posting a followup to it!!
  13.  
  14. > > char *pointer,*begin,*end;
  15. > > long size;
  16. > > 
  17. > > size=71800;
  18.  
  19. > make this 71800L and it will work. This compiler like many others treats
  20. > integer cosntants as 16-bit ints. 61800-65536 == 6264.
  21.  
  22. If so, it is a compiler bug.  Both K&R1 (page 180) and the ANSI/ISO
  23. standard (section 3.1.3.2/6.1.3.2) specify that an integer constant
  24. whose value doesn't fit in an int, but does fit in a long, has the
  25. type long.  However, if there are really "many" compilers with this
  26. bug, then using 71800L is a suitable workaround.
  27.  
  28. > > pointer=(char *)farmalloc(size*sizeof(char));
  29. > > begin=pointer;
  30. > > end=pointer+size;
  31. > > printf("%p %p %ld",begin, end, end - begin);
  32.  
  33. If the results of converting the two pointers with %p had been given,
  34. we would have been able to tell whether the above conjecture was right!
  35. When posting a program in this situation, please include ALL relevant
  36. output.
  37.  
  38. > > I would expect end-begin to return 71800. However it seems to return 6264.
  39.  
  40. Perhaps the implementation expresses the difference between two pointers
  41. as an int rather than a long.  If so, and if objects can actually be large
  42. enough to require a long to express the difference, this is stupidity
  43. at least.  However, the only workaround I can suggest is, "get a better
  44. compiler".
  45.  
  46. Note incidentally that printing the result of a pointer subtraction using
  47. %ld is implementation-dependent.  The result actually could be an int, so
  48. %ld could, for example, pick up an extra word from the stack.  Safer is
  49. to use %ld and cast the result of the subtraction to long.
  50.  
  51. > Better still, don't do pointer arithmetic. It is a sure route to trouble.
  52.  
  53. This is followed immediately by a signature line of "Nil taurus excretum".
  54. The two assertions seem to be in conflict.
  55.  
  56.  
  57.  
  58.  
  59.  
  60. I'd like to leave it at that, but for the benefit of the Latin-illiterate,
  61. the signature quote is a mangled translation of "No bullshit".  I am,
  62. therefore, saying that the suggestion to avoid pointer arithmetic is
  63. exactly that.
  64. -- 
  65. Mark Brader                    "Domine, defende nos
  66. SoftQuad Inc., Toronto                 Contra hos motores bos!"
  67. utzoo!sq!msb, msb@sq.com                    -- A. D. Godley
  68.  
  69. This article is in the public domain.
  70.