This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: attribute "unpadded"


Andreas Schwab <schwab@suse.de> writes:

| Paul Koning <pkoning@equallogic.com> writes:
| 
| |> What I meant is: as far as I know, C has never had types that have
| |> this sort of properties, so the new class is unlike normal C types.
| |> And the restrictions are of a kind that a lot of C programmers would
| |> probably find rather surprising.  (It's not that they don't make sense
| |> if you analyze what is going on.  But C, nor for that matter any of
| |> the half dozen or so languages I can think of, doesn't have any types
| |> that aren't permitted as array elements.)
| 
| C always had function types and incomplete types, both are not valid as
| array elements.

Yes, however an important distinction is that function types
aren't object types and you can't create objects of incomplete types.
Having a complete object type for which pointer arithmetic isn't
allowed isn't something I'll say natural for C.

|  But the new types are neither functions nor incomplete,
| so there is something new about them.

Exactly.

I think Paul has a point here that needs some consideration as far as 
the pertubations to the existing type system are concerned.

Well, I won't repeat the arguments Mark himself made in the past
regarding extensions 8-)

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]