Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > [va_list *] Is this legal ?

Reply
Thread Tools

[va_list *] Is this legal ?

 
 
m.labanowicz@gmail.com
Guest
Posts: n/a
 
      01-16-2013
Hello,

I'm trying to compile following example:

-----{test:BEG}----------------------------------------
01: #include <stdio.h>
02: #include <stdarg.h>
03: #include <stdlib.h>
04: int va_get_int(va_list * ap) {
05: return va_arg(*ap, int);
06: }
07: char * va_get_chrptr(va_list * ap) {
08: return va_arg(*ap, char *);
09: }
10: void fooA(va_list ap) {
11: char const * txt = NULL;
12: printf("A:int = %d\n", va_arg(ap, int));
13: txt = va_arg(ap, char *);
14: printf("Atr = %p\n", (void *)txt);
15: printf("Atr = \"%s\"\n", txt);
16: }
17: void fooB(va_list ap) {
18: char const * txt = NULL;
19: printf("B:int = %d\n", va_get_int(&ap));
20: txt = va_get_chrptr(&ap);
21: printf("Btr = %p\n", (void *)txt);
22: printf("Btr = \"%s\"\n", txt);
23: }
24: void bar(char const * arg0, ...) {
25: va_list ap;
26: printf("arg0 = \"%s\"\n", arg0);
27: va_start(ap, arg0);
28: fooA(ap);
29: va_end(ap);
30: va_start(ap, arg0);
31: fooB(ap);
32: va_end(ap);
33: va_start(ap, arg0);
34: fooA(ap);
35: va_end(ap);
36: }
37: int main(void) {
38: bar("koko", 23, "txt");
39: return EXIT_SUCCESS;
40: }
-----{test:EOF}----------------------------------------

[32 bit machine]
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
$ gcc -W -Wall -ansi -pedantic test.c
$ ./a.out
arg0 = "koko"
A:int = 23
Atr = 0x8048669
Atr = "txt"
B:int = 23
Btr = 0x8048669
Btr = "txt"
A:int = 23
Atr = 0x8048669
Atr = "txt"

[64 bit machine]
gcc (Ubuntu/Linaro 4.7.2-11precise2) 4.7.2
$ gcc -W -Wall -ansi -pedantic test.c
test.c: In function 'fooB':
test.c:18:3: warning: passing argument 1 of 'va_get_int' from incompatible pointer type [enabled by default]
test.c:4:5: note: expected 'struct __va_list_tag (*)[1]' but argument is of type 'struct __va_list_tag **'
test.c:19:3: warning: passing argument 1 of 'va_get_chrptr' from incompatible pointer type [enabled by default]
test.c:7:8: note: expected 'struct __va_list_tag (*)[1]' but argument is of type 'struct __va_list_tag **'
$ ./a.out
arg0 = "koko"
A:int = 23
Atr = 0x40096d
Atr = "txt"
B:int = -443987883
Btr = 0x455441ed31455541
Segmentation fault (core dumped)

It seems that pointer to 'va_list' can not be used,
ok, I have changed code to:
-----{diff:BEG}----------------------------------------
4,5c4,5
< int va_get_int(va_list * ap) {
< return va_arg(*ap, int);
---
> int va_get_int(va_list ap) {
> return va_arg(ap, int);

7,8c7,8
< char * va_get_chrptr(va_list * ap) {
< return va_arg(*ap, char *);
---
> char * va_get_chrptr(va_list ap) {
> return va_arg(ap, char *);

19,20c19,20
< printf("B:int = %d\n", va_get_int(&ap));
< txt = va_get_chrptr(&ap);
---
> printf("B:int = %d\n", va_get_int(ap));
> txt = va_get_chrptr(ap);

-----{diff:EOF}----------------------------------------

After that both compilers are silent,
no errors, no warnings, but:

[64 bit machine]
gcc (Ubuntu/Linaro 4.7.2-11precise2) 4.7.2
$ gcc -W -Wall -ansi -pedantic test2.c
$ ./a.out
arg0 = "koko"
A:int = 23
Atr = 0x40096d
Atr = "txt"
B:int = 23
Btr = 0x40096d
Btr = "txt"
A:int = 23
Atr = 0x40096d
Atr = "txt"

[32 bit machine]
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
$ gcc -W -Wall -ansi -pedantic test2.c
$ ./a.out
arg0 = "koko"
A:int = 23
Atr = 0x8048669
Atr = "txt"
B:int = 23
Btr = 0x17
Segmentation fault


Best Regards

--
Maciej Labanowicz
 
Reply With Quote
 
 
 
 
Noob
Guest
Posts: n/a
 
      01-16-2013
Robert Wessel wrote:

> Mind you that there is no guarantee in C that there is *any* integer
> type that can actually hold a pointer (although both Posix and Windows
> require such).


However, if a given implementation provides intptr_t and/or uintptr_t,
then one can use either(?) to store the representation of an object pointer.

Tangential questions:

- Can uintptr_t store the representation of a function pointer?

- Why provide signed and unsigned types?

Regards.

 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      01-16-2013
http://www.velocityreviews.com/forums/(E-Mail Removed) writes:

> I'm trying to compile following example:
>
> -----{test:BEG}----------------------------------------
> 01: #include <stdio.h>
> 02: #include <stdarg.h>
> 03: #include <stdlib.h>
> 04: int va_get_int(va_list * ap) {
> 05: return va_arg(*ap, int);
> 06: }
> 07: char * va_get_chrptr(va_list * ap) {
> 08: return va_arg(*ap, char *);
> 09: }
> 10: void fooA(va_list ap) {
> 11: char const * txt = NULL;
> 12: printf("A:int = %d\n", va_arg(ap, int));
> 13: txt = va_arg(ap, char *);
> 14: printf("Atr = %p\n", (void *)txt);
> 15: printf("Atr = \"%s\"\n", txt);
> 16: }
> 17: void fooB(va_list ap) {
> 18: char const * txt = NULL;
> 19: printf("B:int = %d\n", va_get_int(&ap));
> 20: txt = va_get_chrptr(&ap);
> 21: printf("Btr = %p\n", (void *)txt);
> 22: printf("Btr = \"%s\"\n", txt);
> 23: }
> 24: void bar(char const * arg0, ...) {
> 25: va_list ap;
> 26: printf("arg0 = \"%s\"\n", arg0);
> 27: va_start(ap, arg0);
> 28: fooA(ap);
> 29: va_end(ap);
> 30: va_start(ap, arg0);
> 31: fooB(ap);
> 32: va_end(ap);
> 33: va_start(ap, arg0);
> 34: fooA(ap);
> 35: va_end(ap);
> 36: }
> 37: int main(void) {
> 38: bar("koko", 23, "txt");
> 39: return EXIT_SUCCESS;
> 40: }
> -----{test:EOF}----------------------------------------
>
> [32 bit machine] [..snip..]
>
> [64 bit machine]
> gcc (Ubuntu/Linaro 4.7.2-11precise2) 4.7.2
> $ gcc -W -Wall -ansi -pedantic test.c
> test.c: In function 'fooB':
> test.c:18:3: warning: passing argument 1 of 'va_get_int' from incompatible pointer type [enabled by default]
> test.c:4:5: note: expected 'struct __va_list_tag (*)[1]' but argument is of type 'struct __va_list_tag **'
> test.c:19:3: warning: passing argument 1 of 'va_get_chrptr' from incompatible pointer type [enabled by default]
> test.c:7:8: note: expected 'struct __va_list_tag (*)[1]' but argument is of type 'struct __va_list_tag **'
> [..snip..]


These messages appear not to match the given source file
(some of the line numbers are off). This makes me
suspicious that what is being reported may not match what
really occurred.

Incidentally, I suggest using -pedantic-errors rather than
just -pedantic. The conditions being reported above should
be errors, not warnings; -pedantic-errors should do that.

Also, I think the problem you're having is not taking into
account that the va_list type could be an array type. This
means that a declaration like this

void
blah(){
va_list ap;
}

and a declaration like this

void
bleah( va_list ap ){
}

even though it looks like the same type is involved in both
cases, actually the two types are different. Try changing
the function fooB() so its declaration looks like this

void fooB( va_list *ap ){ /* etc */

and make other changes as needed (the call to fooB(), and
the functions that fooB() calls that take this parameter).
Using the type 'va_list *' should work, _if_ you use it all
the way along the call chain to the function that declares
the original 'va_list ap;' local variable, because that
avoids the problem with having an array type for a parameter
declaration.
 
Reply With Quote
 
Heikki Kallasjoki
Guest
Posts: n/a
 
      01-16-2013
On 2013-01-16, (E-Mail Removed) <(E-Mail Removed)> wrote:
> I'm trying to compile following example:
>
> -----{test:BEG}----------------------------------------
> 01: #include <stdio.h>
> 02: #include <stdarg.h>
> 03: #include <stdlib.h>
> 04: int va_get_int(va_list * ap) {
> 05: return va_arg(*ap, int);
> 06: }
> 07: char * va_get_chrptr(va_list * ap) {
> 08: return va_arg(*ap, char *);
> 09: }
> 10: void fooA(va_list ap) {
> 11: char const * txt = NULL;
> 12: printf("A:int = %d\n", va_arg(ap, int));
> 13: txt = va_arg(ap, char *);
> 14: printf("Atr = %p\n", (void *)txt);
> 15: printf("Atr = \"%s\"\n", txt);
> 16: }
> 17: void fooB(va_list ap) {
> 18: char const * txt = NULL;
> 19: printf("B:int = %d\n", va_get_int(&ap));
> 20: txt = va_get_chrptr(&ap);
> 21: printf("Btr = %p\n", (void *)txt);
> 22: printf("Btr = \"%s\"\n", txt);
> 23: }
> 24: void bar(char const * arg0, ...) {
> 25: va_list ap;
> 26: printf("arg0 = \"%s\"\n", arg0);
> 27: va_start(ap, arg0);
> 28: fooA(ap);
> 29: va_end(ap);
> 30: va_start(ap, arg0);
> 31: fooB(ap);
> 32: va_end(ap);
> 33: va_start(ap, arg0);
> 34: fooA(ap);
> 35: va_end(ap);
> 36: }
> 37: int main(void) {
> 38: bar("koko", 23, "txt");
> 39: return EXIT_SUCCESS;
> 40: }
> -----{test:EOF}----------------------------------------

[...]
> It seems that pointer to 'va_list' can not be used,
> ok, I have changed code to:
> -----{diff:BEG}----------------------------------------
> 4,5c4,5
>< int va_get_int(va_list * ap) {
>< return va_arg(*ap, int);
> ---
>> int va_get_int(va_list ap) {
>> return va_arg(ap, int);

> 7,8c7,8
>< char * va_get_chrptr(va_list * ap) {
>< return va_arg(*ap, char *);
> ---
>> char * va_get_chrptr(va_list ap) {
>> return va_arg(ap, char *);

> 19,20c19,20
>< printf("B:int = %d\n", va_get_int(&ap));
>< txt = va_get_chrptr(&ap);
> ---
>> printf("B:int = %d\n", va_get_int(ap));
>> txt = va_get_chrptr(ap);

> -----{diff:EOF}----------------------------------------


Due to C11 7.16p3:

If access to the varying arguments is desired, the called function
shall declare an object (generally referred to as ap in this
subclause) having type va_list. The object ap may be passed as an
argument to another function; if that function invokes the va_arg
macro with parameter ap, the value of ap in the calling function is
indeterminate and shall be passed to the va_end macro prior to any
further reference to ap.

FOOTNOTE 253) It is permitted to create a pointer to a va_list and
pass that pointer to another function, in which case the original
function may make further use of the original list after the other
function returns.

....the rewritten version seems to be unambiguously illegal. However,
the footnote seems to slightly suggest that the original code ought to
be permitted, though admittedly by a strict reading it does not
guarantee that anything else than the function declaring the va_list may
form the pointer to it, and only pass it to a single other function.
Note that if you rewrite it so that fooB itself also takes a "va_list *"
argument, things (at least on my system) work out right on both 32 and
64 bits; example pasted to:
http://sprunge.us/gabU

(Presumably, and based on the warning messages emitted, the difference
is due to "[1]" meaning different things in a function parameter
declaration than elsewhere.)

--
Heikki Kallasjoki
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      01-16-2013
Robert Wessel <(E-Mail Removed)> writes:

> On Wed, 16 Jan 2013 00:15:12 -0800 (PST), (E-Mail Removed)
> wrote:
>
>>Hello,
>>
>>I'm trying to compile following example:
>>
>>-----{test:BEG}----------------------------------------
>>01: #include <stdio.h>
>>02: #include <stdarg.h>
>>03: #include <stdlib.h>
>>04: int va_get_int(va_list * ap) {
>>05: return va_arg(*ap, int);
>>06: }
>>07: char * va_get_chrptr(va_list * ap) {
>>08: return va_arg(*ap, char *);
>>09: }
>>10: void fooA(va_list ap) {
>>11: char const * txt = NULL;
>>12: printf("A:int = %d\n", va_arg(ap, int));
>>13: txt = va_arg(ap, char *);
>>14: printf("Atr = %p\n", (void *)txt);
>>15: printf("Atr = \"%s\"\n", txt);
>>16: }
>>17: void fooB(va_list ap) {
>>18: char const * txt = NULL;
>>19: printf("B:int = %d\n", va_get_int(&ap));
>>20: txt = va_get_chrptr(&ap);
>>21: printf("Btr = %p\n", (void *)txt);
>>22: printf("Btr = \"%s\"\n", txt);
>>23: }
>>24: void bar(char const * arg0, ...) {
>>25: va_list ap;
>>26: printf("arg0 = \"%s\"\n", arg0);
>>27: va_start(ap, arg0);
>>28: fooA(ap);
>>29: va_end(ap);
>>30: va_start(ap, arg0);
>>31: fooB(ap);
>>32: va_end(ap);
>>33: va_start(ap, arg0);
>>34: fooA(ap);
>>35: va_end(ap);
>>36: }
>>37: int main(void) {
>>38: bar("koko", 23, "txt");
>>39: return EXIT_SUCCESS;
>>40: }
>>-----{test:EOF}----------------------------------------
>>
>>[32 bit machine]
>>gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
>>$ gcc -W -Wall -ansi -pedantic test.c
>>$ ./a.out
>>arg0 = "koko"
>>A:int = 23
>>Atr = 0x8048669
>>Atr = "txt"
>>B:int = 23
>>Btr = 0x8048669
>>Btr = "txt"
>>A:int = 23
>>Atr = 0x8048669
>>Atr = "txt"
>>
>>[64 bit machine]
>>gcc (Ubuntu/Linaro 4.7.2-11precise2) 4.7.2
>>$ gcc -W -Wall -ansi -pedantic test.c
>>test.c: In function 'fooB':
>>test.c:18:3: warning: passing argument 1 of 'va_get_int' from incompatible pointer type [enabled by default]
>>test.c:4:5: note: expected 'struct __va_list_tag (*)[1]' but argument is of type 'struct __va_list_tag **'
>>test.c:19:3: warning: passing argument 1 of 'va_get_chrptr' from incompatible pointer type [enabled by default]
>>test.c:7:8: note: expected 'struct __va_list_tag (*)[1]' but argument is of type 'struct __va_list_tag **'
>>$ ./a.out
>>arg0 = "koko"
>>A:int = 23
>>Atr = 0x40096d
>>Atr = "txt"
>>B:int = -443987883
>>Btr = 0x455441ed31455541
>>Segmentation fault (core dumped)
>>
>>It seems that pointer to 'va_list' can not be used,
>>ok, I have changed code to:
>>-----{diff:BEG}----------------------------------------
>>4,5c4,5
>>< int va_get_int(va_list * ap) {
>>< return va_arg(*ap, int);
>>---
>>> int va_get_int(va_list ap) {
>>> return va_arg(ap, int);

>>7,8c7,8
>>< char * va_get_chrptr(va_list * ap) {
>>< return va_arg(*ap, char *);
>>---
>>> char * va_get_chrptr(va_list ap) {
>>> return va_arg(ap, char *);

>>19,20c19,20
>>< printf("B:int = %d\n", va_get_int(&ap));
>>< txt = va_get_chrptr(&ap);
>>---
>>> printf("B:int = %d\n", va_get_int(ap));
>>> txt = va_get_chrptr(ap);

>>-----{diff:EOF}----------------------------------------
>>
>>After that both compilers are silent,
>>no errors, no warnings, but:
>>
>>[64 bit machine]
>>gcc (Ubuntu/Linaro 4.7.2-11precise2) 4.7.2
>>$ gcc -W -Wall -ansi -pedantic test2.c
>>$ ./a.out
>>arg0 = "koko"
>>A:int = 23
>>Atr = 0x40096d
>>Atr = "txt"
>>B:int = 23
>>Btr = 0x40096d
>>Btr = "txt"
>>A:int = 23
>>Atr = 0x40096d
>>Atr = "txt"
>>
>>[32 bit machine]
>>gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
>>$ gcc -W -Wall -ansi -pedantic test2.c
>>$ ./a.out
>>arg0 = "koko"
>>A:int = 23
>>Atr = 0x8048669
>>Atr = "txt"
>>B:int = 23
>>Btr = 0x17
>>Segmentation fault

>
>
> On most 64 bit implementations of C, pointers are 64 bits and ints are
> 32, thus attempting to squeeze a 64 bit address through a 32 bit int
> is unlikely to be successful.
>
> On most 64 bit *nix, long is 64 bits, while on windows long remains 32
> bits. In both cases explicitly 64 bit types will be provided by the
> compiler.
>
> Mind you that there is no guarantee in C that there is *any* integer
> type that can actually hold a pointer (although both Posix and Windows
> require such).


What makes you think this has anything to do with his
problem?
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      01-16-2013
Heikki Kallasjoki <(E-Mail Removed)> writes:

> On 2013-01-16, (E-Mail Removed) <(E-Mail Removed)> wrote:
>> I'm trying to compile following example: [snip]

>
> Due to C11 7.16p3:
>
> If access to the varying arguments is desired, the called function
> shall declare an object (generally referred to as ap in this
> subclause) having type va_list. The object ap may be passed as an
> argument to another function; if that function invokes the va_arg
> macro with parameter ap, the value of ap in the calling function is
> indeterminate and shall be passed to the va_end macro prior to any
> further reference to ap.
>
> FOOTNOTE 253) It is permitted to create a pointer to a va_list and
> pass that pointer to another function, in which case the original
> function may make further use of the original list after the other
> function returns.
>
> ...the rewritten version seems to be unambiguously illegal. However,
> the footnote seems to slightly suggest that the original code ought to
> be permitted,


The problem is what that code is making is not a pointer to a
va_list but (in some cases) a pointer to a different type, and
the result of that is not compatible with a va_list *.

> though admittedly by a strict reading it does not
> guarantee that anything else than the function declaring the va_list may
> form the pointer to it, and only pass it to a single other function.
> Note that if you rewrite it so that fooB itself also takes a "va_list *"
> argument, things (at least on my system) work out right on both 32 and
> 64 bits; [snip]
> (Presumably, and based on the warning messages emitted, the difference
> is due to "[1]" meaning different things in a function parameter
> declaration than elsewhere.)


Yes. And the moral is, _always_ use 'va_list *' for parameters,
because the behavior is more well-defined than for plain 'va_list',
and it won't lead to nasty little surprises like the examples here
(which do use 'va_list' for parameters) illustrate.
 
Reply With Quote
 
m.labanowicz@gmail.com
Guest
Posts: n/a
 
      01-16-2013
> These messages appear not to match the given source file
> (some of the line numbers are off). This makes me
> suspicious that what is being reported may not match what
> really occurred.


Sorry, my fault, I hate such inconsistency, following there is the corresponding compilation messages to the code from original post:
----------------------------------
test.c: In function ‘fooB’:
test.c:19:3: warning: passing argument 1 of ‘va_get_int’ from incompatible pointer type [enabled by default]
test.c:4:5: note: expected ‘struct __va_list_tag (*)[1]’ but argument is of type ‘struct __va_list_tag **’
test.c:20:3: warning: passing argument 1 of ‘va_get_chrptr’ from incompatible pointer type [enabled by default]
test.c:7:8: note: expected ‘struct __va_list_tag (*)[1]’ but argument is of type ‘struct __va_list_tag **’
----------------------------------

--
Maciej Labanowicz
 
Reply With Quote
 
Shao Miller
Guest
Posts: n/a
 
      01-16-2013
On 1/16/2013 04:05, Noob wrote:
> Robert Wessel wrote:
>
>> Mind you that there is no guarantee in C that there is *any* integer
>> type that can actually hold a pointer (although both Posix and Windows
>> require such).

>
> However, if a given implementation provides intptr_t and/or uintptr_t,
> then one can use either(?) to store the representation of an object pointer.
>
> Tangential questions:
>
> - Can uintptr_t store the representation of a function pointer?
>


I don't see a guarantee for that, no.

> - Why provide signed and unsigned types?
>


Since pointer representation is mostly opaque, this strikes me as a
flexibility for the implementation. Suppose an implementation
"actually" uses a signed integer value for pointers... Then not
providing 'uintptr_t' and providing 'intptr_t' might be most natural.
Does that make sense?

- Shao Miller


--
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.

Cheerily," -- Richard Harter
 
Reply With Quote
 
Shao Miller
Guest
Posts: n/a
 
      01-16-2013
On 1/16/2013 03:15, (E-Mail Removed) wrote:
> Hello,
>
> I'm trying to compile following example:
>


'va_list' is an array type. A function parameter cannot be declared to
have an array type, even if it looks like it does. Here are two
test-cases for you:

#include <stdio.h>

typedef char arr42_t[42];

void func1(arr42_t * arr) {
(*arr)[0] = 'C';
(*arr)[1] = '\0';
}

void func2(arr42_t arr) {
func1(&arr);
}

int main(void) {
arr42_t arr;

func2(arr);
printf("%s\n", arr);
return 0;
}

---

gcc -ansi -pedantic -Wall -Wextra -Werror -o mlaban1 mlaban1.c

---

#include <stdio.h>

typedef char arr42_t[42];

void func1(arr42_t * arr) {
(*arr)[0] = 'C';
(*arr)[1] = '\0';
}

void func2(arr42_t * arr) {
func1(arr);
}

int main(void) {
arr42_t arr;

func2(&arr);
printf("%s\n", arr);
return 0;
}

---

gcc -ansi -pedantic -Wall -Wextra -Werror -o mlaban2 mlaban2.c

---

And here is a test-case to demonstrate that the parameter is not the
same type as the original:

#include <stdio.h>

typedef char arr42_t[42];

size_t sizeof_arr_param(arr42_t param) {
return sizeof param;
}

int main(void) {
arr42_t arr;

printf(
"sizeof arr == %u && sizeof param == %u\n",
(unsigned int) sizeof arr,
(unsigned int) sizeof_arr_param(arr)
);
return 0;
}

---

gcc -ansi -pedantic -Wall -Wextra -Werror -o mlaban3 mlaban3.c

--
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.

Cheerily," -- Richard Harter
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-16-2013
Shao Miller <(E-Mail Removed)> writes:
> On 1/16/2013 04:05, Noob wrote:
>> Robert Wessel wrote:
>>> Mind you that there is no guarantee in C that there is *any* integer
>>> type that can actually hold a pointer (although both Posix and Windows
>>> require such).

>>
>> However, if a given implementation provides intptr_t and/or uintptr_t,
>> then one can use either(?) to store the representation of an object pointer.
>>
>> Tangential questions:
>>
>> - Can uintptr_t store the representation of a function pointer?

>
> I don't see a guarantee for that, no.


There is no such guarantee. You can convert a void* to intptr_t or
uintptr_t and back to void*, and get back a result that compares
equal to the original value. A void* may not be able to hold the
converted value of a function pointer without loss of information.

>> - Why provide signed and unsigned types?

>
> Since pointer representation is mostly opaque, this strikes me as a
> flexibility for the implementation. Suppose an implementation
> "actually" uses a signed integer value for pointers... Then not
> providing 'uintptr_t' and providing 'intptr_t' might be most natural.
> Does that make sense?


Yes, but that doesn't seem to be the way the standard defines it.
Both intptr_t and uintptr_t behave as described. Both types
are optional, but there's no guidance for the criteria for
an implementation to provide them or not. Typically (with
two's-complement and no padding bits) a signed type and its
corresponding unsigned type hold exactly the same amount of
information, and I've never heard of an implementation that provides
intptr_t but not uintptr_t, or vice versa.

And if either intptr_t or uintptr_t provides a more natural mapping
to pointers on a given implementation, I see no way for a program
to detect that.

On the other hand, if you're using these types, you're probably
writing low-level implementation-specific code anyway, so you should
know (by other means) which type is more useful.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Is it legal to write an logical equation for a FPGA LUT in claims of a patent? Weng Tianxiang VHDL 12 12-10-2005 03:49 PM
Research: File-sharers big legal download spenders. Silverstrand Front Page News 0 07-27-2005 03:00 PM
State machine transition on internal signals - is it legal? Divyang M VHDL 9 05-18-2005 03:58 PM
State machine transition on internal signals -- is it legal? Divyang M VHDL 1 05-15-2005 09:36 AM
Is this legal? Valentin Tihomirov VHDL 20 10-29-2003 10:31 AM



Advertisments