Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is %p specifier only for valid pointers?

Tags:

Suppose on my platform sizeof(int)==sizeof(void*) and I have this code:

printf( "%p", rand() );

Will this be undefined behavior because of passing a value that is not a valid pointer in place of %p?

like image 870
sharptooth Avatar asked Jul 27 '12 12:07

sharptooth


People also ask

What is %P used for?

In C we have seen different format specifiers. Here we will see another format specifier called %p. This is used to print the pointer type data.

What does %P in C mean?

%p is for printing a pointer address. 85 in decimal is 55 in hexadecimal. On your system pointers are 64bit, so the full hexidecimal representation is: 0000000000000055.

How does %P work in printf?

By using '%p' you print the address of the variable in question, "The void * pointer argument is printed in hexadecimal (as if by %#x or %#lx)."

What is the difference between %D and %P in C?

As you already explained %d is used for signed integers, while %u is for unsigned integers. %p is used to print pointer addresses. Originally Answered: What are the actual differences between %d, %u and %p format specifiers used in C to print the memory address of a variable?


2 Answers

To expand upon @larsman's answer (which says that since you violated a constraint, the behavior is undefined), here's an actual C implementation where sizeof(int) == sizeof(void*), yet the code is not equivalent to printf( "%p", (void*)rand() );

The Motorola 68000 processor has 16 registers which are used for general computation, but they are not equivalent. Eight of them (named a0 through a7) are used for accessing memory (address registers) and the other eight (d0 through d7) are used for arithmetic (data registers). A valid calling convention for this architecture would be

  1. Pass the first two integer parameters in d0 and d1; pass the rest on the stack.
  2. Pass the first two pointer parameters in a0 and a1; pass the rest on the stack.
  3. Pass all other types on the stack, regardless of size.
  4. Parameters passed on the stack are pushed right-to-left regardless of type.
  5. Stack-based parameters are aligned on 4-byte boundaries.

This is a perfectly legal calling convention, similar to calling conventions used by many modern processors.

For example, to call the function void foo(int i, void *p), you would pass i in d0 and p in a0.

Note that to call the function void bar(void *p, int i), you would also pass i in d0 and p in a0.

Under these rules, printf("%p", rand()) would pass the format string in a0 and the random number parameter in d0. On the other hand, printf("%p", (void*)rand()) would pass the format string in a0 and the random pointer parameter in a1.

The va_list structure would look like this:

struct va_list {
    int d0;
    int d1;
    int a0;
    int a1;
    char *stackParameters;
    int intsUsed;
    int pointersUsed;
};

The first four members are initialized with the corresponding entry values of the registers. The stackParameters points to the first stack-based parameters passed via the ..., and the intsUsed and pointersUsed are initialized to the number of named parameters which are integers and pointers, respectively.

The va_arg macro is a compiler intrinsic which generates different code based on the expected parameter type.

  • If the parameter type is a pointer, then va_arg(ap, T) expands to (T*)get_pointer_arg(&ap).
  • If the parameter type is an integer, then va_arg(ap, T) expands to (T)get_integer_arg(&ap).
  • If the parameter type is something else, then va_arg(ap, T) expands to *(T*)get_other_arg(&ap, sizeof(T)).

The get_pointer_arg function goes like this:

void *get_pointer_arg(va_list *ap)
{
    void *p;
    switch (ap->pointersUsed++) {
    case 0: p = ap->a0; break;
    case 1: p = ap->a1; break;
    case 2: p = *(void**)get_other_arg(ap, sizeof(p)); break;
    }
    return p;
}

The get_integer_arg function goes like this:

int get_integer_arg(va_list *ap)
{
    int i;
    switch (ap->intsUsed++) {
    case 0: i = ap->d0; break;
    case 1: i = ap->d1; break;
    case 2: i = *(int*)get_other_arg(ap, sizeof(i)); break;
    }
    return i;
}

And the get_other_arg function goes like this:

void *get_other_arg(va_list *ap, size_t size)
{
    void *p = ap->stackParameters;
    ap->stackParameters += ((size + 3) & ~3);
    return p;
}

As noted earlier, calling printf("%p", rand()) would pass the format string in a0 and the random integer in d0. But when the printf function executes, it will see the %p format and perform a va_arg(ap, void*), which will use get_pointer_arg and read the parameter from a1 instead of d0. Since a1 was not initialized, it contains garbage. The random number you generated is ignored.

Taking the example further, if you had printf("%p %i %s", rand(), 0, "hello"); this would be called as follows:

  • a0 = address of format string (first pointer parameter)
  • a1 = address of string "hello" (second pointer parameter)
  • d0 = random number (first integer parameter)
  • d1 = 0 (second integer parameter)

When the printf function executes, it reads the format string from a0 as expected. When it sees the %p it will retrieve the pointer from a1 and print it, so you get the address of the string "hello". Then it will see the %i and retrieve the parameter from d0, so it prints a random number. Finally, it sees the %s and retrieves the parameter from the stack. But you didn't pass any parameters on the stack! This will read undefined stack garbage, which will most likely crash your program when it tries to print it as if it were a string pointer.

like image 88
Raymond Chen Avatar answered Sep 22 '22 13:09

Raymond Chen


C standard, 7.21.6.1, The fprintf function, states just

p The argument shall be a pointer to void.

By Appendix J.2, this is a constraint, and violating a constraint causes UB.

(Below is my previous reasoning why this should be UB, which was too complicated.)

That paragraph does not describe how the void* is retrieved from the ..., but the only way that the C standard itself offers for this purpose is 7.16.1.1, The va_arg macro, which warns us that

if type is not compatible with the type of the actual next argument (as promoted according to the default argument promotions), the behavior is undefined

If you read 6.2.7, Compatible type and composite type, then there's no hint that void* and int should be compatible, regardless of their size. So, I'd say that since va_arg is the only way to implement printf in standard C, the behavior is undefined.

like image 40
Fred Foo Avatar answered Sep 22 '22 13:09

Fred Foo