471,086 Members | 1,137 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,086 software developers and data experts.

size of pointer in C?

What is size of pointer in C on DOS?
is it sizeof(int ) or size of (long int)?
If this ans is present in FAQ pls direct me to tht ouestion

Nov 15 '05 #1
33 16946
siliconwafer wrote:
What is size of pointer in C on DOS?
is it sizeof(int ) or size of (long int)?
If this ans is present in FAQ pls direct me to tht ouestion


It is sizeof(void*)...
It may be sizeof(void*)==sizeof(long), but it may not be as well.
Whatever depends on the conditional above is considered not portable.
--
one's freedom stops where others' begin

Giannis Papadopoulos
Computer and Communications Engineering dept. (CCED)
University of Thessaly
http://dop.users.uth.gr
Nov 15 '05 #2
Giannis Papadopoulos wrote:

siliconwafer wrote:
What is size of pointer in C on DOS?
is it sizeof(int ) or size of (long int)?
If this ans is present in FAQ pls direct me to tht ouestion


It is sizeof(void*)


Pointers to void are the same size as pointers to char.

Pointers to structures are the same size as each other.

The sizes of most other types of pointers
have no special specifications.

--
pete
Nov 15 '05 #3
In article <11**********************@o13g2000cwo.googlegroups .com>,
siliconwafer <sp*********@yahoo.com> writes
What is size of pointer in C on DOS?
is it sizeof(int ) or size of (long int)?
If this ans is present in FAQ pls direct me to tht ouestion


plz wrt in engsh

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Nov 15 '05 #4
On Thu, 29 Sep 2005 02:18:33 -0700, siliconwafer wrote:
What is size of pointer in C on DOS?
Whatever the compiler chooses to make it. For most DOS compilers that
depends on the memory model you use to compile. However memory models are
a DOSism or at least processor related, and not part of standard C. A good
place to discuss this is comp.os.msdos.programmer.
is it sizeof(int ) or
size of (long int)? If this ans is present in FAQ
pls direct me to tht ouestion


So it could be either depending on what compiler and compiler options you
use. As far as writing C code is concerned just write you program so that
it wirks either way, that is without making assumptions about pointer size
and representation.

Lawrence
Nov 15 '05 #5

siliconwafer wrote:
What is size of pointer in C on DOS?
is it sizeof(int ) or size of (long int)?
If this ans is present in FAQ pls direct me to tht ouestion


Lets take an example:
char*str = (char*)malloc(1024);
printf("%d",sizeof(str));
what should get printed?

Nov 15 '05 #6
siliconwafer wrote:
What is size of pointer in C on DOS?
is it sizeof(int ) or size of (long int)?
If this ans is present in FAQ pls direct me to tht ouestion


Lets take an example:
char*str = (char*)malloc(1024);
printf("%d",sizeof(str));
what should get printed?


(a) Anything. You have undefined behaviour there. (Clue: what type
does %d expect?)

(b) The sizeof a pointer-to-char in your implementation. Possibilities
include 2, 4, 8, 3, 1, and 17.

--
Chris "Dragaeran software written in C?!" Dollin
The software engineer's song: "who knows where the time goes".
Nov 15 '05 #7
Hi Chris,
does it make any difference that size of pointer to char is different
than size of pointer to say long int?
A pointer stores address and address is integer or long int.So size of
pointer *must* be either 2 or 4
-Siliconwafer

Nov 15 '05 #8
siliconwafer wrote:
Hi Chris,
does it make any difference that size of pointer to char is different
than size of pointer to say long int?
Is it? It need not be.
A pointer stores address and address is integer or long int.
That depends on the implementation. I imagine a DOS compiler is
free to choose whatever it finds convenient.
So size of pointer *must* be either 2 or 4


If you say so. Such an answer isn't required by the Standard, though.

It is wise to arrange that your code doesn't care.

--
Chris "electric hedgehog" Dollin
The software engineer's song: "who knows where the time goes".
Nov 15 '05 #9
siliconwafer wrote:
siliconwafer wrote:
What is size of pointer in C on DOS?
is it sizeof(int ) or size of (long int)?
If this ans is present in FAQ pls direct me to tht ouestion
Lets take an example:
char*str = (char*)malloc(1024);


Don't cast the return value of malloc, it's not required.
printf("%d",sizeof(str));
what should get printed?


Anything or nothing since the result of sizeof is size_t which is *not*
int. If you correct all the bugs and produce a conforming C program then
the answer, al others have already stated, is, "whatever the implementer
decided the size of a char* pointer should be." On DOS that is *likely*
to be either 2 or 4 and will probably depend on the options you provide
the compiler.

So, once again, don't write SW that depends on knowing the size of a
pointer.

I believe a corrected program is:

#include <stdio.h> /* Required for printf */
/* If you use malloc, which I don't, you need to include stdlib.h */

int main(void)
{
char *ptr;
/* No need to assign anything since we just want the size of the
pointer */
printf("%lu\n",(unsigned long)sizeof ptr);
/* You get 0 on the Deathstation 9000 in super large pointer
mode where the size of a pointer is one larger than can be
represented in an unsigned long and size_t has a larger range
than unsigned long. */
return 0;
}
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Nov 15 '05 #10
In article <11**********************@z14g2000cwz.googlegroups .com> "siliconwafer" <sp*********@yahoo.com> writes:
does it make any difference that size of pointer to char is different
than size of pointer to say long int?
A pointer stores address and address is integer or long int.So size of
pointer *must* be either 2 or 4


Wrong. An address is not necessarily an integer. It can contain things
like ring number, segment number, address within segment, byte number
within a word and a host of other things.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Nov 15 '05 #11
On 2005-09-29 08:38:44 -0400, "siliconwafer" <sp*********@yahoo.com> said:
Hi Chris,
does it make any difference that size of pointer to char is different
than size of pointer to say long int?
There is nothing wrong with a platform where sizeof(char*) != sizeof(int*).
A pointer stores address and address is integer or long int.
Who says that a pointer must be an integer? The standard certainly doesn't
So size of
pointer *must* be either 2 or 4


That's odd, considering that I'm working on a platform at this very
moment where
(sizeof(void*) == 8).
--
Clark S. Cox, III
cl*******@gmail.com

Nov 15 '05 #12
"Clark S. Cox III" wrote:

On 2005-09-29 08:38:44 -0400, "siliconwafer" <sp*********@yahoo.com> said:

[...]
So size of
pointer *must* be either 2 or 4


That's odd, considering that I'm working on a platform at this very
moment where
(sizeof(void*) == 8).


Although I never worked in C on this platform, the computer I used at
college had 36-bit words and 18-bit addresses. Although there were
opcodes for accessing sub-words, the smallest unit of storage was 36
bits.

I have no idea what "sizeof(void *)" would be on such a platform, but
it is quite possible that it would be "1".

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

Nov 15 '05 #13
siliconwafer wrote:
siliconwafer wrote:
What is size of pointer in C on DOS?
is it sizeof(int ) or size of (long int)?
If this ans is present in FAQ pls direct me to tht ouestion

Lets take an example:
char*str = (char*)malloc(1024);
printf("%d",sizeof(str));
what should get printed?


Someone who can write
printf("%d",sizeof(str));
has no business worrying about the size of a pointer.
The value from sizeof(str) is an unsigned integer that may be wider than
an int (and often is). "%d" expects a signed value, and so is wrong, and
an integral object no larger than an int, and is wrong a second time.

Also, writing
char*str = (char*)malloc(1024);
strongly suggests a failure to include <stdlib.h>, since there is no
excuse for the (char *) cast.

It would probably be better to concentrate on learning the basics of
writing C programs instead of trying to look under the hood at details
you are not ready to explore and need not be the same on the next model
implementation you use.
Nov 15 '05 #14
siliconwafer wrote:
Hi Chris,
does it make any difference that size of pointer to char is different
than size of pointer to say long int?
A pointer stores address and address is integer or long int.
Wrong. You premise is false. So size of
pointer *must* be either 2 or 4
Wrong. Not only is your premise wrong, buteven if it were true there is
no logical connection to your conclusion. A non-sequitor based on false
premises is hardly worth considering.
-Siliconwafer

Nov 15 '05 #15
Le jeudi 29 septembre 2005 à 14:38:44, siliconwafer a écrit dans
comp.lang.c*:
A pointer stores address and address is integer or long int.
Bullshit. Remember MS-DOS where pointers were often two ints: a 16-bit
segment and a 16-bit offset.
So size of pointer *must* be either 2 or 4


More bullshit. In Win64 programming:

sizeof (int) == sizeof (long) == 4 [32 bits]
sizeof (void *) == 8 [64 bits]

--
___________ 29/09/2005 18:28:31
_/ _ \_`_`_`_) Serge PACCALIN -- sp ad mailclub.net
\ \_L_) Il faut donc que les hommes commencent
-'(__) par n'être pas fanatiques pour mériter
_/___(_) la tolérance. -- Voltaire, 1763
Nov 15 '05 #16
"siliconwafer" <sp*********@yahoo.com> writes:
siliconwafer wrote:
What is size of pointer in C on DOS?
is it sizeof(int ) or size of (long int)?
If this ans is present in FAQ pls direct me to tht ouestion


Lets take an example:
char*str = (char*)malloc(1024);
printf("%d",sizeof(str));
what should get printed?


Let's fix your example:

char *str = malloc(1024);
printf("%d\n", (int)sizeof str);

The sizeof operator does not evaluate its operand; all it does is
yield its size in bytes. (There is an exception for VLAs
(variable-length arrays), but that's not relevant here.) So the fact
that you initialized str has no effect on the behavior of the code.
(You should normally check whether the malloc() succeeded, but that
doesn't matter here since you're not using the result.) So:

char *str;
printf("%d\n", (int)sizeof str);

The expression "sizeof str" yields the size in bytes of str, which is
the same as sizeof(char*). The standard says very little about what
this value will be. It's guaranteed to be at least 1; on some
systems, it can be 1. Certain other requirements imply that it needs
to be at least 16 bits in a hosted environment, so sizeof(char*)==1
implies CHAR_BIT>=16. If you don't understand these details yet,
don't worry about it.

There is very little guaranteed relationship between integers and
pointers. They are two entirely different things. A C pointer is
*not* some kind of integer in disguise; it's just a pointer. Its
value refers to some memory location, but the manner in which it does
so is implementation-specific. Different kinds of pointers can have
different sizes (though they tend to be the same on most systems).
You can convert integers to pointers and vice versa, but the results
of doing so are system-specific.

A pointer is not necessarily the same size as any particular integer
type; a system where pointers are 128 bits and the largest integer
type is 64 bits would be perfectly legal.

Pointers point to things. Forget everything else you think you know
about them, and start from there. Re-read the section on pointers in
your C textbook; if you don't have one, K&R2 is excellent. Read
section 4 of the C FAQ.

On a typical modern system, CHAR_BIT (the number of bits in a byte) is
likely to be 8, int is likely to be 32 bits, long is likely to be
either 32 or 64 bits, and pointers are likely to be 32 or 64 bits.
Converting a pointer to an unsigned integer of the same size is likely
to yield something that looks meaningful if you know anything about
the underlying memory addressing of the system. But the C standard is
designed to allow for exceptions to all of these things. You can
write useful code that doesn't depend on any of these assumptions, and
it will work everywhere, not just on "typical" systems.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #17
siliconwafer wrote on 29/09/05 :
What is size of pointer in C on DOS?
is it sizeof(int ) or size of (long int)?


size_t size_of_a_pointer_of_type_T = sizeof (T*);

Out of this, you are not portable.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"There are 10 types of people in the world today;
those that understand binary, and those that dont."
Nov 15 '05 #18
siliconwafer wrote on 29/09/05 :
siliconwafer wrote:
What is size of pointer in C on DOS?
is it sizeof(int ) or size of (long int)?
If this ans is present in FAQ pls direct me to tht ouestion
Lets take an example:
char*str = (char*)malloc(1024);


Useless for the example.

char *str;
printf("%d",sizeof(str));
printf ("%u\n", (unsigned) sizeof str);

BTW, you just need the type...

printf ("%u\n", (unsigned) sizeof (char *));
what should get printed?


Who knows, it's implementation-dependent.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

..sig under repair
Nov 15 '05 #19

siliconwafer wrote:
What is size of pointer in C on DOS?
is it sizeof(int ) or size of (long int)?
If this ans is present in FAQ pls direct me to tht ouestion


The quickest way to find out what pointer sizes are on your particular
implementation:

printf("sizeof(char*): %lu\n", (unsigned long) sizeof(char*));
printf("sizeof(int*): %lu\n", (unsigned long) sizeof(int*));
printf("sizeof(short*): %lu\n", (unsigned long) sizeof(short*));

etc.

Note that pointers to different types may be different sizes, and may
be different between implementations.

Nov 15 '05 #20
"John Bode" <jo*******@my-deja.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
....
The quickest way to find out what pointer sizes are on your particular
implementation:

printf("sizeof(char*): %lu\n", (unsigned long) sizeof(char*));
printf("sizeof(int*): %lu\n", (unsigned long) sizeof(int*));
printf("sizeof(short*): %lu\n", (unsigned long) sizeof(short*));


And chances are that the tree will print the same number. And that's
practically on every system, if not on all.
However, sizeof(void*) and sizeof(void(*)()) are very often different,
consider the Harvard architecure (if you've always programmed in msvc++ on
x86 PC :), where program and data memories aren't necessarily the same thing
and may have different width of either the address bus or data bus or both,
alsmo meaning that a byte in one space isn't necessarily equal to a byte in
the other (in bits).

Alex
Nov 15 '05 #21
"Alexei A. Frounze" <al*****@chat.ru> writes:
"John Bode" <jo*******@my-deja.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
...
The quickest way to find out what pointer sizes are on your particular
implementation:

printf("sizeof(char*): %lu\n", (unsigned long) sizeof(char*));
printf("sizeof(int*): %lu\n", (unsigned long) sizeof(int*));
printf("sizeof(short*): %lu\n", (unsigned long) sizeof(short*));
And chances are that the tree will print the same number. And that's
practically on every system, if not on all.


Probably, but there are valid reasons why char* and void* might be
bigger, or at least have a different representation, than int*.
However, sizeof(void*) and sizeof(void(*)()) are very often different,
consider the Harvard architecure (if you've always programmed in msvc++ on
x86 PC :), where program and data memories aren't necessarily the same thing
and may have different width of either the address bus or data bus or both,
alsmo meaning that a byte in one space isn't necessarily equal to a byte in
the other (in bits).


Yes, differing sizes for data pointers and function pointers are
plausible, but I don't think I've ever used a system where they
actually differ. As for "byte" sizes, the C standard only uses the
term to refer to object sizes; there's no such thing as the size of a
function, in "bytes" or any other units. (A system may have such a
concept, but standard C doesn't refer to it.)

But the most important point is that, most of the time, none of this
should matter. You can write code that doesn't *care* whether
different pointer types have different sizes, and that will work
properly whether they differ or not. Just don't depend on any
assumptions that aren't guaranteed by the standard. It's often
(usually?) *easier* to write portable code than to write code that
depends on system-specific sizes.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #22
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Alexei A. Frounze" <al*****@chat.ru> writes:
"John Bode" <jo*******@my-deja.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
...
The quickest way to find out what pointer sizes are on your particular
implementation:

printf("sizeof(char*): %lu\n", (unsigned long) sizeof(char*));
printf("sizeof(int*): %lu\n", (unsigned long) sizeof(int*));
printf("sizeof(short*): %lu\n", (unsigned long) sizeof(short*));
And chances are that the tree will print the same number. And that's
practically on every system, if not on all.


Probably, but there are valid reasons why char* and void* might be
bigger,


Bigger than what and why?
or at least have a different representation, than int*.
Like what? A few lowest signigicant bits being 0 due to alignment?
However, sizeof(void*) and sizeof(void(*)()) are very often different,
consider the Harvard architecure (if you've always programmed in msvc++ on x86 PC :), where program and data memories aren't necessarily the same thing and may have different width of either the address bus or data bus or both, alsmo meaning that a byte in one space isn't necessarily equal to a byte in the other (in bits).


Yes, differing sizes for data pointers and function pointers are
plausible, but I don't think I've ever used a system where they
actually differ. As for "byte" sizes, the C standard only uses the
term to refer to object sizes; there's no such thing as the size of a
function, in "bytes" or any other units. (A system may have such a
concept, but standard C doesn't refer to it.)


Right.
But the most important point is that, most of the time, none of this
should matter.
True.
You can write code that doesn't *care* whether
different pointer types have different sizes, and that will work
properly whether they differ or not. Just don't depend on any
assumptions that aren't guaranteed by the standard. It's often
(usually?) *easier* to write portable code than to write code that
depends on system-specific sizes.


I'm not sure of this... The practice seem to show lots of examples of the
directly opposite. Many C programmers, the beginners (including me some time
ago), do not know C and the standard well for obvious reasons -- it's new to
them and it's different from whatever they had learned or used before. If
they happen to know a bit about the CPU for which they write their C code,
they're more likely to not use sizeof for the basic types, not care about
the alignment when placing objects in memory, ignore various warnings about
prototypes, conversion/promotion, etc etc. I did it all myself. Now I don't
do it because I'm fortunate enough to have seen (correct my English here if
need be) various platforms, not just the x86. And this taught me how to do
things better. Those who are condemned to x86 and ignorance about C and its
standard, are condemned to making bad code. And it's not easier to write
portable code in that case, it's simply impossible. :)

Alex
Nov 15 '05 #23
"Alexei A. Frounze" <al*****@chat.ru> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Alexei A. Frounze" <al*****@chat.ru> writes:
> "John Bode" <jo*******@my-deja.com> wrote in message
> news:11**********************@g43g2000cwa.googlegr oups.com...
> ...
>> The quickest way to find out what pointer sizes are on your particular
>> implementation:
>>
>> printf("sizeof(char*): %lu\n", (unsigned long) sizeof(char*));
>> printf("sizeof(int*): %lu\n", (unsigned long) sizeof(int*));
>> printf("sizeof(short*): %lu\n", (unsigned long) sizeof(short*));
>
> And chances are that the tree will print the same number. And that's
> practically on every system, if not on all.
Probably, but there are valid reasons why char* and void* might be
bigger,


Bigger than what and why?


Bigger than int* ...
or at least have a different representation, than int*.
... as I think I made clear in the same sentence.

The example I've brought up here several times in the past is the C
implementation on Cray vector machines. The smallest directly
addressible unit of memory is 64 bits, so the obvious value for
CHAR_BIT would be 64 -- except that the system runs a version of Unix,
and there's a need to be able to represent strings of 8-bit characters
and share information with other systems, so the implementation uses
CHAR_BIT==8. An int* (pointing to a 64-bit int) is simply a native
64-bit machine address, but a char* pointer needs to specify which
8-bit byte within the word it points to. This is done (purely in
software) by storing a 3-bit offset in the (otherwise unused)
high-order 3 bits of the pointer.

If the machine used all 64 bits of a word pointer, a byte pointer
would have to store the offset somewhere else -- i.e., it would have
to be bigger than 64 bits.
Like what? A few lowest signigicant bits being 0 due to alignment?


No, see above.

[...]
But the most important point is that, most of the time, none of this
should matter.


True.
You can write code that doesn't *care* whether
different pointer types have different sizes, and that will work
properly whether they differ or not. Just don't depend on any
assumptions that aren't guaranteed by the standard. It's often
(usually?) *easier* to write portable code than to write code that
depends on system-specific sizes.


I'm not sure of this... The practice seem to show lots of examples of the
directly opposite. Many C programmers, the beginners (including me some time
ago), do not know C and the standard well for obvious reasons -- it's new to
them and it's different from whatever they had learned or used before. If
they happen to know a bit about the CPU for which they write their C code,
they're more likely to not use sizeof for the basic types, not care about
the alignment when placing objects in memory, ignore various warnings about
prototypes, conversion/promotion, etc etc. I did it all myself. Now I don't
do it because I'm fortunate enough to have seen (correct my English here if
need be) various platforms, not just the x86. And this taught me how to do
things better. Those who are condemned to x86 and ignorance about C and its
standard, are condemned to making bad code. And it's not easier to write
portable code in that case, it's simply impossible. :)


Perhaps the problem is in the way beginners learn C. If you learn the
language without reference to the details of the underlying machine,
you'll presumably develop the habit of writing portable code because
you don't know how not to. Learning the details of particular
implementations *later* can let you write non-portable code when
necessary, while knowing the difference. (I'm using "you" as a verbal
shorthand; I'm not referring to you personally.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #24
Keith Thompson wrote:

"Alexei A. Frounze" <al*****@chat.ru> writes:

[...]
However, sizeof(void*) and sizeof(void(*)()) are very often different,
consider the Harvard architecure (if you've always programmed in msvc++ on
x86 PC :), where program and data memories aren't necessarily the same thing
and may have different width of either the address bus or data bus or both,
alsmo meaning that a byte in one space isn't necessarily equal to a byte in
the other (in bits).


Yes, differing sizes for data pointers and function pointers are
plausible, but I don't think I've ever used a system where they
actually differ.


(Drifting slightly OT for clc, but still on-topic because it shows
that there is a "real world" platform where these things occur.)

You've never worked in the 16-bit segmented x86 architecture then,
have you? There, pointers were either 16 or 32 bits, depending on
"memory model" and whether it's a data or code pointer.

Model sizeof(void*) sizeof(void(*)())
===== ============= =================
Tiny 2 2
Small 2 2
Compact 4 2
Medium 2 4
Large 4 4
Huge 4 4

And even then, you could coerce a code/data pointer to the other
size using the (implementation-specific) "near" and "far" modifiers.

ie: sizeof(void near *)==2, sizeof(void far *)==4, regardless of
memory model.

[...]

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

Nov 15 '05 #25
Kenneth Brody <ke******@spamcop.net> writes:
Keith Thompson wrote:

[...]
Yes, differing sizes for data pointers and function pointers are
plausible, but I don't think I've ever used a system where they
actually differ.


(Drifting slightly OT for clc, but still on-topic because it shows
that there is a "real world" platform where these things occur.)

You've never worked in the 16-bit segmented x86 architecture then,
have you? There, pointers were either 16 or 32 bits, depending on
"memory model" and whether it's a data or code pointer.


No, I haven't.

Saying that I've never used such a system doesn't imply that they
don't exist, or even that they're particularly rare. I know my own
experience is limited in many ways. (And I know you haven't implied
otherwise; I'm just trying to be as clear as possible.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #26
>You've never worked in the 16-bit segmented x86 architecture then,
have you? There, pointers were either 16 or 32 bits, depending on
"memory model" and whether it's a data or code pointer.

Model sizeof(void*) sizeof(void(*)())
===== ============= =================
Tiny 2 2
Small 2 2
Compact 4 2
Medium 2 4
Large 4 4
Huge 4 4


You forgot a whole bunch of them:

32-bit tiny 4 4
32-bit small 4 4
32-bit compact 6 4
32-bit medium 4 6
32-bit large 6 6
32-bit huge 6 6 also called "intergalactic tremendously enormous"

I don't know how many compilers for 32-bit huge model actually exist,
but sooner or later Windows will need more than 4G for the boot process.

Gordon L. Burditt
Nov 15 '05 #27
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Alexei A. Frounze" <al*****@chat.ru> writes:
"Keith Thompson" <ks***@mib.org> wrote in message ....
Probably, but there are valid reasons why char* and void* might be
bigger,
Bigger than what and why?


Bigger than int* ...
or at least have a different representation, than int*.
... as I think I made clear in the same sentence.

The example I've brought up here several times in the past is the C
implementation on Cray vector machines. The smallest directly
addressible unit of memory is 64 bits, so the obvious value for
CHAR_BIT would be 64 -- except that the system runs a version of Unix,
and there's a need to be able to represent strings of 8-bit characters
and share information with other systems, so the implementation uses
CHAR_BIT==8. An int* (pointing to a 64-bit int) is simply a native
64-bit machine address, but a char* pointer needs to specify which
8-bit byte within the word it points to. This is done (purely in
software) by storing a 3-bit offset in the (otherwise unused)
high-order 3 bits of the pointer.


So, let alone the representation, sizeof(char*) == sizeof(int*) anyway in
this case?
If the machine used all 64 bits of a word pointer, a byte pointer
would have to store the offset somewhere else -- i.e., it would have
to be bigger than 64 bits.


E.g. sizeof(char*) = 2*sizeof(int*) ?
What a waste :)

....
It's often
(usually?) *easier* to write portable code than to write code that
depends on system-specific sizes.


I'm not sure of this... The practice seem to show lots of examples of the directly opposite. Many C programmers, the beginners (including me some time ago), do not know C and the standard well for obvious reasons -- it's new to them and it's different from whatever they had learned or used before. If they happen to know a bit about the CPU for which they write their C code, they're more likely to not use sizeof for the basic types, not care about the alignment when placing objects in memory, ignore various warnings about prototypes, conversion/promotion, etc etc. I did it all myself. Now I don't do it because I'm fortunate enough to have seen (correct my English here if need be) various platforms, not just the x86. And this taught me how to do things better. Those who are condemned to x86 and ignorance about C and its standard, are condemned to making bad code. And it's not easier to write
portable code in that case, it's simply impossible. :)


Perhaps the problem is in the way beginners learn C. If you learn the
language without reference to the details of the underlying machine,
you'll presumably develop the habit of writing portable code because
you don't know how not to. Learning the details of particular
implementations *later* can let you write non-portable code when
necessary, while knowing the difference. (I'm using "you" as a verbal
shorthand; I'm not referring to you personally.)


While I'd agree on the point of view, for some reason many indeed do first
learn something about the underlying hardware and then apply C to it...

Alex
Nov 15 '05 #28
Gordon Burditt wrote:
You've never worked in the 16-bit segmented x86 architecture then,
have you? There, pointers were either 16 or 32 bits, depending on
"memory model" and whether it's a data or code pointer.

Model sizeof(void*) sizeof(void(*)())
===== ============= =================
Tiny 2 2
Small 2 2
Compact 4 2
Medium 2 4
Large 4 4
Huge 4 4


You forgot a whole bunch of them:

32-bit tiny 4 4
32-bit small 4 4
32-bit compact 6 4
32-bit medium 4 6
32-bit large 6 6
32-bit huge 6 6 also called "intergalactic tremendously enormous"

I don't know how many compilers for 32-bit huge model actually exist,
but sooner or later Windows will need more than 4G for the boot process.


Well, I did say "16-bit segmented x86 architecture". :-)

I assume the 6-byte pointers are 16-bit selector plus 32-bit offset?

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

Nov 15 '05 #29
Keith Thompson wrote:

Kenneth Brody <ke******@spamcop.net> writes:
Keith Thompson wrote: [...]
Yes, differing sizes for data pointers and function pointers are
plausible, but I don't think I've ever used a system where they
actually differ.


(Drifting slightly OT for clc, but still on-topic because it shows
that there is a "real world" platform where these things occur.)

You've never worked in the 16-bit segmented x86 architecture then,
have you? There, pointers were either 16 or 32 bits, depending on
"memory model" and whether it's a data or code pointer.


No, I haven't.


Not that it's necessarily a bad thing that you've never had to deal
with the segmented 16-bit real-mode of the x86 CPU...
Saying that I've never used such a system doesn't imply that they
don't exist, or even that they're particularly rare. I know my own
experience is limited in many ways. (And I know you haven't implied
otherwise; I'm just trying to be as clear as possible.)


True. But sometimes people use the argument "but _I've_ never seen
such a system" as a way of justifying the "portability" of some
piece of code.

I happen to know that the programs I work on are not 100% portable.
While many things (like screen and keyboard I/O) are modularized in
system-specific modules, other things are "portable enough" to work
on any Posix system we're likely to port to, with the occasional #if
to tweak minor sections as needed.

On the other hand, I avoid "undefined behavior" like the plague.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Nov 15 '05 #30
go***********@burditt.org (Gordon Burditt) writes:
I don't know how many compilers for 32-bit huge model actually exist,
but sooner or later Windows will need more than 4G for the boot process.


Whew! That's a relief. I thought it did already.
Nov 15 '05 #31
"Tim Rentsch" <tx*@alumnus.caltech.edu> wrote in message
news:kf*************@alumnus.caltech.edu...
go***********@burditt.org (Gordon Burditt) writes:
I don't know how many compilers for 32-bit huge model actually exist,
but sooner or later Windows will need more than 4G for the boot process.


Whew! That's a relief. I thought it did already.


Maybe I missed the point or something, but Watcom C/C++ compiler has support
for far pointers being a 16-bit selector and 32-bit offset. Just if you
didn't know...

Alex
Nov 15 '05 #32
Tim Rentsch wrote:

go***********@burditt.org (Gordon Burditt) writes:
I don't know how many compilers for 32-bit huge model actually exist,
but sooner or later Windows will need more than 4G for the boot process.


Whew! That's a relief. I thought it did already.


This is from the "setup.htm" file in the Windows Vista beta 1 install:

==========

2. When the message "Press any key to boot from CD" appears, press a
key. Windows installation begins.

* If you have an x64-based computer, you might see a blank screen
for long time. It can take 20 minutes or longer before the next
screen appears. Do not turn off your computer or restart it
during this time.

* After the blank screen, you will see a progress bar at the bottom
of the screen. This stage might also take some time to complete.

==========

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

Nov 15 '05 #33
On Tue, 4 Oct 2005 23:25:09 +0400, "Alexei A. Frounze"
<al*****@chat.ru> wrote:
"Tim Rentsch" <tx*@alumnus.caltech.edu> wrote in message
news:kf*************@alumnus.caltech.edu...
go***********@burditt.org (Gordon Burditt) writes:
> I don't know how many compilers for 32-bit huge model actually exist,
> but sooner or later Windows will need more than 4G for the boot process.


Whew! That's a relief. I thought it did already.


Maybe I missed the point or something, but Watcom C/C++ compiler has support
for far pointers being a 16-bit selector and 32-bit offset. Just if you
didn't know...

And it's free!
--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 15 '05 #34

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

12 posts views Thread by Ellarco | last post: by
18 posts views Thread by Tarundeep | last post: by
79 posts views Thread by syntax | last post: by
54 posts views Thread by Neo | last post: by
18 posts views Thread by bsder | last post: by
38 posts views Thread by maadhuu | last post: by
4 posts views Thread by Kenneth Brody | last post: by
33 posts views Thread by Adam Chapman | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.