From linux-kernel Sat Apr 14 08:54:23 2012 From: Lubos Lunak Date: Sat, 14 Apr 2012 08:54:23 +0000 To: linux-kernel Subject: Re: [PATCH][RESEND] do not redefine userspace's NULL #define Message-Id: <201204141054.23935.l.lunak () suse ! cz> X-MARC-Message: https://marc.info/?l=linux-kernel&m=133439378123064 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--Boundary-00=_/sTiPY5taHpi46e" --Boundary-00=_/sTiPY5taHpi46e Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 14 of April 2012, Linus Torvalds wrote: > On Sat, Apr 14, 2012 at 1:21 AM, Lubos Lunak wrote: > > =A0How about the patch? Are there any *actual* problems with it or can = it > > please go in? > > If we're going to change that thing, I'd actually prefer to just move > it inside the #ifdef __KERNEL__ entirely, and get rid of the cplusplus > case. > > IOW, something like this (obviously white-space-mangled) patch: =2E.. > which protects the kernel NULL definition along with the whole > offsetof and true/false ones too. And just gets rid of the insane C++ > case entirely. That's what the original version of my patch did, but Arnd pointed out tha= t=20 other exported headers might use NULL and thus not be self-contained in=20 userspace after this change, breaking backwards source compatibility. But I= 'd=20 expect such breakages to be rather unlikely (stddef.h is probably pulled in= =20 by pretty much everything), so if you're fine with it, I'm ok with this=20 solution too. =2D-=20 Lubos Lunak l.lunak@suse.cz --Boundary-00=_/sTiPY5taHpi46e Content-Type: message/rfc822; name="forwarded message" Content-Transfer-Encoding: 7bit Content-Description: Lubos Lunak : [PATCH] do not export kernel's NULL #define to userspace Content-Disposition: inline Subject: [PATCH] do not export kernel's NULL #define to userspace From: Lubos Lunak To: Linus Torvalds Cc: Andrew Morton , linux-kernel@vger.kernel.org Date: Wed, 21 Mar 2012 14:08:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201203211408.25040.l.lunak@suse.cz> X-Length: 1543 X-UID: 26267 GCC's NULL is actually __null, which allows detecting some questionable NULL usage and warn about it. Moreover each platform/compiler should have its own stddef.h anyway (which is different from linux/stddef.h). So there's no good reason to leak kernel's NULL to userspace and override what the compiler provides. Signed-off-by: Lubo=C5=A1 Lu=C5=88=C3=A1k =2D-- include/linux/stddef.h | 8 ++------ 1 files changed, 2 insertions(+), 6 deletions(-) diff --git a/include/linux/stddef.h b/include/linux/stddef.h index 6a40c76..1747b67 100644 =2D-- a/include/linux/stddef.h +++ b/include/linux/stddef.h @@ -3,14 +3,10 @@ =20 #include =20 +#ifdef __KERNEL__ + #undef NULL =2D#if defined(__cplusplus) =2D#define NULL 0 =2D#else #define NULL ((void *)0) =2D#endif =2D =2D#ifdef __KERNEL__ =20 enum { false =3D 0, =2D-=20 1.7.3.4 =2D-=20 Lubos Lunak l.lunak@suse.cz --Boundary-00=_/sTiPY5taHpi46e-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/