| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 12 Mar 2007 06:40:18 +0100 (MET)
From: Jan Engelhardt <jengelh@...ux01.gwdg.de>
To: Cong WANG <xiyou.wangcong@...il.com>
cc: linux-kernel@...r.kernel.org
Subject: Re: Style Question
On Mar 12 2007 13:37, Cong WANG wrote:
>
> The following code is picked from drivers/kvm/kvm_main.c:
>
> static struct kvm_vcpu *vcpu_load(struct kvm *kvm, int vcpu_slot)
> {
> struct kvm_vcpu *vcpu = &kvm->vcpus[vcpu_slot];
>
> mutex_lock(&vcpu->mutex);
> if (unlikely(!vcpu->vmcs)) {
> mutex_unlock(&vcpu->mutex);
> return 0;
> }
> return kvm_arch_ops->vcpu_load(vcpu);
> }
>
> Obviously, it used 0 rather than NULL when returning a pointer to
> indicate an error. Should we fix such issue?
Indeed. If it was for me, something like that should throw a compile error.
>>[...]
> I think it's more clear to indicate we are using a pointer rather than
> an integer when we use NULL in kernel. But in userspace, using NULL is
> for portbility of the program, although most (*just* most, NOT all) of
> NULL's defination is ((void*)0). ;-)
NULL has the same bit pattern as the number zero. (I'm not saying the bit
pattern is all zeroes. And I am not even sure if NULL ought to have the same
pattern as zero.) So C++ could use (void *)0, if it would let itself :p
>
>
Jan
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists