linux-kernel - Re: [PATCH 3/7] drivers: usb: Include appropriate header file in hcd.h

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: <20131219165310.GA1893@cloud>
Date:	Thu, 19 Dec 2013 08:53:10 -0800
From:	josh@...htriplett.org
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Rashika Kheria <rashika.kheria@...il.com>,
	linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-usb@...r.kernel.org
Subject: Re: [PATCH 3/7] drivers: usb: Include appropriate header file in
 hcd.h

On Thu, Dec 19, 2013 at 11:48:15AM -0500, Alan Stern wrote:
> On Thu, 19 Dec 2013 josh@...htriplett.org wrote:
> 
> > > Of course, people have varying opinions on this issue.  As far as I 
> > > know, there is no fixed policy in the kernel about nested includes.
> > 
> > True.  I personally prefer the policy of making all headers
> > self-contained, and then only including headers that define things used
> > in the source file.  That has the advantage of not including any
> > unnecessary headers if the dependencies shrink, and not requiring
> > changes to multiple source files if the dependencies grow.
> > 
> > Any particular objection to making the headers self-contained?
> 
> I guess it depends on what you mean by "self-contained".  The only 
> reasonable definition I can think of at the moment is that you don't 
> get any errors or warnings when you compile the .h file by itself.

Or, to look at it another way, you can #include the .h file in a .c file
without any other .h file, and successfully compile the .c file and use
everything defined by the .h file.

> For that matter, how can you tell that you are including only headers 
> that define things used in the source file?  Remove each #include line, 
> one at a time, and see if you then get an error?  Do you do this after 
> each change to the source file to make sure it remains true over time?
>
> My point is that the C language design and compiler infrastructure make 
> it virtually impossible to enforce any fixed policy.

And that leaves aside all the preprocessor symbols that might change
what a header defines.  I'd argue for a best-effort policy, together
with fixing headers whenever someone notices that they're *not*
self-contained (in other words, they include a .h file to get a
definition they need, and get a compile error).

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