Re: kernel-2.2.1-undefined references.

[Michael Gschwind <mikeg at watson dot ibm dot com>]

> Same goes for using inline functions before declaring them - there's no
> point in even asking the compiler to do global parsing (a compiler may
> offer it if it wants to, but requireing it is fairly obnoxious). 

That type of reasoning is not very standards-minded, but more like
special casing things that current compilers would generally do?

And besides, note that other compile hints, such as the "register"
attribute doesn't have to be adhered to, either.

It is safest when programming languages specify the semantics of the
program, and not bind some implementation meaning in... If for some
reason the compiler cannot inline it, then I think it is reasonable to
generate non-inlined code.  

> I'm not trying to be unreasonable. I'm just saying that if there is a
> function that is marked inline that can be inlined, it _should_ be
> inlined, because the compiler _never_ knows better than the programmer.

And compilers are dumb, so what should the compiler do with a register
attribute, when no registers are left?  Abort the compile run or
settle for the less perfect choice by allocating a stack frame slot?

I understand what your point is, i.e., I don't think the compiler
should CHOOSE to ignore the programer, but there can be a number
of reasons why the compiler may have no other choice. I think that is
what Joe was trying to tell you.  (And the reasons behind the compiler
not being to inline some functions may include deficiencies in the
compiler, as well as cost/benefit tradeoffs relating to memory
availability.   I must say I hate the latter type of limitations and
just wish all tools had a switch to use as much memory as deemed
necessary...)


m.

-- 
Michael K. Gschwind
IBM T.J. Watson Research Center     phone (external): (914) 945-3162
PO Box 218                          phone (internal): T/L 862-3162
Yorktown Heights, NY 10598          e-mail: mikeg@watson.ibm.com