Closed thrimbor closed 4 years ago
This was one of the first definitions I made... and I had hoped to get away without #ifdef __cplusplus (because C++ defines NULL as literal 0, and C doesn't care much whether it is a pointer type or not in virtually all places)...
But by now we have lots of __cplusplus checks anyway, so why not here. This will be quickly done, but might take a couple of days extra before I push to git, as I want to have the changes necessitated by freopen() all cleaned up and properly commented first.
Afaik C++11 and higher even allow NULL
to be defined as nullptr
, while clang seems to use __null
when building C++ code (seems to be a GCC/LLVM thing only). Not sure whether it may be a good idea to go for one of these, though.
Added a three-way selection for C ((void*)0), C++98 (0), and C++11 and later (nullptr).
Only in SVN until I get the rest cleaned up as well.
Does this float your boat?
That should be fine, thanks!
We came across this a while ago in https://github.com/XboxDev/nxdk/issues/253. Code can use a special attribute on gcc and clang that signals the compiler that it should check whether calls to the function use a sentinel value to properly end the parameter list. This warning gets emitted when using PDCLib even when properly using
NULL
as a sentinel value, becauseNULL
is defined as a zero literal: https://github.com/DevSolar/pdclib/blob/108299a1157e6872d60936d6e1481d2dbaad2737/include/pdclib/_PDCLIB_int.h#L19clang has a test for this warning which indicates that it expects a pointer type: https://github.com/llvm-mirror/clang/blob/master/test/Sema/block-sentinel-attribute.c
The C11 standard says in 7.19:
So I think replacing the above line with something
#define _PDCLIB_NULL ((void *)0)
should resolve that without any drawbacks regarding portability or standard compliance.