James Richard Tyrer wrote:
> On 04/19/10 18:04, Mike McCarty wrote:
>> James Richard Tyrer wrote:
>>> Is there something wrong with this code:
>>>
>>> NetworkManager-0.8.build/src/NetworkManagerPolicy.c:
>>>
>>> #include<ctype.h>
>>>
>>> if (isblank (*p) || (*p == '\0')) {
>>>
>>> ?? GCC-4.3.4 doesn't like it:
>>>
>>> NetworkManagerPolicy.c:272: error: implicit declaration of function
>>> 'isblank'
>> Yep. The Standard C provides somehthing which is similar to what is
>> meant, but the name is "isspace(.)". "isblank(.)" is a GNU
>> extension.
>>
> And I am compiling against GLibC, so it should be OK.
>
> Could this be the wrong error message?
I'm not sure I understand your question. Do you mean that there
may be some other error, and this warning is not the one
you need to be considering?
>> Are you compiling with strict ANSI compliance?
>
> The command when it doesn't work is:
[...]
> Doesn't look that way,
I concur.
>> isspace(.) looks for space, tab, vertical tab, newline, return,
>> and formfeed.
>> isblank(.) looks only for space and tab.
>>
>>> Any suggestions?
>>>
>>> Note that it does compile OK if I add the: "configure" paramater:
>>>
>>> --disable-more-warnings
>> Uh, it doesn't compile any differently, you just don't see the
>> warning. That function has no prototype in scope.
>
> The GNU: "ctype.h" header defines it as something else, apparently
> dependent on whether or not various things are defined, so there should
> be the function somewhere, but it is possible that the C headers are
> missing the prototype. That is a warning, not an error, so it should
> compile correctly.
There "is a function somewhere", and in this particular case
you'll probably not encounter a run problem, since the "default"
for functions is
int function_name();
However, if there _is_ an error in calling, then you'll not be
told. The correct prototype is
int isblank(int c);
which is _not_ the same. The above is compatible, but they are
definitely not the same.
> So, I added: "-Wno-error=implicit-function-declaration" to the above
> command and it compiles correctly. Using:
No, it compiles without warning. There is a difference. The fact is
that the program may contain an error that the compiler cannot detect,
and that's what it's warning you about. If there were a prototype in
scope, then there would be a class of error in the program which the
compiler could detect. As it is, there is a class of error which may
be in the program, and the compiler will not be able to detect one of
them.
To say that a program is without error is a much greater claim than
simply that there are no errors which the compiler can detect.
> "-Wno-error=missing-prototypes" doesn't fix it, so I doubt that it is a
> missing prototype.
I think you misunderstand the distinction between "missing prototypes"
and "implicit definition". They are not the same. For example, this
code would generate "missing prototype":
#include <stdio.h>
int isspace(int Chr) {
return (Chr == ' ') || (Chr == '\t');
}
int main(void) {
...
}
There is no prototype in scope for isspace(.), and the compiler would
warn you of that.
The function definition _becomes_ an implicit definition of a prototype,
and the compiler would warn you that you didn't otherwise have one.
That's distinct from there being no prototype _and_ no definition in
scope when the function gets used, and hence implicitly defined, which
is the warning you are getting. In that latter case, the compiler cannot
check any of the argument types, and if the function returns other than
type int, the compiler will generate bad code.
> What is implicit about the definition unless there is a problem with the
> header? OTOH, using: "isspace" instead of: "isblank" in the code fixes
> the problem cures the problem.
The implicit definition occurs because the function is used when
there is no protoype, either explicit (in <ctype.h> or otherwise)
or implicit (as in the code above, where the actual function
definition becomes the source for the prototype as well). In the
latter case, the compiler can go ahead and do checks of argument
types. In the former, it cannot.
The problem may be in the header, or it may be that there is not
proper preparation of #defines before the #include of the header.
I've done some work on porting of GCC to other platforms, and
the way they did the standard (and non standard) headers is
something of a maintenance nightmare.
In any case, this particular compile probably results in
programs which run the same as would be with a proper
prototype in scope. What I'm worried about is that this
indicates you have a fundamental problem in your build
environment, because there _should_ be a prototype in scope,
and that needs to be resolved.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
