From: broeker AT acp3bf DOT knirsch DOT de (Hans-Bernhard Broeker) Newsgroups: comp.os.msdos.djgpp Subject: Re: far pointers again Date: 6 Oct 1999 14:27:43 +0200 Organization: RWTH Aachen, III. physikalisches Institut B Lines: 50 Message-ID: <7tff80$2kp@acp3bf.knirsch.de> References: <7tf476$8qj AT cs DOT vu DOT nl> NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de X-Trace: nets3.rz.RWTH-Aachen.DE 939212866 19230 137.226.32.75 (6 Oct 1999 12:27:46 GMT) X-Complaints-To: abuse AT rwth-aachen DOT de NNTP-Posting-Date: 6 Oct 1999 12:27:46 GMT X-Newsreader: TIN [version 1.2 PL2] To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com FokkemaDBRA wrote: > Shawn Hargreaves (SHargreaves AT acclaimstudios DOT co DOT uk) wrote: > : That, IMHO, is the right way to do it. The need to use far pointers > : in djgpp is a misfeature of the design of DOS and DPMI, and not a > : good thing if there are other alternatives. > IMHO, everything that is possible on a platform, should be somehow possible > in C. That's your opinion, but obviously not the opinion of the people who invented and later standardized C. The outcome of this is that you *cannot* use far pointers (in the DOS 16bit compiler variety) and still code in the language defined under the name 'C', because 'far' is a new keyword that simply doesn't exist in C. As soon as you add the 'far' keyword, one of the most fundamental assumptions in C breaks down: a pointer is a pointer is a pointer. There will suddently be different types of pointers to the same data type. C is not designed for such a (brain-damaged, IMHO) concept. You end up with braindamaged things like this (observed in BC++): you can access an array of structures of more than 64K in size by use of 'huge' pointers, but even so, no single structure is allowed to cross a 64K boundary, or you'll be in trouble. For exactly that reason, I suspect you'll never be able to talk the GCC maintainers into even accepting readily made patches for 'far' support, let alone get them code it for you. You may try, but don't you be surprised when the answer is given in a tone of disgust... > The x86 processors support multisegmented memory models in protected > mode. Many c compilers support far pointers. "Many millions of flies eat sh*t. So we should eat it, as well." or what? This argument has never been a good one. > Why wouldn't you support it > just because you think a flat memory model is better? Because a flat memory model *is* better, by all measures. The only true reason for support of multisegmented models, originally, was starvation of pins and register widths in the original x86 processors. Until the point where it's anywhere near likely for a single machine to have more than 2 GB of RAM, there's no reason for using far pointers, at all. There's next to nothing that cannot be done more elegantly in a flat address space, using the paging mechanisms of the MMU. -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.