linux-kernel - Re: [PATCH 1/2] HID: hid-lg4ff: Use Private Data

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F79E242.5090300@suse.cz>
Date:	Mon, 02 Apr 2012 19:30:42 +0200
From:	Jiri Slaby <jslaby@...e.cz>
To:	simon@...gewell.org
CC:	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	Jiri Kosina <jkosina@...e.cz>,
	Michael Bauer <michael@...auer.org>,
	Michal Maly <madcatxster@...il.com>
Subject: Re: [PATCH 1/2] HID: hid-lg4ff: Use Private Data

On 04/02/2012 07:01 PM, simon@...gewell.org wrote:
> 
>>> +	struct lg4ff_device_entry *uninitialized_var(entry);
>>> +	struct lg_drv_data *uninitialized_var(drv_data);
>>
>> You don't need uninitialized_var bloat anymroe, right?
> 
> I guess I don't fully understand the 'unitialized_var()' macro, and was
> just following the previous uses in the code.
> 
> Google'ing doesn't really help either. Is there a definitive guide as when
> to use and not?

The simple answer is: never.

It serves the purpose to shut up the compiler when it complains that the
variable might be uninitialized, but the programmer is sure it cannot.
In your case, the compiler should not even complain about that.

Advantage of the macro is that it adds no assembly, but still silents
the compiler.

thanks,
-- 
js
suse labs


--
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/