tinycc-devel
[Top][All Lists]
Advanced

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

Re: [Tinycc-devel] Can't compile the eiffel generated C files


From: Dave Dodge
Subject: Re: [Tinycc-devel] Can't compile the eiffel generated C files
Date: Mon, 1 Aug 2005 01:22:38 -0400
User-agent: Mutt/1.4.2i

On Mon, Aug 01, 2005 at 12:11:14AM +0700, Lothar Scholz wrote:
> >When a function is called using a prototype, the implicit argument
> >conversions are done with the same rules as assignment.  An assignment
> >of a structure pointer requires that the structures be compatible.
> >Structure compatibility requires all fields to match.  This is
> >essentially the same problem as:
> >
> >  struct x { int a; };
> >  struct y { int a; int b; };
> >
> >  struct x foo;
> >  struct y * bar;
> >  bar = &foo;        /* cast needed */
> 
> Sorry but i think this should compile nevertheless as such a case is
> well defined by the C-99 standard that it must copy the sizeof(bar)
> bytes from foo into bar.

While I agree that it probably should do this, I'm still not sure that
C99 defines the operation as valid.  Care to provide a reference?

Here's what I based my message on; note that this comes from the C99
draft rather than the final standard, so it may be that the final does
change this:

  6.5.2.2 Function calls
  Constraints

  [#2] If the expression that denotes the called function has a type
  that includes a prototype, the number of arguments shall agree with
  the number of parameters.  Each argument shall have a type such that
  its value may be assigned to an object with the unqualified version
  of the type of its corresponding parameter.

  Semantics

  [#7] If the expression that denotes the called function has a type
  that does include a prototype, the arguments are implicitly
  converted, as if by assignment, to the types of the corresponding
  parameters, [...]

  6.5.16.1 Simple assignment
  Constraints

  [#1] One of the following shall hold:

  -- [arithmetic types]
  -- [compatible structures and unions (not pointers)]

  -- both operands are pointers to qualified or unqualified versions
     of compatible types, and the type pointed to by the left has all
     the qualifiers of the type pointed to by the right;

  -- [pointers, but one of them has to be void*]
  -- [pointer = null pointer constant]
  -- [_Bool = pointer]

Note the requirement for type compatibility.

  6.2.7 Compatible type and composite type

  [#1] Two types have compatible type if their types are the same.
  Additional rules for determining whether two types are compatible
  are described in 6.7.2 for type specifiers, in 6.7.3 for type
  qualifiers, and in 6.7.5 for declarators.40) Moreover, two
  structure, union, or enumerated types declared in separate
  translation units are compatible if their tags and members satisfy
  the following requirements: If one is declared with a tag, the other
  shall be declared with the same tag.  If both are completed types,
  then the following additional requirements apply: there shall be a
  one-to-one correspondence between their members such that each pair
  of corresponding members are declared with compatible types, and
  such that if one member of a corresponding pair is declared with a
  name, the other member is declared with the same name.  For two
  structures, corresponding members shall be declared in the same
  order.  For two structures or unions, corresponding bit-fields shall
  have the same widths.  For two enumerations, corresponding members
  shall have the same values.

I read this as saying the pointers are not to compatible types; therefore
there is a constraint violation in 6.5.16.1.

                                                  -Dave Dodge




reply via email to

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