double pointers

[junky_fellow]

Do all double pointers have same size on a particular implementation.

eg char **c_ptr;
int **i_ptr;

Is the size of c_ptr and i_ptr always same (on same implementation)
or it may be different ?

 

[pete]

Do all double pointers have same size on a particular implementation.

eg char **c_ptr;
int **i_ptr;

Is the size of c_ptr and i_ptr always same (on same implementation)
or it may be different ?

It may be different.

 

[S.Tobias]

Do all double pointers have same size on a particular implementation.

eg char **c_ptr;
int **i_ptr;

Is the size of c_ptr and i_ptr always same (on same implementation)
or it may be different ?

They may be different. They point to different types (which happen
to be pointer types, but this is irrelevant here).
Eg. all of these may have different sizes:
char *pc;
short *ps;
int *pi;
struct s *pst;
union u *pun;
short * *pps;
int * *ppi;
int ** *ppi;
struct s * *ppst;
struct s2* *ppst2;
int ****** *p7i;
void (*pvf)(void);
int (*pif)(void);
const int (*pcif)(void);
int (*pifi)(int);
int (*pifii)(int, int);
etc...

What we only know is that pointer to void and pointer to char
have the same representation, therefore the same size, and that
they must be able to hold all other pointer-to-object values
(after conversion).

However it doesn't follow that their size must be greater or equal
to other pointers (eg. other pointers could have padding bits,
or other information encoded, that make them fatter that absolutely
necessary).

Apart of that, pointers to structs, unions and un/qualified compatible
types have to have the same representation (and size) within
their respective group.

 

[junky_fellow]

Apart of that, pointers to structs, unions and un/qualified compatible
types have to have the same representation (and size) within
their respective group.

Can you please elaborate this ? Also, what do you mean by nu/qualified
compatible types ?

 

[Ravi Uday]

They may be different. They point to different types (which happen
to be pointer types, but this is irrelevant here).
Eg. all of these may have different sizes:

Chapter and verse please for my clarification.

Apart of that, pointers to structs, unions and un/qualified compatible
types have to have the same representation (and size) within
their respective group.

couldnt get that. Do you mean sizeof (struct *a) == sizeof (union *b)
etc !

- Ravi

 

[CBFalconer]

S.Tobias wrote:
.... snip ...


couldnt get that. Do you mean sizeof (struct *a) == sizeof
(union *b) etc !

Yes. This is needed so self-referencing structures can be created,
as in:

struct blah {
struct blah *next;
whatever info;
}

because the need for struct blah * size arises before struct blah
has been defined.

 

[S.Tobias]

Can you please elaborate this ? Also, what do you mean by nu/qualified
compatible types ?

Short for "qualified and unqualified versions of compatible types"

(n869.txt)
# [#27] A pointer to void shall have the same representation
# and alignment requirements as a pointer to a character type.
# Similarly, pointers to qualified or unqualified versions of
# compatible types shall have the same representation and
# alignment requirements.28) All pointers to structure types
# shall have the same representation and alignment
# requirements as each other. All pointers to union types
# shall have the same representation and alignment
# requirements as each other. Pointers to other types need
# not have the same representation or alignment requirements.

These have to have same representation (and size):
struct s1 *pst1;
struct s2 *pst2;

These too:
union u1 *pun1;
union u2 *pun2;

These don't:
struct s1 *pst1;
union u1 *pun1;
and neither do these (incompatible pointed to types):
struct s1 * *ppst1;
struct s2 * *ppst2;

These don't have to have the same representation:
signed int *psi;
unsigned int *pui;

These have to (pointed-to types differ in qualification):
int *pi;
const int *pci;

These don't (incompatible pointed to types):
int * *pi;
const int * *pci;
but these have to (pointed to types differ in const qualification):
int * *pi;
int * const *pci;
and so do these:
const int * *pi;
const int * const *pci;

These have to (compatible types):
int (*paI)[];
int (*paC)[7];
and it can be deduced (by association), that these also
have to (although it's not explicitly demanded; pointed
types are incompatible):
int (*pa7i)[7];
int (*pa9i)[9];

These have to (different, but compatible pointed-to types):
void (*pvf )();
void (*pvfi)(int);
and it can be deduced (similarly as for the arrays above) that
these have to, too:
void (*pvfv)(void);
void (*pvfi)(int);
void (*pvfid)(int, double);
but these don't (incompatible pointed to types):
void (*pvf)();
int (*pif)();
and neither do these:
void (* *ppvfv)(void);
void (* *ppvfi)(int);

These probably may have different representation:
const int (*pcif)();
int (*pif )();
but this is arguable (formally function types are different, but functions
return rvalues which lose qualifiers).

 

[Robert Gamble]

Yes. This is needed so self-referencing structures can be created,
as in:

struct blah {
struct blah *next;
whatever info;
}

because the need for struct blah * size arises before struct blah
has been defined.

I not making the connection here. Why does this require that
sizeof(struct *a) == sizeof(union *b) and from where in the Standard to
you conclude that this statement is guaranteed to be true?

Robert Gamble

 

[Keith Thompson]

Do all double pointers have same size on a particular implementation.

eg char **c_ptr;
int **i_ptr;

Is the size of c_ptr and i_ptr always same (on same implementation)
or it may be different ?

Several people have already answered this; there's no requrement for
them to be the same size. (BTW, the phrase "double pointers" is
potentially misleading; I initially thought you meant double*.)

My question is, why does it matter? How does knowing or not knowing
that char** and int** may not be the same size affect the way you read
or write C programs? It's possible to write code that depends on the
assumption that they're the same size, but it's nearly impossible to
write *good* code that does so.

If you're asking out of idle curiosity, that's fine; idle curiosity is
a good thing (legends about cats notwithstanding). But if you intend
to make use of the information, my advice is that you almost certainly
don't need to. For most C programming, there's little need to mix
pointers of different types. For the cases where it's necessary, the
language's guarantees about conversions to and from void*, and the
equivalent representation of void* and character pointer types, should
be sufficient -- and does not depend on the sizes of the pointers.

 

[CBFalconer]

I not making the connection here. Why does this require that
sizeof(struct *a) == sizeof(union *b) and from where in the Standard
to you conclude that this statement is guaranteed to be true?

Because, to saw off enough space to hold a struct blah, you have to
know how much room a struct blah * takes (with the above
definition). Thus the size and alignment of a struct blah * cannot
depend on the size of a struct blah.

 

[Robert Gamble]

Because, to saw off enough space to hold a struct blah, you have to
know how much room a struct blah * takes (with the above
definition). Thus the size and alignment of a struct blah * cannot
depend on the size of a struct blah.

What does this have to do with unions though?

Robert Gamble

 

[Keith Thompson]

Robert Gamble wrote: [...]

I not making the connection here. Why does this require that
sizeof(struct *a) == sizeof(union *b) and from where in the Standard
to you conclude that this statement is guaranteed to be true?

Because, to saw off enough space to hold a struct blah, you have to
know how much room a struct blah * takes (with the above
definition). Thus the size and alignment of a struct blah * cannot
depend on the size of a struct blah.

That implies that all struct pointers have to be the same size, and
that all union pointers have to be the same size. It doesn't imply
that struct pointers have to be the same size as union pointers
(though I'd bet they are on everything other than the DS9K).