NULL definition problem on 64 bit system

Question

I'm running on RHEL 5.1 64 bit platfrom using gcc 4.1.2.

I have a utility function:

void str_concat(char *buff, int buffSize, ...);

which concats char * passed in variadic list(...), while last argument should be NULL, to designate end of the arguments. On 64 bit system NULL is 8 bytes.

Now to the problem. My application includes directly/indirectly 2 stddef.h files.

First one is /usr/include/linux/stddef.h which defines NULL as following:

#undef NULL
#if defined(__cplusplus)
#define NULL 0
#else
#define NULL ((void *)0)
#endif

The second one is /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include/stddef.h

#if defined (_STDDEF_H) || defined (__need_NULL)
#undef NULL     /* in case <stdio.h> has defined it. */
#ifdef __GNUG__
#define NULL __null
#else   /* G++ */
#ifndef __cplusplus
#define NULL ((void *)0)
#else   /* C++ */
#define NULL 0
#endif  /* C++ */
#endif  /* G++ */
#endif  /* NULL not defined and <stddef.h> or need NULL.  */
#undef  __need_NULL

Of course I need the 2nd one, since it defines NULL as __null (8 bytes), while 1st one defines it as integer 0 (4 bytes).

How do I prevent /usr/include/linux/stddef.h to be inderectly included?

UPD:

1. Compilation line is pretty straightforward:

   g++ -Wall -fmessage-length=0 -g -pthread

2. Many of you advised to pass (void *)0. This of course will work. The problem that the function is used in many, I mean many places. I'd like to find solution that will give me what C++ standard promises - NULL of 8 byte size.

Answer 1

I previously replied with the below answer. But then I saw that I misinterpreted several information and gave an incorrect answer. Just out of curiosity, I did the same test with VS2008 and I got different results. This is just brain exercise...

Why do you need the second one ? Both headers say the same thing.
And it does not even matter if you write 0 or NULL or ((void *)0)
All of them will take 8 bytes.

I did a quick test on a 64-bit platform with GCC 4.1.3

#include <string.h>

void str_concat(char *po_buf, int pi_max, ...)
{
    strcpy(po_buf, "Malkocoglu"); /* bogus */
}

int main()
{
    char buf[100];
    str_concat(buf, 100, "abc", 1234LL, "def", 5678LL, "ghi", 2345LL, "jkl", 6789LL, "mno", 3456LL, 0, "pqx", 0);
    return 1;
}

And this is the assembly generated by the compiler...

main:
.LFB3:
    pushq %rbp
.LCFI3:
    movq %rsp, %rbp
.LCFI4:
    subq $192, %rsp
.LCFI5:
    leaq -112(%rbp), %rdi
    movl $0, 64(%rsp)                          0
    movq $.LC2, 56(%rsp)                       "pqx"
    movl $0, 48(%rsp)                          0
    movq $3456, 40(%rsp)                       3456LL
    movq $.LC3, 32(%rsp)                       "mno"
    movq $6789, 24(%rsp)                       6789LL
    movq $.LC4, 16(%rsp)                       "jkl"
    movq $2345, 8(%rsp)                        2345LL
    movq $.LC5, (%rsp)                         "ghi"
    movl $5678, %r9d                           5678LL
    movl $.LC0, %r8d                           "def"
    movl $1234, %ecx                           1234LL
    movl $.LC1, %edx                           "abc"
    movl $100, %esi                            100
    movl $0, %eax
    call str_concat
    movl $1, %eax
    leave
    ret

Notice all the stack displacements are 8 byte...

Compiler treats 0 as it was a 32-bit data-type.
Although it does the correct displacement on the
stack pointer, the value pushed should not be 32-bit !

I did the same test with VS2008 , the assembly output is as follows :

mov QWORD PTR [rsp+112], 0
lea rax, OFFSET FLAT:$SG3597
mov QWORD PTR [rsp+104], rax
mov QWORD PTR [rsp+96], 0
mov QWORD PTR [rsp+88], 3456  ; 00000d80H
lea rax, OFFSET FLAT:$SG3598
mov QWORD PTR [rsp+80], rax
mov QWORD PTR [rsp+72], 6789  ; 00001a85H
lea rax, OFFSET FLAT:$SG3599
mov QWORD PTR [rsp+64], rax
mov QWORD PTR [rsp+56], 2345  ; 00000929H
lea rax, OFFSET FLAT:$SG3600
mov QWORD PTR [rsp+48], rax
mov QWORD PTR [rsp+40], 5678  ; 0000162eH
lea rax, OFFSET FLAT:$SG3601
mov QWORD PTR [rsp+32], rax
mov r9d, 1234    ; 000004d2H
lea r8, OFFSET FLAT:$SG3602
mov edx, 100    ; 00000064H
lea rcx, QWORD PTR buf$[rsp]
call ?str_concat@@YAXPEADHZZ   ; str_concat

This time compiler generates different code and it treats 0 as an 64-bit data-type (notice the QWORD keyword). Both the value and stack displacement is correct. VS and GCC behaves differently.

Answer 2

Removing the __GNUG__case, and inverting the ifdef/endif in the second file, BOTH files do:

#undef NULL
#if defined(__cplusplus)
#define NULL 0
#else
#define NULL ((void *)0)
#endif

Which is to say that they define NULL as ((void *)0) for C compilations and 0 for C++.

So the simple answer is "Don't compile as C++".

Your real problem is your desire to use NULL in your variadic arugment list, combined with your compiler's unpredictable argument sizing. What you MIGHT try is writing "(void *)0" instead of NULL to terminate your list, and force the compiler pass an 8-byte pointer instead of a 4-byte int.

Answer 3

You may not be able to fix the includes because system includes are a twisty maze.

You might fix the problem by using (void*)0 or (char*)0 instead of NULL.

After considering it I am rejecting my previous idea of redefining NULL. That would be a bad thing to do and could mess up a lot of other code.

Answer 4

One solution - possibly even the best, but certainly very reliable - is to pass an explicit null char pointer to your function calls:

str_concat(buffer, sizeof(buffer), "str1", "str2", ..., (char *)0);

or:

str_concat(buffer, sizeof(buffer), "str1", "str2", ..., (char *)NULL);

This is standard recommended practice for the execl() function in POSIX systems, for example, and for precisely the same reason - the trailing arguments of a variable-length argument list are subject to usual promotions (char or short to int; float to double), but cannot otherwise be type safe.

It is also why C++ practitioners generally avoid variable-length argument lists; they are not type safe.

Answer 5

There's no "NULL definiton problem" in this case. There's a problem with how you are trying to use NULL in your code.

NULL cannot be portably passed to variadic functions in C/C++ by itself. You have to explicitly cast it before passing, i.e. in your case you have to pass (const char*) NULL as the terminator of the argument list.

Your question is tagged as C++. In any case, regardless of size, in C++ NULL will always be defined as an integer constant. It is illegal in C++ to define NULL as a pointer. Since your function expects a pointer (const char *), no definition of NULL will ever work for it in C++ code.

For cleaner code you can define your own constant, like

const char* const STR_TERM = NULL;

and use it in the calls to your function. But you will never be able to meaningfully use just NULL for that purpose. Whenever a plain NULL is passed as a variadic argument, it is a blatant portability bug that has to be fixed.

Added: your update claims that "C++ standard promises NULL of 8 byte size" (on a 64-bit platform I presume). This just doesn't make any sense. C++ standard does not promise anything like that about NULL.

NULL is intended to be used as an rvalue. It has no specific size and there's no valid use of NULL where its actual size might even remotely matter.

---

Quoting from ISO/IEC 14882:1998, section 18.1 'Types', paragraph 4:

The macro NULL is an implementation defined C++ null pointer constant in this International Standard (4.10).¹⁸⁰⁾

¹⁸⁰⁾ Possible definitions include 0 and 0L, but not (void*)0.