home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c
- Path: sparky!uunet!uunet.ca!canrem!telly!druid!darcy
- From: darcy@druid.uucp (D'Arcy J.M. Cain)
- Subject: Re: HALLOC and HUGE ptrs in Microsoft C
- Message-ID: <1993Jan27.232921.3693@druid.uucp>
- Date: Wed, 27 Jan 1993 23:29:21 GMT
- Distribution: world,local
- References: <1993Jan21.175608.4279@arizona.edu> <C1BFs8.6EF@ccu.umanitoba.ca>
- Organization: D'Arcy Cain Consulting
- Lines: 41
-
- raskin@ccu.umanitoba.ca (Alan Raskin) writes:
- >Actually, I think that fwrite is one of the library routines that *will*
- >take huge pointers; according to an old QuickC manual, "a huge array can
- >be passed without difficulty to any of these [bsearch, fread, fwrite, halloc,
- >hfree, lfind, lsearch, mem* and qsort] functions in a compact-, large-, or
- >huge-model program." ^^^^^^^ ^^^^^
- ^^^^
-
- That's the problem - it isn't consistent across all models.
-
- >Because of the <expletive deleted> segmented-memory architecture of the Intel
- >80x86 CPUs, which at times requires the use of the non-portable "near", "far"
- >and "huge" keywords, the only way to write "portable" C would be to use
- >#if defined ( MSDOS ) /* M_I86 is also defined by MSC; what about Borland? */
- __MSDOS__ is defined by Borland and I believe by MSC as well.
-
- >.
- >. halloc(...);
- >.
- >#else
- >.
- >. malloc(...);
- >.
- >#endif
-
- While I agree with you about segments (*) in this case why not just:
-
- #ifdef __MSDOS__
- #define halloc malloc
- #endif
-
- Just once at the top.
-
- (*) Q: What's the difference between an IBM PC and a boat anchor?
- A: Segment registers.
-
- --
- D'Arcy J.M. Cain (darcy@druid.com) |
- D'Arcy Cain Consulting | There's no government
- Toronto, Ontario, Canada | like no government!
- +1 416 424 2871 DoD#0082 |
-