home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / c / 19445 < prev    next >
Encoding:
Text File  |  1993-01-08  |  2.3 KB  |  72 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!mcrware!adam
  3. From: adam@microware.com (Adam Goldberg)
  4. Subject: Re: Problem with Turbo-C: calculating with pointers
  5. Message-ID: <1993Jan8.161709.10524@microware.com>
  6. Sender: news@microware.com
  7. Nntp-Posting-Host: ren
  8. Organization: Microware Systems Corp., Des Moines, Iowa
  9. References: <1993Jan7.112219.578@reks.uia.ac.be>
  10. Date: Fri, 8 Jan 1993 16:17:09 GMT
  11. Lines: 59
  12.  
  13. derijkp@reks.uia.ac.be (Peter De Rijk) writes:
  14.  
  15. >I am porting a program (working on different platforms such as VAX and DEC) to
  16. >the PC. I am using Turbo C++ v.3.0. I compile using the huge memory model.
  17. >I seem to have tracked down the problem (well, one of the problems.) I don't
  18. >know what to do about it though. Here's a little program to illustrate the
  19. >problem:
  20.  
  21. >#include <alloc.h>
  22.  
  23. >main()
  24. >{
  25. >char *pointer,*begin,*end;
  26. >long size;
  27.  
  28. >size=71800;
  29. >pointer=(char *)farmalloc(size*sizeof(char));
  30. >begin=pointer;
  31. >end=pointer+size;
  32. >printf("%p %p %ld",begin, end, end - begin);
  33. >}
  34.  
  35. >I would expect end - begin to return 71800. However it seems to return 6264.
  36. >This is exactly 64K less.
  37. >If this happens for all pointer calculations, I'm in big trouble.
  38. >Any ideas to solve this.
  39.  
  40. Huge model normalizes all pointers, which allows you to access a whole
  41. 64k area with one pointer (ie, huge_char_ptr[64000]).
  42.  
  43. Here's what is happening:
  44.  
  45. pointer=(char *)farmalloc(71800); /* Pointer gets assigned the value 
  46.                                      'seg:0' (where seg is arbitrary).*/
  47. begin = pointer;  /* Ok, no problem so far */
  48. end = pointer+size;  /* Ok, sega:0 + 0:0x11878  BUT WAIT, 0x11878 is
  49.                         > 0xffff, therefore the actual calculation
  50.                         is 'sega:0 + 0x1878', so end is actually pointing
  51.                         to sega:1878 */
  52.  
  53. printf();  /* Yup, you get 6264 which is 0x1878 */
  54.  
  55.  
  56. So, the root cause of this is the bane of all MS-DOS programmers:
  57.   Commandment 1:  You must treat as a special case any accesses to
  58.                   data of length >64k.
  59.  
  60. No, this does not happen with all pointer calculations--only those
  61. which wrap-around 64k.
  62.  
  63. (PS: I believe the other responses were in error)
  64.  
  65. Adam
  66.  
  67. -- 
  68. Adam G.
  69. adamg@microware.com, or ...!uunet!mcrware!adamg
  70. The above is not to be construed in any way as the official or unofficial
  71. statements of Microware, or any Microware employees.
  72.