Re: make #pragma pack() implementation consistent with other compilers(PR c/7054)

["Joseph S. Myers" <jsm at polyomino dot org dot uk>]

On Wed, 7 Jul 2004, Jan Beulich wrote:

> For the documentation requirements (I'm still learning doing 'open
> source', and previously I was used to there being someone else taking
> care of documentation stuff, after all I'm not a technical writer but a
> programmer): Can you suggest an obvious to use editor for the .texi
> files (not a plain text one, so I won't have to twiddle the directives
> in there a hundred times)?

As far as I know developers generally edit the files as plain text.  A
good discipline - though there's no requirement for this as long as the
final submitted patch follows all the requirements, and not all parts
necessarily apply to all patches - is:

* First write any documentation appropriate for the manuals for any new
features or interfaces: specify what the patch is intended to do.

* Then write the testcases for the features, by which you will know
whether the patch works and people later will know whether they've broken
it.  (The testcases should generally fail before you apply the patch, and
pass afterwards.)

* Then write the code itself; this may feed back to the previous parts if
special cases show up in the process that need documenting or testing.

* While you were doing these three, a baseline build can have been
running.  Apply the single patch to the baseline, and test the patched
tree (best to test with the *only* variable changed from the baseline
being the single patch, rather than using baseline results from a slightly
different tree or just eyeballing the test results rather than comparing
with a baseline).

* You can do something else while the tests of the patched tree are
running.

> For the unmentioned test case changes: Without them these tests fail if
> you have a target that requires less than word alignment as the default
> setting (which is what DEFAULT_PACK_STRUCT is used for). Thus for such
> targets the packing value has to be set high enough (and thus the value
> 8 to accomodate all targets up to 64 bits). It seemed inappropriate to
> add options for individual targets here when adding them globally does
> not do any harm), but it could of course be done.

I think you need more explanation of *why* the tests fail, and why they
can't be made more portable to systems with different alignment
requirements (while still testing what they're meant to test) rather than
needing special options.  And they still need including in the ChangeLog
entries.

> later running into the same problem again). As said above (and as got to
> hear previously), everyone's (supposedly) playing by these rules.
> Whether everyone's pleased by them doesn't matter. Whether this severly
> limits productivity doesn't matter either.

If anything, the rules should be even stricter, as the tree still seems to
be in an almost perpetual state of many regressions on multiple platforms.

Zack's paper
<http://www.codesourcery.com/public/publications/a_maintenance_programmers_view_of_gcc.pdf>
discusses some of the maintenance problems with GCC.  Weakening submission
requirements is not a useful solution if the tree is to be kept
high-quality.  Systematic cleanups (completing incomplete transitions, so
the existing code is more consistently a good example of how new code
should do things) may be.  In general contributors eventually learn to
follow the requirements automatically.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)