118418 - PRInt8 is undefined in idl?

Status: VERIFIED WONTFIX

(Core :: XPCOM, defect)

Description

[Blake Ross]

Umm...just wondering why it is I need to explicitly include prtypes.h to use 
PRInt8 in idl, but PRIntX where X > 8 works without issue.  xpidl reports a 
parse error when using PRInt8, saying it's an undefined identifier.

Comment 1

[Brendan Eich [:brendan]]

This is xpcom, giving dougt a crack at it and cc'ing jband.

It's easy enough for anyone to fix (hint, blake): patch nsrootidl.idl.

/be

Comment 2

[John Bandhauer]

There is nothing unambiguous to map PRInt8 to in nsrootidl. Our Corba libIDL
based frontend does not have a signed 8bit type. And we did not hack one in. The
typelib format supports it. But the current idl compiler does not. Corba's octet
maps to PRUint8. char maps to char. Nothing maps to PRInt8. I think fixing this
would require a new 'magic' type that libIDL would see as a native and that the
xpidl backends would emit as PRInt8. We can't do such a trick in nsrootidl. This
is an xpidl bug.

Comment 3

[Brendan Eich [:brendan]]

D'oh!  Are you sure OMG IDL (sorry, I'm ignorant -- school me please) does not
define char as signed 8 bit int?  That would be lame, given octet; it would be
lame also to leave OMG IDL users at the mercy of platform char signed-ness.

/be

Comment 4

[Mike Shaver (:shaver emeritus)]

http://www.infosys.tuwien.ac.at/Research/Corba/OMG/idlsyn.htm#532

Neither char nor octet seem to specify signedness in the 2.6 spec, and none of
my ORB-implementing buddies think there's a way to specify a signed 8-bit atom
in IDL.

(I'm not convinced we really need PRInt8, personally.  What interfaces are we
writing to that actually benefit from passing an 8-bit quantity over the "wire",
and yet aren't passing characters?  Use of 8-bit quantities to represent a
limited set of values is a false economy, I think.  And, of course, CORBA lives
without it.)

Comment 5

[John Bandhauer]

brendan: It doesn't matter how OMG defines these types. We are not interfacing
with Corba objects. We are just using a Corba-biased parser. *We* have distinct
typelib types for PRUint8, PRInt8, and char. But we only have two handy types
that the idl parser currently understands: octet and char. Even if char were
signed on all our platforms (is it?) we still don't want to map the PRInt8 to
char in nsrootidl because this *still* would not generate headers or typelibs
with PRInt8 in them. No, I really think the answer is that we need a new way for
the idl compiler to be told that a give param is of type PRInt8.

FWIW, I looked at...
http://www.omg.org/technology/documents/formal/c_language_mapping.htm
...and could not see that it specified this. And, again, I think this is moot.

Comment 6

[John Bandhauer]

Yeah, what shaver said. In doing nsIVariant I supported PRInt8 for completeness.
It required ugly casts to move the data in and out via params actually defined
as PRUint8. It was messy. But it will also probably never be called. I don't
much care if this support is ever added to xpidl or not. If it is, then with
luck the code in typelib clients will be correctly supporting this type if it
ever surfaces in a typelib.

Comment 7

[Brendan Eich [:brendan]]

jband: I know, I'm all over the IDL vs. typelib distinction.  I was mainly
interested in what OMG IDL specifies.  This bug can be futured or even (better)
wontfixed, IMHO.

/be

Comment 8

[David Bradley]

Marking WONTFIX. Blake, feel free to revive this if you can make a good argument.

Comment 9

[Blake Ross]

I can't. I'm worthless.