From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 15:59:05 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCED71065670 for ; Sat, 2 May 2009 15:59:05 +0000 (UTC) (envelope-from brampton@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id CB34A8FC15 for ; Sat, 2 May 2009 15:59:04 +0000 (UTC) (envelope-from brampton@gmail.com) Received: by bwz9 with SMTP id 9so2732171bwz.43 for ; Sat, 02 May 2009 08:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=d8JKvANX/38fYk25AKEzoiAQiYUgjMtrKfi++/6BURg=; b=MPjlREXBVYyo+tju3o3dxn2/0r19nKJs7s6OW4l/iZK3j3zINe+ALPBOOaNoGCA4EX NHiIEcgQedB6HwmS0Jn2wKvkZbQmbmRVULVntC50qcxJ4KlxRRO9fkTwM8RiAgHg6UhX PMbRyWMJJQ0Q1G8ViRbjgUzp9tUZIBXuqOwzQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=uG1TxNvMLsSlcjfDHsDSpGFNzQabNF8zQ00cQUs56YQ7E9gBSNpFLZojkb6BVNseOg 6S263WaFWbC8heaiwj2a057A8STz3TU1yXz/9UHT1Ejq2lJORusubFOhEOI8IEAJFM6Q EWv8TV1KKZ56lsyGvv/yDQYS4xQ2wfzHZYBHg= MIME-Version: 1.0 Sender: brampton@gmail.com Received: by 10.223.116.72 with SMTP id l8mr1452901faq.33.1241279943677; Sat, 02 May 2009 08:59:03 -0700 (PDT) Date: Sat, 2 May 2009 16:59:03 +0100 X-Google-Sender-Auth: db136479a5ce41dd Message-ID: From: Andrew Brampton To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Definition of NULL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 15:59:06 -0000 I'm writing a C++ Kernel Module, and one thing that has been bugging me is the kernel's definition of NULL. sys/sys/_null.h (in CURRENT): #if defined(_KERNEL) || !defined(__cplusplus) #define NULL ((void *)0) #else #if defined(__GNUG__) && defined(__GNUC__) && __GNUC__ >= 4 #define NULL __null #else #if defined(__LP64__) #define NULL (0L) #else #define NULL 0 #endif /* __LP64__ */ #endif /* __GNUG__ */ #endif /* _KERNEL || !__cplusplus */ >From what I've read online the definition of NULL in C is (void *)0, whereas in C++ it should be 0, or 0L (on 64bit machines). Now, my C++ kernel module is built with _KERNEL definited, like any other C kernel module. This leads to NULL being defined incorrectly. So I have a question and two suggestions. Firstly, why is the #if defined(_KERNEL) in _null.h? Is it to stop userland application applications picking up this definition? Or for another reason? and two, how about we change the first line of _null.h so that we use a && instead of a || like so: #if defined(_KERNEL) && !defined(__cplusplus) That should ensure the definition is correct. Or, a more radical approach, we could remove the check for _KERNEL, since I can't figure out why it is needed and do something like: #if defined(__GNUG__) && defined(__GNUC__) && __GNUC__ >= 4 # define NULL __null #elif !defined(__cplusplus) # define NULL ((void *)0) #elif defined(__LP64__) # define NULL (0L) #else # define NULL 0 #endif That way, if we are using GCC 4+ we use their __null definition, otherwise if we are not c++ we use the standard (void *)0, and then if we are 64bit we use 0L, and finally anything else uses 0. A quick amd64 kernel compile seems to allow my new definition I hope this makes sense, and I welcome all feedback. Andrew