Re: [OMPI devel] u_int8_t

2011-01-11 Thread Eugene Loh
Jeff Squyres wrote: On Jan 11, 2011, at 2:05 PM, Eugene Loh wrote: Do we have configure tests for them, or just #define's? Configure tests. Ok, cool. I assume you'll remove the senseless configure tests, too. Right.

Re: [OMPI devel] u_int8_t

2011-01-11 Thread Jeff Squyres
On Jan 11, 2011, at 2:05 PM, Eugene Loh wrote: >> Do we have configure tests for them, or just #define's? >> > Configure tests. Ok, cool. I assume you'll remove the senseless configure tests, too. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to:

Re: [OMPI devel] u_int8_t

2011-01-11 Thread Eugene Loh
Jeff Squyres wrote: Shrug. If they're not used anywhere, I'd whack them. Excellent. They screw things up (at least for me). Turns out, Solaris IB uses such types and has the sense to typedef them. But such typedefs conflict with opal_config.h, which #define's them (for apparently no

Re: [OMPI devel] u_int8_t

2011-01-10 Thread Jeff Squyres
Shrug. If they're not used anywhere, I'd whack them. Do we have configure tests for them, or just #define's? On Jan 10, 2011, at 7:51 PM, Eugene Loh wrote: > Why do > u_int8_t > u_int16_t > u_int32_t > u_int64_t > get defined in opal_config.h? I don't see them used anywhere in the >

[OMPI devel] u_int8_t

2011-01-10 Thread Eugene Loh
Why do u_int8_t u_int16_t u_int32_t u_int64_t get defined in opal_config.h? I don't see them used anywhere in the OMPI/OPAL/ORTE code base. Okay, one exception, in opal/util/if.c: #if defined(__DragonFly__) #define IN_LINKLOCAL(i)(((u_int32_t)(i) & 0x) == 0xa9fe)