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]
Date:	Thu, 19 Dec 2013 11:48:15 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	josh@...htriplett.org
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, 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.

But what use is that in practice?  Nobody ever compiles .h files by
themselves.

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.

Alan Stern

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ