discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: This NSConstantString thing


From: Richard Frith-Macdonald
Subject: Re: This NSConstantString thing
Date: Wed, 13 Mar 2002 16:55:18 +0000

On Wednesday, March 13, 2002, at 04:27 PM, Richard Frith-Macdonald wrote:


static int
check_string_class_template ()
{
  tree field_decl = TYPE_FIELDS (constant_string_type);

#define IS_FIELD_OF_TYPE(F, T) \
  (F && TREE_CODE (F) == FIELD_DECL && TREE_CODE (TREE_TYPE (F)) == T)

  if (!IS_FIELD_OF_TYPE (field_decl, POINTER_TYPE))
    return 0;

  field_decl = TREE_CHAIN (field_decl);
  if (!IS_FIELD_OF_TYPE (field_decl, POINTER_TYPE))
    return 0;

  field_decl = TREE_CHAIN (field_decl);
  return IS_FIELD_OF_TYPE (field_decl, INTEGER_TYPE);

#undef IS_FIELD_OF_TYPE
}
/* APPLE LOCAL end Objective-C++ */

... and later:

      if (!check_string_class_template ())
    {
      error ("interface `%s' lacks required ivars",
         IDENTIFIER_POINTER (constant_string_id));
      return error_mark_node;
    }
...

It's the code which checks for some specific ivar layout and it doesn't see a pointer inside a union as a valid pointer. The later is the type of incompatibility I'm speaking of.

Ok ... so parhaps apple have broken the compiler somewhat ... could report it as a bug. However, the above code looks correct to me ... ie it would appear to be checking to see that the declared ivars are a pointer, a pointer, and an integer ... which is what they were and are. So given that the compiler seems to be checking for the ivar types which were in fact present, I still wonder if there was not some sort of header file confusion going on. However, I don't know gcc internals to say whether the
IS_FIELD_OF_TYPE() macro is doing the right thing.

Sorry, misread originally ... in re-reading it's clear that the IS_FIELD_OF_TYPE() macro isn't allowing for unions, so there definitely *is* a problem in the compiler.

However, the current solution of giving the compiler a dummy declaration which we
never use should work round that.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]