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]

Date:	Thu, 19 Dec 2013 21:03:27 +0300
From:	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
To:	Alan Stern <stern@...land.harvard.edu>, 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

Hello.

On 12/19/2013 07:48 PM, Alan Stern 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.

    It's enough to verify that a .c file containing the given .h file would 
not cause errors *located in that .h file*. This is not really such an 
improbable situation, e.g. at the early stages of development. I did discover 
header fiel errors this way.

> For that matter, how can you tell that you are including only headers
> that define things used in the source file?

    I still think that's a whole different issue.

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

    That's what #include cleanup patches are for. Somebody has to do them from 
time to time when the #include's accumulate -- they tend to accumulate as 
people often forget to remove no longer needed one while removing some feature 
from the .c file.

> My point is that the C language design and compiler infrastructure make
> it virtually impossible to enforce any fixed policy.

    I don't really see how C language design can justify header files that 
once included, require each .c file to #include other headers ahead of them, 
each time such header is used. In my opinion, it's just crazy.

> Alan Stern

WBR, Sergei

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