LWN.net Logo

Buggifying critical core modules

Buggifying critical core modules

Posted Mar 19, 2008 16:47 UTC (Wed) by jengelh (subscriber, #33263)
In reply to: Buggifying critical core modules by quotemstr
Parent article: Who maintains dpkg?

#include <stdio.h>
#define E(t) printf(#t " = %u\n", sizeof(t));

int main(void)
{
        E(void *);
        E(void far *);
        E(void near *);
        E(void (*)(void));
}

near pointers are always 2, and far are always 4. But it is interesting to see that untagged pointers vary in size, depending on the compiler model. Turbo C++ 1.x for DOS says:

/* “Tiny” and “Small” model */
void * = 2
void (*)(void) = 2
/* “Medium” model */
void * = 2
void (*)(void) = 4
/* “Compact” model */
void * = 4
void (*)(void) = 2
/* “Large” and “Huge” model */
void * = 4
void (*)(void) = 4
/* For your information about this compiler, in all models: */
int = 2
long = 4

nonfunctionpointertype * is always the same width as void *, though.


(Log in to post comments)

Buggifying critical core modules

Posted Mar 19, 2008 17:07 UTC (Wed) by quotemstr (subscriber, #45331) [Link]

Not applicable. DOS isn't a POSIX system.

Buggifying critical core modules

Posted Apr 7, 2008 8:00 UTC (Mon) by jengelh (subscriber, #33263) [Link]

So what? You do not need DOS to make a compiler output far/near-based pointers. What it
requires is — I think — that the CPU is in real mode because that's where far/near pointers
make most sense.

Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds
Powered by Rackspace Managed Hosting.