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

John Mills johnmills at speakeasy.net
Thu May 1 09:37:07 EDT 2008


ALErs -

Thanks for all the input.

I think we have short- and long-term solutions now.

In the short term, we juggled the inclusions and removed the build 
problem, but this doesn't solve the basic problems in our source tree.

It turns out that several 'include' files use the '#ifndef/#define/#endif' 
construction to define data types as macros. These should be defined with 
'typedef' instead. Changing only one instance of the redundant definitions 
broke the build. There are suitable types defined across all our targets 
in system files that we can use: 'unit8_t' instead of '__u8' for example.

The long-term solution is updating code to those higher-level definitions, 
use properly-wrapped 'include' files, and 'typedef' instead or '#define' 
to create data types.

On Wed, 30 Apr 2008, Michael H. Warfield wrote:

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

>> ALErs -

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

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

> 	Does including <linux/types.h> solve the problem without the defines
> above?  If not, what are you missing?
  ...
> 	Should be able to include <linux/types.h> without conflict.
  ...
> 	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.

It would have been OK, except I hadn't seen multiple cases defining the 
same tokens from different files

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

I'm sure the guy who sorted it out would agree!

  - Mills


More information about the Ale mailing list