Equivalency of Integral Pointers

[William Ahern]

I'm writing an unpack function which uses "c", "h", "l", "q" format tokens
to specify the type of the integral object pointer. To support fixed-width
types, a la <stdint.h>, another format specifier, "i", can be prefixed with
the width--8, 16, 32, 64, etc. Then, a jump table is used to branch to the
native type conversion based on the size of the native type. (This is
distinct from specifying the number of input bits to consume in the
conversion, and in general disregards the propriety of such fixed-width to
native type-punning.)

Problem: if we don't match a native type, and we wish to soldier on,
discarding input bits and skipping the variable argument without
deferencing, does `va_arg(ap, int *)' exhibit well-defined behavior in
attempting to consume _any_ integral pointer variable argument?

Loose contrapositive: must all integral pointers have the same size?

[Barry Schwarz]

Re: Equivalency of Integral Pointers

On Fri, 8 Aug 2008 00:22:51 -0700, William Ahern
<william@wilbur .25thandClement .comwrote:

>I'm writing an unpack function which uses "c", "h", "l", "q" format tokens
>to specify the type of the integral object pointer. To support fixed-width
>types, a la <stdint.h>, another format specifier, "i", can be prefixed with
>the width--8, 16, 32, 64, etc. Then, a jump table is used to branch to the
>native type conversion based on the size of the native type. (This is
>distinct from specifying the number of input bits to consume in the
>conversion, and in general disregards the propriety of such fixed-width to
>native type-punning.)
>
>Problem: if we don't match a native type, and we wish to soldier on,
>discarding input bits and skipping the variable argument without
>deferencing, does `va_arg(ap, int *)' exhibit well-defined behavior in
>attempting to consume _any_ integral pointer variable argument?
>
>Loose contrapositive: must all integral pointers have the same size?

There is no requirement that a short* have the same size or
representation as an int* or long*. There are only a couple of
guarantees:

char* and void* have the same size and representation
all struct and union pointers have the same size and
representation
all function pointers have the same size and representation

--
Remove del for email

[Eric Sosman]

Re: Equivalency of Integral Pointers

Barry Schwarz wrote:

[...]
char* and void* have the same size and representation
all struct and union pointers have the same size and
representation

For clarity's sake: All struct pointers have the same size
and representation, and all union pointers have the same size
and representation. There is no requirement that a struct
pointer and a union pointer look the same. (Or if there is,
I'd appreciate being corrected on this, er, point.)

all function pointers have the same size and representation

--
Eric Sosman
esosman@ieee-dot-org.invalid

[Antoninus Twink]

Re: Equivalency of Integral Pointers

On 8 Aug 2008 at 7:22, William Ahern wrote:

Does `va_arg(ap, int *)' exhibit well-defined behavior in attempting
to consume _any_ integral pointer variable argument?
>
Loose contrapositive: must all integral pointers have the same size?

In practise, yes, of course, absolutely.

[Malcolm McLean]

Re: Equivalency of Integral Pointers


"Ben Bacarisse" <ben.usenet@bsb .me.ukwrote in message

I think the only defined way is to require that all the pointer
parameters be converted to void * in the calling function,
>

Which IMO is unacceptable. I think you need to accept that the code will
break if shorts have a different representation to int. Or better still
establish a convention that int is the only integral type in actual use.

--
Free games and programming goodies.

http://www.personal.leeds.ac.uk/~bgy1mm

[Ben Bacarisse]

Re: Equivalency of Integral Pointers

"Malcolm McLean" <regniztar@btin ternet.comwrite s:

"Ben Bacarisse" <ben.usenet@bsb .me.ukwrote in message

>I think the only defined way is to require that all the pointer
>parameters be converted to void * in the calling function,
>>

Which IMO is unacceptable.

Yes. Maybe you prefer it if I agree with you rather than the other
way round. I can't think why else you'd snip the part where I say I
don't like this solution either!

I think you need to accept that the code
will break if shorts have a different representation to int.

But here I don't see the connection. All the OP wants to do is to
skip over an unused va_arg pointer. It is very unlikely that the
kind of int pointed to will matter.

Or better
still establish a convention that int is the only integral type in
actual use.

And how many bits should it have? ;-)

--
Ben.

[Keith Thompson]

Re: Equivalency of Integral Pointers

William Ahern <william@wilbur .25thandClement .comwrites:
[...]

Loose contrapositive: must all integral pointers have the same size?

Not necessarily. There are good reasons on some (fairly uncommon)
systems for byte pointers to be bigger than word pointers, for
example.

It may be that you'll never run into such a system. If you're
concerned about the possibility, but not concerned enough to make your
code work correctly on such a system (which is a perfectly legitimate
choice), you can check during program initialization whether different
pointer-to-integer types have the same size, and abort immediately if
they don't.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ben Bacarisse]

Re: Equivalency of Integral Pointers

Ben Bacarisse <ben.usenet@bsb .me.ukwrites:

William Ahern <william@wilbur .25thandClement .comwrites:
>

>I'm writing an unpack function which uses "c", "h", "l", "q" format tokens
>to specify the type of the integral object pointer. To support fixed-width
>types, a la <stdint.h>, another format specifier, "i", can be prefixed with
>the width--8, 16, 32, 64, etc.

<snip>

The trouble is that, while I can't think of an implementation which
will catch you if you do the undefined va_arg(ap, int *),

When I wrote that, I had not spotted the "8". When I saw Keith
Thompson's reply, I went back and read your post again and saw that
you are including byte pointers. I might still be inclined to "wing
it" but there are more machines with wider char * (and void *) than
there are with different sized pointers to the other integer types.
They tend to be word-addressed number-crunchers on the whole.

--
Ben.

[Barry Schwarz]

Re: Equivalency of Integral Pointers

On Fri, 08 Aug 2008 22:06:22 +0100, Ben Bacarisse
<ben.usenet@bsb .me.ukwrote:

>"Malcolm McLean" <regniztar@btin ternet.comwrite s:
>

>"Ben Bacarisse" <ben.usenet@bsb .me.ukwrote in message

>>I think the only defined way is to require that all the pointer
>>parameters be converted to void * in the calling function,
>>>

>Which IMO is unacceptable.

>
>Yes. Maybe you prefer it if I agree with you rather than the other
>way round. I can't think why else you'd snip the part where I say I
>don't like this solution either!
>

>I think you need to accept that the code
>will break if shorts have a different representation to int.

>
>But here I don't see the connection. All the OP wants to do is to
>skip over an unused va_arg pointer. It is very unlikely that the
>kind of int pointed to will matter.

It is not the kind of integer pointed to; it is the size of the
pointers themselves. If the pointers have different sizes, attempting
to skip over a short* with code that references an int* will cause the
wrong number of bytes to be skipped.

--
Remove del for email

[Ben Bacarisse]

Re: Equivalency of Integral Pointers

Barry Schwarz <schwarzb@dqel. comwrites:

On Fri, 08 Aug 2008 22:06:22 +0100, Ben Bacarisse
<ben.usenet@bsb .me.ukwrote:
>

>>"Malcolm McLean" <regniztar@btin ternet.comwrite s:
>>

>>"Ben Bacarisse" <ben.usenet@bsb .me.ukwrote in message
>>>I think the only defined way is to require that all the pointer
>>>parameters be converted to void * in the calling function,
>>>>
>>Which IMO is unacceptable.

>>
>>Yes. Maybe you prefer it if I agree with you rather than the other
>>way round. I can't think why else you'd snip the part where I say I
>>don't like this solution either!
>>

>>I think you need to accept that the code
>>will break if shorts have a different representation to int.

>>
>>But here I don't see the connection. All the OP wants to do is to
>>skip over an unused va_arg pointer. It is very unlikely that the
>>kind of int pointed to will matter.

>
It is not the kind of integer pointed to; it is the size of the
pointers themselves. If the pointers have different sizes, attempting
to skip over a short* with code that references an int* will cause the
wrong number of bytes to be skipped.

Totally agree. I was claiming (having failed to spot that 8-bit
integers -- i.e. bytes -- are also being pointed to) that it is
unlikely that and int * and shot * will be different length. I know
this is possible, but the most common pointer size differences are
between char */void * and all other objects pointers (function
pointers not being at issue here). I could not see why Malcolm was
introducing the differences between the representations of the ints
themselves when, as you say, it is the pointer sizes that matter.

Of course, this is all about what happens in practise. On paper, just
accessing va_arg(ap, int *) when the corresponding parameter is a long
* is UB not matter what the pointer sizes and representations .

--
Ben.

[Flash Gordon]

Re: Equivalency of Integral Pointers

Barry Schwarz wrote, On 08/08/08 09:12:

<snip>

There is no requirement that a short* have the same size or
representation as an int* or long*. There are only a couple of
guarantees:
>
char* and void* have the same size and representation
all struct and union pointers have the same size and
representation
all function pointers have the same size and representation

I cannot find a requirement for all function pointers to have the same
size and type. You are allowed to convert from one function pointer type
to another and back getting back the original pointer, but that is not
the same. Of course, I might have missed the requirement. Also I doubt
there are any implementations where different function pointer types
have different representations (apart from non-standard things like far
function pointers).
--
Flash Gordon

[Harald van =?UTF-8?b?RMSzaw==?=]

Re: Equivalency of Integral Pointers

On Sun, 10 Aug 2008 19:52:50 +0100, Flash Gordon wrote:

Barry Schwarz wrote, On 08/08/08 09:12:
<snip>

> all function pointers have the same size and representation

>
I cannot find a requirement for all function pointers to have the same
size and type.

There isn't in the general case. However, there is an implicit requirement
that for example void(*)(int) and void(*)(long) have the same size and
representation, because both are required to have the same size and
representation as void(*)(). Similar arguments also apply to pointers to
arrays of different lengths.

[Keith Thompson]

Re: Equivalency of Integral Pointers

Flash Gordon <spam@flash-gordon.me.ukwri tes:
[...]

I cannot find a requirement for all function pointers to have the same
size and type.

You mean "same size and representation" .

You are allowed to convert from one function pointer
type to another and back getting back the original pointer, but that
is not the same. Of course, I might have missed the requirement. Also
I doubt there are any implementations where different function pointer
types have different representations (apart from non-standard things
like far function pointers).

I think you're right.

C99 6.2.6.1 begins:

The representations of all types are unspecified except as stated
in this subclause.

There's nothing about pointer representations there.

(Quibble: "this subclause" could be taken to refer to 6.2.6.1 rather
than 6.2.6; if so, it excludes 6.2.6.2, which discusses the
representations of integer types. I have no doubt that it's intended
to refer to 6.2.6.)

And 6.3.2.3 talks about the semantics of *converting* from one
pointer-to-function type to another, but those conversions could be
non-trivial.

But the simplest way to satisfy the standard's requirements would be
to give all pointer-to-function types the same representation.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Flash Gordon]

Re: Equivalency of Integral Pointers

Keith Thompson wrote, On 10/08/08 21:05:

Flash Gordon <spam@flash-gordon.me.ukwri tes:
[...]

>I cannot find a requirement for all function pointers to have the same
>size and type.

>
You mean "same size and representation" .

Yes, I did.

> You are allowed to convert from one function pointer
>type to another and back getting back the original pointer, but that
>is not the same. Of course, I might have missed the requirement. Also
>I doubt there are any implementations where different function pointer
>types have different representations (apart from non-standard things
>like far function pointers).

>
I think you're right.
>
C99 6.2.6.1 begins:
>
The representations of all types are unspecified except as stated
in this subclause.
>
There's nothing about pointer representations there.

<snip>

But the simplest way to satisfy the standard's requirements would be
to give all pointer-to-function types the same representation.

Yes, that is about what I thought. It is purely academic interest since
I'm not about to do anything relying on the size/representation being
the same.
--
Flash Gordon

[Keith Thompson]

Re: Equivalency of Integral Pointers

Flash Gordon <spam@flash-gordon.me.ukwri tes:

Keith Thompson wrote, On 10/08/08 21:05:

>Flash Gordon <spam@flash-gordon.me.ukwri tes:
>[...]

>>I cannot find a requirement for all function pointers to have the same
>>size and type.

>You mean "same size and representation" .

>
Yes, I did.
>

>> You are allowed to convert from one function pointer
>>type to another and back getting back the original pointer, but that
>>is not the same. Of course, I might have missed the requirement. Also
>>I doubt there are any implementations where different function pointer
>>types have different representations (apart from non-standard things
>>like far function pointers).

>I think you're right.
>C99 6.2.6.1 begins:
> The representations of all types are unspecified except as stated
> in this subclause.
>There's nothing about pointer representations there.

>
<snip>
>

>But the simplest way to satisfy the standard's requirements would be
>to give all pointer-to-function types the same representation.

>
Yes, that is about what I thought. It is purely academic interest
since I'm not about to do anything relying on the size/representation
being the same.

On the other hand, Harald made a very interesting point in this thread
about pointers to non-prototyped function types, that void(*)(int)
must have the same size and represenatation as void(*)(), which must
have the same size and represenatation as void(*)(long), and so forth.
I *think* he's right, though I haven't taken the time to think it
through. (I tend to ignore the existence of non-prototyped functions,
even though they still exist in both C90 and C99.)

But it's *still* of purely academic interest.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"