Re: I request inclusion of reiser4 in the mainline kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/20/05, Alexandre Oliva <[email protected]> wrote:
> On Sep 20, 2005, Stephen Pollei <[email protected]> wrote:
> > On 9/19/05, Horst von Brand <[email protected]> wrote:
> >> Since when has a missing declaration prevented anyone calling a function in
> >> C?!
> > Never AFAIK... K&R, ANSI,ISO C89,  c99, whatever version that I know of...
> 
> Actually...  C99 requires a declaration (not necessarily with a
> prototype) before a function can be called.  A prior declaration is
> required for all identifiers.

OK thank you for your correction.

> I'm not sure whether this is new in C99
> or carried over from ISO C90 (AKA ANSI C89).  The fact that so many
> compilers accept calls without prior declarations is a common
> extension to the language, mainly for backward compatibility.

yep I just tested a small program with different flags...
int main(void) {
  int ret;
  ret=my_func(3);
  return 0; }

float my_func(double x) {
  return x+2.0;}

gcc -Wall test_proto.c --std=c99
and even gcc -Wall test_proto.c --std=c99 -pedantic
give me this:
test_proto.c: In function `main':
test_proto.c:6: warning: implicit declaration of function `my_func'
test_proto.c: At top level:
test_proto.c:9: warning: type mismatch with previous implicit declaration
test_proto.c:6: warning: previous implicit declaration of `my_func'
test_proto.c:9: warning: `my_func' was previously implicitly declared
to return `int'

it takes gcc -Wall test_proto.c --std=c99 -pedantic-errors to cause it
not to create the a.out .
So gcc should have caused an error as I didn't set --std=gnu99 .. bad compiler.

So I don't know howto get gcc to follow the standards in this area,
that sounds like a good thing to require.

> > It's really over silly anyway, as it will fail at link time if they
> > had matching preprocessor stuff around the function definition.

> Not really.  A compiler might optimize away the reference to the
> symbol if it's say guarded by a condition whose value can be
> determined to be false at compile time.  If you rely on that, moving
> to a different compiler that is unable to compute the condition value,
> or simply is pickier as to standard compliance, will get you errors.

True again, especially since the kernel code itself relies on that
kind of behavior in some of it's inline functions or macros for
example to cause link errors only when specific conditions arise.
so the construct:

#if conditions
/* function prototype(s) */
#else
#define whatever(a,b,c) /* something to crash the compile */
#endif
is truely the best solution, if the namesys people want to be
absolutely sure to catch all
calls to znode_is_loaded when debuging is not set....

#define znode_is_loaded(I_dont_care_you_are_going_to_) \
 } )die(]0now[>anyway<}}}}}}*bye*}
#define znode_is_loaded(z) ><<<>

Either one of the above defines should be sufficiently crappy to cause
gcc to bomb out.
I'm so sure(some say full) of it that I'm too lazy to test it out for myself.
Of course a _Pragma("error") would`a been nice.

Simply not providing a prototype to generate a warning was just
BAD(B0rken As Designed).

-- 
http://dmoz.org/profiles/pollei.html
http://sourceforge.net/users/stephen_pollei/
http://www.orkut.com/Profile.aspx?uid=2455954990164098214
http://stephen_pollei.home.comcast.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux