On Tue, Aug 7, 2012 at 10:32 PM, Caspar Zhang <[email protected]> wrote:
> On 08/03/2012 12:22 AM, Simon Xu wrote:
>> Capability testcases fail to compile with sys/capability.h of libcap-devel in
>> RHEL5-like distros:
>>
>> In file included from /usr/include/sys/capability.h:34, from 
>> cap_bounds_r.c:30:
>> /usr/include/linux/capability.h:70:
>>           error: expected specifier-qualifier-list before '__le32'
>>
>> This is due to sys/capability.h preventing the correct _LINUX_TYPES_H_ from
>> being included.  The problem can be bypassed by including linux/types.h in
>> capability testcases.
>>
>> Signed-off-by: Simon Xu <[email protected]>
>
> from doc/style-guide.txt:
>
> "
> 14. System headers
> ~~~~~~~~~~~~~~~~~~
>
> Don't use +linux/+ headers if at all possible. Usually they are replaced
> with
> +sys/+ headers as things work their way into glibc.  Furthermore, +linux/+
> headers get shuffled around a lot more than their +sys/+ counterparts it
> seems.
> "
>
> Do we have a better solution?

It's a guideline, not a hard rule. The intent was to avoid nasty
snaking #ifdefs [and special case autoconf tests], or avoid including
system headers (e.g. linux/inotify.h vs sys/inotify.h); this kind of
exists in LTP and exists in other projects like hdparm, iozone,
net-snmp, etc as there isn't a tight coupling between kernel and
userland in Linux.

I doublechecked and there really isn't a good way to check for this in
Fedora (at least), so it's ok, but the upstream author should be
encouraged to not do things like that in headers. It really wreaks
havoc with projects trying to achieve consistency.

Thanks,
-Garrett

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Reply via email to