Re: [PATCH] C undefined behavior fix

[jtv <jtv@xs4all.nl>]

On Wed, Jan 02, 2002 at 05:29:35PM -0700, Tom Rini wrote:
>
> > Which it may do with another function *or expression* as well, because
> > the real bug has already happened before the function call comes into
> > the issue.
> 
> What's the bug?  The 'funny' arithmetic?
 
That depends on your definition of bug--symptom, "sighting" (thank you
Intel), or underlying problem.  The funny arithmetic, in C terms, is
the underlying problem.  The symptom is obvious.  The sighting involves
calls to what appear to be calls to the standard library, but in this
case happen not to be.  We'd still have the same problem if this really 
were the standard C library.


> > As far as I'm concerned the options are: fix RELOC;
> 
> How?

That's the EUR 64 * 10^6 question, isn't it?  It's likely to cost some
performance, but I suspect this would be the easiest solution.


> > obviate RELOC; use
> > an appropriate gcc option if available (-fPIC might be it, -ffreestanding
> > certainly isn't--see above);
> 
> Maybe for 2.5.  Too invasive for 2.4.x (initially at least).
 
I'm not saying these are attractive or even feasible, just prioritizing
the options I see.  I'm sure I'll have forgotten some, but I'm convinced
-ffreestanding isn't among them.

Let's say RELOC also broke in other places, for the exact same reason but
without (names familiar from) the standard library come into play.  How
would one recognize those cases?  And once diagnosed, how to go about
working around them?  Even worse, what if gcc tries to help but still
uses the stricter assumptions in some forgotten case?

Those would take time, and I can't see why none of these would arise
at some point.  That's why I feel -ffreestanding is too brittle as a
workaround.


> > *extend* (not fix, extend) gcc; or work
> > around all individual cases.  In rough descending order of preference.
> 
> Er, say what?

In rough descending order of _my_ preference, that is--falls within the
scope of the "as far as I'm concerned."  :)

But yes, requiring gcc to support RELOC through anything else than an
existing option (and once again, -ffreestanding only works around one 
instance where it breaks) would be an extension to gcc.  If it didn't
break in the past, that was essentially a coincidence.  Unless it's in 
some forgotten corner of the docs: possible, but not probable AFAICS.

Optimizing C is hard to do.  Pointer arithmetic is hell on an optimizer,
and the rules were made to give the latter a fair chance of doing a
good job.  I'm not arguing against having some specific option to relax 
those rules--kernels need to be written, and written in C.  But that 
option is by definition a compiler-specific extension to the language.


Jeroen