«

"John Bode" <> wrote in message
news: 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

"Alexei A. Frounze" <> writes:
> "John Bode" <> wrote in message
> news: 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) kst- <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.

"Keith Thompson" <kst-> wrote in message
news:...
> "Alexei A. Frounze" <> writes:
> > "John Bode" <> wrote in message
> > news: 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

"Alexei A. Frounze" <> writes:
> "Keith Thompson" <kst-> wrote in message
> news:...
>> "Alexei A. Frounze" <> writes:
>> > "John Bode" <> wrote in message
>> > news: 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) kst- <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.

Keith Thompson wrote:
>
> "Alexei A. Frounze" <> 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: <private.php?do=newpm&u=>

Kenneth Brody <> 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) kst- <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.

>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

"Keith Thompson" <kst-> wrote in message
news:...
> "Alexei A. Frounze" <> writes:
> > "Keith Thompson" <kst-> 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

Keith Thompson wrote:
>
> Kenneth Brody <> 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: <private.php?do=newpm&u=>

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: <private.php?do=newpm&u=>