# New Ticket Created by  "Adam Thomason" 
# Please include the string:  [perl #24247]
# in the subject line of all future correspondence about this issue. 
# <URL: http://rt.perl.org/rt2/Ticket/Display.html?id=24247 >


The extension code has some type safety troubles.  For instance, when
PARROT_IN_CORE is defined, Parrot_CharType is declared by

  #define Parrot_CharType struct parrot_chartype_t *

in include/parrot/chartype.h.  However, outside of the core,
include/parrot/extend.h instead declares it as

  typedef void * Parrot_CharType;

This causes problems because Parrot_find_chartype returns a "const
Parrot_CharType".  In the core, this is ok,  because it expands via the
preprocessor to "const struct parrot_chartype_t *", which is a valid
return type.  However, when compiling an extension, the typedef causes
"const Parrot_CharType" to  become a "struct parrot_chartype_t * const",
which is not the same and is seemingly an illegal return type according
to VisualAge C (*1).  On account of this, it refuses to compile code in
extend.t which includes extend.h.  The same problem applies to
Parrot_Encoding vis-a-vis Parrot_find_encoding.

There are two solutions, both of which involve making the declarations
consistent.  Either use #define's in extend.h as in chartype.h for
Parrot_CharType and encoding.h for Parrot_Encoding, or create an extra
typedef for each (e.g. Parrot_Const_CharType).  I tend to avoid the
preprocessor for type magic when possible, so I've opted to make the
latter changes (*2), even though it requires extra definitions.  If
there's a reason they were originally #define'd, that should work also,
but I haven't tried it.

*1) Googling around seems to indicate that ANSI C doesn't allow return
types to be const- or volatile-qualfied.  "const struct
parrot_chartype_t *" is a non-const pointer to const, which is okay;
"struct parrot_chartype_t * const" is a const pointer to non-const,
which is thus illegal.  I don't see anything in the C99 final draft
concerning this, so the restriction might have been lifted to match C++
semantics (passing -qlanglvl=C99 to xlc turns the error into a warning,
which partly supports that theory).  Which version are we targetting
anyway?  I don't see a definitive statement anywhere in docs/.

*2) Patch attached, extend tests now pass on AIX and don't break Gentoo.

--
Adam Thomason
[EMAIL PROTECTED]


Reply via email to