Re: Compile-Time Value Checking (Assertion) Support

[David Howells <dhowells at redhat dot com>]

Richard Henderson <rth@redhat.com> wrote:
> On Wed, Aug 01, 2001 at 02:18:13PM +0100, David Howells wrote:
> > This relies on __bad_udelay() getting referenced in the program when n is too
> > large, and causing a linker error, which is quite hard to trace since the
> > kernel build makes heavy use of incremental linking.
> 
> You know, if you built the kernel with -g, you'd get source line
> number information from the linker for the error.

The main aim of this is to make the code correct by avoiding the possibility
of false positives. With the method currently used at the moment, there is
nothing to stop the compiler generating a reference to the undefined
__bad_udelay symbol anyway.

So you can look on it as the code should properly be considered incorrect, but
that we can escape by means of a compiler quirk, provided that the user of
that code gets the parameter to udelay() in the correct range.

A secondary aim is to avoid having coders asking silly questions because
there's an unresolved symbol.

Additionally, this method allows reasonable documentation of the cause of the
error to be placed in the message generated by the compiler.

Furthermore, your suggestion requires (a) people to compile with -g, and (b)
people to _know_ that compiling with -g will show what line generated the
error. The kernel is very rarely compiled with -g.

There are also other places where we might want to use this in the kernel,
such as checking that kmalloc()'s flags parameter is not zero..

David