[ofa-general] [PATCH] Allow paths to the device specific library to be absolute

[Jason Gunthorpe]

On Wed, Jul 22, 2009 at 03:05:48PM -0700, Roland Dreier wrote:

>  > I'd like to see a result for ia64 and ppc64.. Roland do you have a
>  > Debian machine logon? Could you check this on merulo.debian.org (or
>  > merkel)?  Unfortunately I don't think pescetti is a ppc64 :|
> 
> I don't have a debian logon, but I do have an ia64 machine:

Ah, in the good old days every DD had one of those :)

> Of course this is just with the specific g++ version I tried (4.3.3 on
> ia64, 4.1.1 on ppc64).  Could change with g++ version too I assume.

It is ABI defined how this works. Unfortunately the modern ABI is not
written down anywhere, AFAIK :(

The old i386 SYSV ABI which Linux i386 started with says 'enum' is a 4
byte signed word. (figure 3-1)

>  > What I've been mulling over is exactly what ENUM_TYPE should be to
>  > have guarenteed ABI compatibility on ppc 32/64, i386 and x86-64.
> 
> Yuck... the C standard says
> 
>     The identifiers in an enumerator list are declared as constants that
>     have type int and may appear wherever such are permitted.
> 
> so using int in the function declaration would be fine, except:
> 
>     Each enumerated type shall be compatible with an integer type. The
>     choice of type is implementation-defined

C99 is a little more descript but not more helpful:

 The identifiers in an enumerator list are declared as constants that
 have type int and may appear wherever such are permitted.

 Each enumerated type shall be compatible with an integer type. The
 choice of type is implementation-defined, but shall be capable of
 representing the values of all the members of the enumeration.

Basically, it means, the compiler gets to pick. In real life,
depending on the constants assigned to the enum members you get
different types:
t.cc:3: error: invalid conversion from 'int' to 'bar1'
t.cc:3: error: invalid conversion from 'unsigned int' to 'bar1'
t.cc:3: error: invalid conversion from 'long long int' to 'bar1'
t.cc:3: error: invalid conversion from 'long long unsigned int' to 'bar1'

> so we might be changing the function signature on some obscure platform
> without knowing it.  I'm not sure if just ppc32/64, x86, ia64 is really
> good enough -- but on the other hand unbreaking C++ would be nice too.

Yes, thats right. To be honest, obscure platforms deal with this sort
of stuff often enough to be used to it. The user base of the next 3
major platforms [arm, mips, sparc] is very embedded focused and can
deal with an ABI breakage pretty easily.

That said, at this point finding a platform that didn't use int for
these types would be very surprising.

[[BTW, as I was looking this up, I found this in C99 under common
warnings:

   A value is given to an object of an enumeration type other than by
   assignment of an enumeration constant that is a member of that
   type, or an enumeration variable that has the same type, or the
   value of a function that returns the same enumeration type (6.7.2.2).

donno why gcc doesn't have a warning..]]

Jason