Re: Why oh why does this NOT give a compile error?



On 5 Nov., 13:38, James Kuyper <jameskuy...@xxxxxxxxxxx> wrote:
Paul Melis wrote:
Can someone explain to me why the following code compiles without
errors on gcc 4.0.2?

void f()
{
}

void t()
{
f(1,2,3);
f("1");
}

I would expect at least some warning, but not even that. Is this a
feature of the newest C dialect or something, that you can provide
arbitrary arguments to a function having no arguments?

No, it's a feature of the C standard that this code has undefined
behavior, but is neither a syntax error nor a constraint violation, and
therefore does not require a diagnostic message. A good compiler might
provide one. The more fundamental problem is that you should be using
function prototypes, in which case the corresponding code would require
a diagnostic message.

What compiler options are you using? With the right compiler options,
gcc can be a good compiler, though what it produces is a warning about
the more fundamental problem, rather than the one you're actually asking
about:

cc -std=c99 -pedantic -Wall -Wpointer-arith -Wcast-align -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -c -o ft.o ft.c
ft.c:2: warning: function declaration isn't a prototype
ft.c:6: warning: function declaration isn't a prototype- Zitierten Text ausblenden -

- Zitierten Text anzeigen -


No, it's a feature of the C standard that this code has undefined
behavior, but is neither a syntax error nor a constraint violation, and
therefore does not require a diagnostic message.

Exactly!
Things that are "correct" in C might still not always be the best
solution.

Think about the following:

(array[i] == i[array]) will return (!0)
array[i] is the same as i[array], and it is perfectly correct in C.
But you still would not want to use it.

Why?
array[i] == *(array+i) == *(i+array) == i[array]

Christian

.



Relevant Pages

  • Re: POSIX_C_SOURCE
    ... > is defined to have a value of zero, and GCC ... Many gcc options generate warnings with legal C source and this is ... The problem is one of incompatibility between the header files and the ... compiler options selected. ...
    (freebsd-stable)
  • Re: Why oh why does this NOT give a compile error?
    ... void f ... I would expect at least some warning, ... With the right compiler options, gcc can be a good compiler, though what it produces is a warning about the more fundamental problem, rather than the one you're actually asking about: ...
    (comp.lang.c)
  • Re: [klibc 07/31] i386 support for klibc
    ... effects of compiler options on libgcc, especially the ones that affect binary ... The semantics of these functions are well-defined, stable, and documented in the gcc documentation. ... klibc is shared, not dynamic, but it also means that there is no cross-version calling; each build of the shared klibc library has a hashed filename, thus allowing multiple versions of klibc to coexist if absolutely necessary. ... workarounds for gcc bugs in the kernel. ...
    (Linux-Kernel)
  • Re: [PATCH]: warrning fix: unsigned->signed
    ... The patch seems OK, but I'm curious to know why you're seeing this warning ... Are you using a compiler other than gcc? ... Did you add any new compiler options? ...
    (Linux-Kernel)
  • Re: to reduce footprint
    ... debug info during make phase, ... as they are more familiar with the gcc tools. ... I am wondering how to reduce the footprint of a binary build ... I think some linker or compiler options may help, ...
    (microsoft.public.windowsce.platbuilder)