[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


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