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: Patch to allow Ada to work with tree-ssa


[I'm moving this to the gcc list and off gcc-patches]

    this is my point. What is the point of this extension?
    * It's not documented, so users have no formal knowledge of its existance
    * It's not documented, so users have no guarantee that it'll continue
    to work

Historically, very few C programs read standards or give any thought at all
to what's "guaranteed".  If anything, I'd suspect that practice to have
gotten worse.

    * IMO, it's marginally useful to have a variable length array in the
    *middle* of a C structure

It's marginally useful to do it in *any* language!  But that doesn't mean it
isn't done.  There have been quite a few cases when experienced programmers
at large aerospace companies have (in Ada) written structures that consist of
one or more variable-length arrays followed by a hundreds of scalars.

They then complain about the size of their executables.  So it's suggested to
them that they should reorder their structures to put the variably-sized
fields first.  When they do that, they are amazed at how much smaller and
faster their application is (note that although GNAT doesn't do it, the Ada
standard allows a compiler to do that reordering, but C doesn't).

You would think experienced programmers would know how inefficient this is,
but apparently they don't.  I don't want to go too far down a tangent, but
it's now quite possible to get a CS degree (perhaps even a graduate degree)
without knowing anything about assembler language or architecture, so things
that are obvious to us as things that "you shouldn't do" seem perfectly
reasonable to a lot of programmers.

    Then document it. And the fact that it didn't work properly, and
    you're having such grief getting it working seems to imply 'easily
    support' is not actually true.

I'm not sure exactly what you're asking to document.  We document that GNU C
allow variable-sized arrays in general.  It's part of C that you can put an
arbitrary type inside a struct.  The testcase I showed is just a composition
of two documented features.

This is the case with much of language complexity: the hardest cases
are those where two or more features of the language are composed together.

What I meant by "easily support" is that since it's needed for Ada anyway,
the cost of doing it for C too is trivial.

    I'd like to know how many real (not a testcase) GNU C programs out
    there use this varray-in-middle idiom (really, I would).

Unfortunately, there's no way to get that data.


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