Re: PATCH to implement `restrict' in C

[Jeffrey A Law <law at cygnus dot com>]

  In message <199810142329.QAA11079@smtp.earthlink.net>you write:
  > > Unless we are literally importing this code from elsewhere, we should
  > > avoid changing the convention for typedefs.
  > 
  > I guess what I don't like is that there is *no* convention for
  > typedefs.  I'll remove the "_t" bits, though, and try to remember this
  > in the future.
Well, it's an unwritten convention :-)  We should write it down, no "_t"
suffixes :-)

On a slightly related note, Goeff noer has asked if we can move the dynstring
code into libiberty.  Apparently he wants to use it for something :-)  If
it's OK with you I'd like to go ahead and make that change.  We'll need to
put its external header file into include, or if the number of interfaces
are small, then in libiberty.h directly.

We may want to go ahead and put splay-tree into libiberty from day 1, which
would also be fine with me.

  > OK, but then they'll be unprototyped.  The only headers with
  > xmalloc/xrealloc are rtl.h and tree.h, but neither of those belong in
  > splay-tree.c.  In fact, splay-tree.[hc] could also go in libiberty.
Ah.  If there's no good file to include, then don't worry about it.

Note if we move it into libiberty, then it can include libiberty.h I think
which should have those prototypes.


  > OK.  I'll change the spelling of -frestrict to -fisoc9x, and alter the
  > documentation accordingly.  If there are other c9x features (like
  > _Pragma) implemented, they can go under this flag.
I'd make it a -lang-c9x to be consistent with other options which control
language dialects.

  > Dang it; I just can't seem to get my fingers to do that right.
Habits are hard to break.  Until I came to Cygnus I had to work in three
separate coding styles (knr, gnu & mach).  I had a hell of a time keeping
one format from infecting files from other projects.

My personal feelings about the GNU standards aside, it was *real* nice to
be able to work with only one coding style once I left the UofU.

  > I've done my best to address them.  The short answer is that I think the
  > patch is fully ISO C9x compliant, even where it doesn't take full
  > advantage of the optimization opportunities provided.  As for C++, I
  > plan on doing the work, and most of it will be straightforward.  We can
  > hash out the bit about `restrict' member functions at a later time;
  > there's no standard to guide us here.
Thanks.  That's what I expected and wanted to hear.

  > If I make the changes mentioned above, make I check in the patch?
With the -lang-isoc9x change, yes.  Your choice what to do about putting
splay trees into libiberty.

jeff