linux-kernel - Re: including .c files ?

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:	Fri, 08 Aug 2008 17:36:59 +0200
From:	Rene Herman <rene.herman@...access.nl>
To:	Frans Meulenbroeks <fransmeulenbroeks@...il.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: including .c files ?

On 08-08-08 13:25, Frans Meulenbroeks wrote:

> I was wondering how people feel about including .c files in other .c
> files.
> 
> I saw a few occasions of this. Triggered by that observation I
> decided to do a grep for this (on 2.6.25.7 as that was the one I had
> handy at that moment). Some 268 .c files are included. Seems an awful
> lot for me.
> 
> Do people feel this is good practice? I understand that sometimes it
> is useful (and then you might need to decide on whether to include a
> .c file or to have a .h file with code), but in other places it is
> probably less relevant.
> 
> Generally I would expect that if the .c file contains some standalone
>  functionality then it should probably be a .c file on its own with a
>  well defined interface.
> 
> Curious what others think about this. As attachement I've added the
> output of the grep (slightly edited to remove some false positives,
> like those from the Documentation and scripts directories and those
> who are obviously comments).

As you posted, many of these are in sound/ and many of those #define a 
model and then including the "real source file". Can't say I've been 
very keen on that either and in those cases using a -D commandline 
#define might be better especially since I believe that's actually very 
easy these days.

I also keep a local driver here though that #defines some 50 items and 
then includes the source so that the driver for another version of the 
card can just redefine those and keep the code itself the same (as a 
coincidence, I was just porting that one forward in fact).

This general problem more or less is "library code". Say I have some 
code that I want to use in two different drivers -- I can't just link it 
into both due to symbol clashes if I'd try to then _load_ both drivers. 
So I then have to structure the library code as a completely seperate 
module that both drivers depend on and for small stuff that's sometimes 
just really silly. You still definitely don't want two copies of the 
code to avoid all the usual problems of stuff getting out of sync so a 
solution is to just #include the library code in both after which its 
identifiers can be static.

If you think about it -- in C, #include really at least conceptually 
means "cut & paste this in here, please" meaning headers are not 
anything special and .h and .c seperation is a mere convention.

As we all know, conventions exist _only_ to be violated...

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