[ale] Battling Distros and unwrapped '#include's

[Michael H. Warfield]

On Wed, 2008-04-30 at 13:23 -0400, John Mills wrote:
> ALErs -

> Different engineers in our development group use different Linux distros 
> and we seem to have a cross-file of system *.h files defining basic types.

> In particular, one of our own product's files attempts to conditionally 
> define basic integer types as follows:

> ************<common.h>********************
> /* Types */
> 
> #ifndef __u8
> #define __u8 unsigned char
> #endif
> #ifndef __u16
> #define __u16 unsigned short
> #endif
> #ifndef __u32
> #define __u32 unsigned long
> #endif
> #ifndef __s8
> #define __s8 signed char
> #endif
> #ifndef __s16
> #define __s16 signed short
> #endif
> #ifndef __s32
> #define __s32 signed long
> #endif

	This should not be necessary.  If you chose the correct headers in the
first place, those definitions should be in place and they will be
defined correctly as typedefs and not define macros.

> *****************************************

> Three distros react in different ways to this fragment:

> 1. openSuSE-10.x can't build if these definitions are _not_ included, but 
> crashes on duplicated definitions from <asm/types.h> if I instead include 
> <linux/types.h>. Specifically with a flurry of:

>   "/usr/include/asm/types.h:13: error: duplicate -1signed"

	Does including <linux/types.h> solve the problem without the defines
above?  If not, what are you missing?

> 2. FC8 can't build if these definitions _are_ included, on account of 
> duplicate declarations.

	Should be able to include <linux/types.h> without conflict.

> 3. Ubuntu-8.04 doesn't care - it apparently wraps these types properly.

> First, the "#ifndef/#endif" contructions clearly don't work properly with 
> 'typedef' defined types, and
> Second, there seem to be problems with the system '#include's wrappers, at 
> least in openSuSE.

> Any suggestions how to code around this in a fairly portable fashion? We 
> have conditional compilation for other targets, but for our purposes it 
> would be good to have a single target for our Linux/x86 builds.

	Well, if you have to resort to those definitions above, I would say
you've got a problem.  Scrap those defines and go find where they are
suppose to be included from.  Sounds like Ubuntu should be a wash and F8
should work without them as well.  So, what's the problem with Suse?
Sounds like including <linux/types.h> should resolve the Suse problem
from the statement under #1.

	In general, it can be a bit tricky tracking down the correct header to
include.  You find a define in a header file and it's often tempting to
include THAT header when what you really want is an include file that
ultimately calls the one your after.  You've got a lot of defines
beginning with "__".  Those are generally deeper system defines.  If you
really need them, you probably should include them properly for it to be
portable.

> TIA for any clever ideas.

	Defining those types in that manner is barking up the wrong tree so
fixing them is not fixing the problem.  Remove them and fix the problem
that prompted you to insert them.  I'd like to hear more about the
problem that prompted this workaround in the first place.

>   - Mills

	Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20080430/7bb65dd6/attachment.bin