Re: problem building a GCJ-friendly GNU Crypto

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> I'm not surprised.  Many unspoken, non-portable assumptions are made
> in GCC and I view them as bugs.  I don't think that the general
> approach to that is  to add flags each time we find one.  The sooner,
> it breaks, the better.

Personally, I believe that it is useful to have an option to provide
left to right evaluation of expresssions where currently the C standard
leaves the evaluation order undefined.  This is useful for numeric
applications where evaluation order is sometimes critical.  As a result
of fewer parentheses, it can make the code more readable.  Java seems to
need this anyway, so it will get tested.

Apparently, gcc previously provided left to right evaluation as the
default.  There is certainly a lot of code that inadvertantly assumes
left to right evaluation.  Thus, changing gcc to exploit the undefined
evaluation order allowed in the standard could break a lot of code in
subtle ways.  If the code is controlling a nuclear reactor or the
brakes in your car, you don't want it to break.

So, I think the questions are:

  1) Are the benefits in exploiting the undefined evaluation order 
     worthwhile?

  2) Should we maintain the current left to right evaluation order
     as an option if 1 is implemented?

I'm sure everybody agrees that the non-portable assumptions made in
GCC code should be eliminated.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)