The usage of %p in C

[Charlie Gordon]

It could be argued (and has been, in fact) that this
causes undefined behaviour. The standard specifies that
%x requires an unsigned int argument.

I can't see anything other than a DS9000 failing it, though.

How could that be a problem, even on a DS9K ?

 

[Keith Thompson]

<nitpick>
If there's an I/O error it will return a negative value, which is
the proper behavior in that case.
</nitpick>

Touche.

 

[Keith Thompson]

How could that be a problem, even on a DS9K ?

The standard requires signed int and unsigned int to have the same
size and alignment, and for values representable in both to have the
same representation. But I don't think the standard requires the same
parameter passing method for both.

 

[Martin Wells]

jacob:

I think the cast is unnecessary, unless int * and void *
are of different sizes in your system...

Here's a case of where you can add NO overhead to your program and at
the same time maintain its portability... YET you still strive to
deportify your programs as best you can. You should start writing
4294967295 instead of UINT_MAX, that'll further your cause even
further.

It's strange to see how someone could be so hellbent on causing
inconvenience for themselves.

Martin

 

[Old Wolf]

How could that be a problem, even on a DS9K ?

Because the standard explicitly says that the argument
corresponding to %x must be of type 'unsigned int'. The
DS9K compiler could note that you pass a signed int,
and replace the code with a call to nasal_demon().

 

[Jack Klein]

You meant "...a cast is necessary..."?

Yes, indeedy! But I didn't charge for the extra word...

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Richard Bos]

I was. A question if you will.

I'm a bit hazy at the moment but I remember someone harping on about
pointers of one type being of a special type and residing in "special
memory".

That is, effectively, not possible. (To be precise, if it is possible,
it must be invisible to any conforming program, for the reason you
mention above amongst others.) However, it has nothing whatsoever to do
with pointers passed to variadic functions, so I fail to see why you
appended that question to this thread.

Richard

 

[Charlie Gordon]

The standard requires signed int and unsigned int to have the same
size and alignment, and for values representable in both to have the
same representation. But I don't think the standard requires the same
parameter passing method for both.

Even for varadic functions ?

 

[=?iso-2022-kr?q?Harald_van_D=0E=29=26=0Fk?=]

Even for varadic functions ?

The standard requires this program to work:

#include <stdio.h>
#include <stdarg.h>

void f(int a, ...) {
va_list ap;
va_start(ap, a);
printf("%d %d\n", a, va_arg(ap, int));
va_end(ap);
}

int main(void) {
unsigned x = 1;
f(x, x);
return 0;
}

The implementation must ensure an int value 1 is read even though an
unsigned int value 1 is passed. However, so long as va_arg can find the
right value in either case, the standard allows an int and an unsigned
int to be passed differently (possibly by passing argument type
information along with argument values). And there's nothing requiring
the same va_arg handling from the *printf functions.

 

[Keith Thompson]

Even for varadic functions ?

Whoops you're right. C99 7.15.1.1p2 requires corresponding signed and
unsigned to work properly for values that are representable in both
(it also requires void* and pointers to character types to be
compatible).

As Harald points out, printf isn't required to use va_arg. But the
DS9K is probably the only implementation where the above would fail
(and it took a fair amount of work to cause that case to fail without
breaking conformance).