[Libvir] [PATCH] header file changes for Solaris
Richard W.M. Jones
rjones at redhat.com
Fri Jun 15 13:16:06 UTC 2007
Daniel P. Berrange wrote:
> On Fri, Jun 15, 2007 at 09:06:55AM +0100, Richard W.M. Jones wrote:
>> Daniel P. Berrange wrote:
>>> On Thu, Jun 14, 2007 at 05:26:39PM -0400, Mark Johnson wrote:
>>>> This patch has the includes need to build on Solaris.
>>>> I've been using ifdef linux & ifndef linux to distinguish
>>>> between solaris and linux at this point.
>>> Looks ok aside from
>> [..]
>>
>> No, I don't agree. We should use configure.in to test for the presence
>> of header files and then do things like:
>>
>> #ifdef HAVE_STRINGS_H
>> #include <strings.h>
>> #endif
>
> For strings.h I don't see the point in making it conditional really, unless
> we're going to do the same for every single other header we include. The
> strings.h header is always present on Linux. In recent times stuff that was
> previously in strings.h has moved to string.h, but they're still in the
> original header too. So we should always include both string.h & strings.h
> for maximum portability.
<string.h> is in ISO C, but <strings.h> is not. So as Daniel Veillard
said you can include the former without checks, but the latter should be
defended with an #ifdef HAVE_STRINGS_H.
On BSD, <strings.h> has the legacy functions like bcopy and index. Are
we using those? Shouldn't we instead replace any instances with memcpy
/ memmove / strchr / strrchr?
There are apparently some platforms where you can't include both ...
urrgh: http://gcc.gnu.org/ml/gcc-patches/1998-08/msg00317.html
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070615/ed8a21d9/attachment-0001.bin>
More information about the libvir-list
mailing list