home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / c / 20147 < prev    next >
Encoding:
Internet Message Format  |  1993-01-24  |  2.8 KB
  1. Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!usenet.ins.cwru.edu!agate!spool.mu.edu!howland.reston.ans.net!paladin.american.edu!news.univie.ac.at!hp4at!mcsun!chsun!zurich!gegu
  2. From: gegu@zurich.spectrospin.ch (Gerry Gucher)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: HALLOC and HUGE ptrs in Microsoft C
  5. Summary: C is portable, implementations are not
  6. Message-ID: <206@zurich.spectrospin.ch>
  7. Date: 24 Jan 93 17:21:30 GMT
  8. References: <1993Jan21.175608.4279@arizona.edu>
  9. Distribution: world,local
  10. Organization: Spectrospin AG, Fallanden Switzerland
  11. Lines: 56
  12.  
  13. In article <1993Jan21.175608.4279@arizona.edu>, jjr@ace.ece.arizona.edu (Jeffrey J. Rodriguez) writes:
  14. > On a 486 running DOS, I need to allocate an array that's bigger than 64K,
  15. > ll it up with data, and write it to a binary file.
  16. > The MSC 7.0 manual says to use halloc(), which returns a "huge ptr".
  17. > It also says that huge ptrs cannot be passed as args to library functions.
  18. > Therefore, I can't pass the array to fwrite()!
  19.  
  20. I doubt that you interpret the manual correctly.
  21. Huge pointers are simply far pointers that have their seg:offset
  22. pair normalized so that the offset is always smaller than 16.
  23. If a library gets 0x1000:0x0005 it can not tell the difference from a far
  24. pointer. 
  25.  
  26. > So, how do I write the data? (Do I really have to loop through putchar?)
  27.  
  28. If anything I would loop over fwrite() to print large binary data.
  29.  
  30. > 
  31. > This sure seems cumbersome.
  32. > It also seems that a program written for PC-DOS using halloc and huge
  33. > ptrs would not run on a Sun running UNIX.
  34.  
  35. That is right, but it's easy to fix. Just do:
  36.  
  37. #define huge    /* empty */
  38. #define halloc(x)      malloc(x)
  39.  
  40. > So much for portable C.
  41.  
  42. C is in fact portable. But due to the braindamaged memory architecture,
  43. most if not all compiler vendors in the MESS-DOS world chose to implement
  44. a language that looks like C but isn't C. They invented new
  45. keywords like "huge, far, ..." etc. which makes their language non standard
  46. conformant. When they claim ANSI compatibility, they mean the "small" memory
  47. model only. Fortunately most problems can be solved by defining the problem
  48. away. Additionally every C implementor can extend the library with more
  49. functions (e.g. halloc) and using those makes your code non portable. This
  50. is your problem and has nothing to do with the portability of C.
  51.  
  52. Back to your question about fwrite(). You can eiter break you fwrite() call
  53. into a series of fwrites() each writing less than 64 kB at once or you can try
  54. to make the size of your items larger (say 1k words) and write less items.
  55. I have never tried this but it might work (even on a PC). Of course you
  56. must use the "large" memory model library for fwrite(). E.g.
  57.  
  58.   instead :  fwrite( buf, 200000, sizeof(int), fp );
  59.   try     :  fwrite( buf, 2000, 1000*sizeof(int), fp );
  60.  
  61. I have not tried it but it might work.
  62. > 
  63. > Jeff Rodriguez
  64. > rodriguez@ece.arizona.edu
  65.  
  66. Gerry
  67.  
  68.  
  69.