| View previous topic :: View next topic |
| Author |
Message |
Oortje
n00b
Joined: 24 Jul 2002
Posts: 14
Location: Netherlands
|
 Posted: Tue Aug 13, 2002 7:31 pm Post subject: Do YOU actually look at the compiler warnings? |
 |
|
When I upgraded my system to gentoo 1.3b I redirected all the output of the install phases to seperate files, but never really bothered looking into them. But when I do, I'm truly amazed that gentoo works at all. Examples:
bootstrap fase (not displaying many 'uninteresting' ones):
warning: assignment discards qualifiers from pointer target type
warning: assignment makes pointer from integer without a cast
warning: comparison between signed and unsigned
warning: comparison is always false due to limited range of data type
warning: comparison of unsigned expression >= 0 is always true
warning: concatenation of string literals with __FUNCTION__ is deprecated
warning: control reaches end of non-void function
warning: division by zero
warning: function returns address of local variable
warning: function-like macro "FG" must be used with arguments in traditional C
warning: function-like macro "FH" must be used with arguments in traditional C
warning: function-like macro "FI" must be used with arguments in traditional C
warning: multi-line string literals are deprecated
warning: operation on `PC' may be undefined
warning: operation on `buf' may be undefined
warning: operation on `genp' may be undefined
warning: operation on `ixdr' may be undefined
warning: operation on `port' may be undefined
warning: pointer targets in passing arg 1 of `do_SUBST_INT' differ in signedness
warning: signed and unsigned type in conditional expression
warning: string length `2143' is greater than the length `509' ISO C89 compilers are required to support
warning: string length `3439' is greater than the length `509' ISO C89 compilers are required to support
warning: traditional C rejects string concatenation
warning: weak declaration of `_IO_do_write' after first use results in unspecified behavior
kernel phase (...):
warning: assignment from incompatible pointer type
warning: comparison of distinct pointer types lacks a cast
warning: concatenation of string literals with __FUNCTION__ is deprecated
warning: deprecated use of label at end of compound statement
system phase (...):
warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <sstream> instead of the deprecated header <strstream.h>. To disable this warning use -Wno-deprecated.
warning: Assuming unsigned for type of bool
warning: Charset "CHARSET" is not a portable encoding name.
warning: Charset "ISO8859-9" is not a portable encoding name.
warning: Charset "iso8859-1" is not a portable encoding name.
warning: Charset missing in header.
warning: `.' or `,' must follow cross reference, not ).
warning: `.' or `,' must follow cross reference, not a.
warning: `.' or `,' must follow cross reference, not f.
warning: assignment discards qualifiers from pointer target type
warning: assignment from incompatible pointer type
warning: assignment makes pointer from integer without a cast
warning: cast discards qualifiers from pointer target type
warning: comparison between pointer and integer
warning: comparison between signed and unsigned
warning: comparison of distinct pointer types lacks a cast
warning: concatenation of string literals with __FUNCTION__ is deprecated
warning: const qualifier ignored on asm
warning: extra tokens at end of #endif directive
warning: format argument is not a pointer (arg 4)
warning: function `recvfrom' was previously declared within a block
warning: function-like macro "F1" must be used with arguments in traditional C
warning: initialization from incompatible pointer type
warning: multi-line string literals are deprecated
warning: no previous prototype for `grub_memcpy'
warning: operation on `buf' may be undefined
warning: passing arg 1 of `_pc_yyerror' discards qualifiers from pointer target type
warning: pasting "->" and "cmaj_flt" does not give a valid preprocessing token
warning: previous rule lacks an ending `;'
warning: reading through null pointer (arg 5)
warning: return makes pointer from integer without a cast
warning: return type of `main' is not `int'
warning: signed and unsigned type in conditional expression
warning: suggest parentheses around assignment used as truth value
warning: too many arguments for format
warning: traditional C rejects automatic aggregate initialization
warning: traditional C rejects string concatenation
warning: traditional C rejects the 'u' suffix
warning: trigraph ??) ignored
warning: type qualifiers ignored on function return type
warning: unlikely character ( in @var.
warning: unlikely character ] in @var.
warning: unsigned int format, different type arg (arg 3)
Would YOU trust your gentoo install with such warnings?
_________________
"All idealism is falsehood in the face of necessity." -- Nietzsche |
|
| Back to top |
|
 |
El_Presidente_Pufferfish
Veteran
Joined: 11 Jul 2002
Posts: 1179
Location: Seattle
|
| Posted: Tue Aug 13, 2002 7:39 pm Post subject: |
|
|
How do you redirect the output?
I usually see a lot of errors streaming by but they go by too fast...and they usually compile in the end |
|
| Back to top |
|
|
proxy
Apprentice
Joined: 20 Apr 2002
Posts: 260
Location: Chantilly, VA
|
| Posted: Tue Aug 13, 2002 7:40 pm Post subject: |
|
|
yes i would, this is not a compiler issue, this is a source code issue. the easrlier versions of gcc were just not compliant enough to pick up on these (for example, many programs seem to do poiter arithmetic on void * pointer which is clearly illegal (what's the size of nothing?). older gcc didnt complain too much, but the newer ones bitche like all hell (but assumes they meant to cast to an int). The warnings are normal... if they bother you, contact the developer asking them to fix there broken code 
also keep in mind that somtimes developers do quazi legal things intentioanally, for example:
| Quote: | | warning: comparison between signed and unsigned |
is just fine so long as you know that it COULD be a problem in some contexts...but is usually not.
also many warnings are do to depricated (out of date, but not removed yet from standard) features. such as using a #include <stdio.h> instead of #include <stdio>..this is just fine just not well liked by the standards commitee 
finally MUCH of the warnign involve a little pointer voodoo  which is really just fine if you really know what you areing, the compile is just saying...."well if you dont know why you get this warning, you probably don't know what the f*ck you are doing! FIX IT!" hehe.
all in all, dont worry out it. |
|
| Back to top |
|
|
trythil
Tux's lil' helper
Joined: 06 Jun 2002
Posts: 123
Location: RHIT, Terre Haute, IN, USA
|
| Posted: Tue Aug 13, 2002 9:55 pm Post subject: |
|
|
Some fixes and an opinion:
| proxy wrote: | yes i would, this is not a compiler issue, this is a source code issue. the easrlier versions of gcc were just not compliant enough to pick up on these (for example, many programs seem to do poiter arithmetic on void * pointer which is clearly illegal (what's the size of nothing?).
|
Erm, the size of a void * isn't "nothing". On IA32 systems it's the same as any other pointer -- 4 bytes. (IIRC.)
| Quote: |
also many warnings are do to depricated (out of date, but not removed yet from standard) features. such as using a #include <stdio.h> instead of #include <stdio>..this is just fine just not well liked by the standards commitee
|
#include <stdio.h> is still accepted. It's #include <iostream.h> which isn't -- that becomes #include <iostream>. #include <cstdio> is the Standard C++ forwarding header.
---
Now, about code warnings:
They are there for a reason. When the compiler gives a warning, you are doing something that isn't quite illegal, but isn't really a good practice, either. For example, "comparison between signed and unsigned" -- this can be a BAD thing in some cases. What happens when the value of the unsigned variable you're comparing your signed variable to becomes greater than what the signed variable can hold?
Many compiler warnings don't translate into run-time problems, but rather small, creeping bugs that pop up as
(1) weird problems later on, or
(2) security holes.
So, yes, it would be a good idea to investigate just what causes those warnings, and fix them if you deem necessary. |
|
| Back to top |
|
|
rac
Bodhisattva
Joined: 30 May 2002
Posts: 6553
Location: Japanifornia
|
| Posted: Tue Aug 13, 2002 10:25 pm Post subject: |
|
|
| trythil wrote: | | Erm, the size of a void * isn't "nothing". On IA32 systems it's the same as any other pointer -- 4 bytes. (IIRC.) |
Yeah, but pointer arithmetic works on the size of the pointee, not the size of the pointer.
_________________
For every higher wall, there is a taller ladder |
|
| Back to top |
|
|
proxy
Apprentice
Joined: 20 Apr 2002
Posts: 260
Location: Chantilly, VA
|
| Posted: Wed Aug 14, 2002 1:19 am Post subject: |
|
|
according to ISO standard void * arithmatic is strictly illegal, just many compilers just assume you want integer (4 bytes) math.
| Quote: | | #include <stdio.h> is still accepted. It's #include <iostream.h> which isn't -- that becomes #include <iostream>. #include <cstdio> is the Standard C++ forwarding header. |
hehe, i was thinking iostream in my head by typed stidio..
as for the warnings, i think we are saying the same thing, they are clearly there because the operation while legal is not recomeneded, but as long as the developer is aware of the side effects, this is just fine.
proxy |
|
| Back to top |
|
|
Oortje
n00b
Joined: 24 Jul 2002
Posts: 14
Location: Netherlands
|
| Posted: Wed Aug 14, 2002 8:07 pm Post subject: |
|
|
Hmmm ... 'this is just fine' ... ? Did you actually look at *each* of the warnings individually? Let me hightlight a few:
| Code: |
warning: comparison is always false due to limited range of data type
warning: function returns address of local variable
warning: format argument is not a pointer (arg 4)
warning: too many arguments for format
|
Can you tell me with a straight face that you actually believe the developer knew what he was doing? (or has any knowledge of coding standards?)
_________________
"All idealism is falsehood in the face of necessity." -- Nietzsche |
|
| Back to top |
|
|
mglauche
Retired Dev
Joined: 25 Apr 2002
Posts: 564
Location: Germany
|
| Posted: Wed Aug 14, 2002 8:46 pm Post subject: |
|
|
hehe keep in mind that most open software is about "it works for me, thats it, if it doesn't work for you, send me a patch"
open softeare programmers are hobby programmers, not high paid coders that program for a living |
|
| Back to top |
|
|
phong
Bodhisattva
Joined: 16 Jul 2002
Posts: 778
Location: Michigan - 15 & Ryan
|
| Posted: Wed Aug 14, 2002 8:58 pm Post subject: |
|
|
| Oortje wrote: | Hmmm ... 'this is just fine' ... ? Did you actually look at *each* of the warnings individually? Let me hightlight a few:
| Code: |
warning: comparison is always false due to limited range of data type
|
|
Well, occasionally it's useful to write an assertion that's always false to disable a section of code (to disable a buggy feature or something). Since it creates a warning, it's self documenting, so you know to go in to fix it in a better way later (remember that some of the packages used by Gentoo are really bleeding edge). Also, the warning might occur on our puny systems with 32 bit integers, but on a 64 bit system, it behaves differently (intentionally, though there are probably better ways).
| Quote: | | warning: function returns address of local variable |
This could be used to give the calling function some idea of the way the stack is being constructed on whatever machine it is on. It could be used as a run-time workaround for some conflict between something very strange that the program does and certain combinations of compilers/machines.
| Quote: | warning: format argument is not a pointer (arg 4)
warning: too many arguments for format
|
I got nothin' for these. Likely just mistakes, but they're innocuous and haven't gotten fixed (or are on the back burner because there's some bugs more serious than compiler warnings).
| Quote: | | Can you tell me with a straight face that you actually believe the developer knew what he was doing? (or has any knowledge of coding standards?) |
Ok, so I DIDN'T have a straight face. Big whoop. I doubt whatever was done to cause those was a GOOD idea, but it's possible. |
|
| Back to top |
|
|
rac
Bodhisattva
Joined: 30 May 2002
Posts: 6553
Location: Japanifornia
|
| Posted: Wed Aug 14, 2002 9:03 pm Post subject: |
|
|
Also remember that those warnings quoted occurred during the bootstrap process, when things like glibc and gcc were being compiled. If there's one program that is probably allowed to take advantage of every little quirk and obscure nook and cranny of compiler behaviour, it would be the compiler itself.
_________________
For every higher wall, there is a taller ladder |
|
| Back to top |
|
|
TuxFriend
Apprentice
Joined: 14 Aug 2002
Posts: 151
|
| Posted: Wed Aug 14, 2002 9:11 pm Post subject: Re: Do YOU actually look at the compiler warnings? |
|
|
| Oortje wrote: |
Would YOU trust your gentoo install with such warnings? |
That's the beauty of Gentoo, you can see what's happening. You can bet on it that RPM-based distro's get the same errors when they compile the stuff but you just don't see it and therefore have no idea what the reason might be for a problem.
TuxFriend
PS. don't worry to much about these warnings, most of them will cause no problems. |
|
| Back to top |
|
|
steblublu
n00b
Joined: 12 Jul 2002
Posts: 49
Location: montreal, canada
|
| Posted: Thu Aug 15, 2002 10:40 am Post subject: |
|
|
| trythil wrote: | | For example, "comparison between signed and unsigned" -- this can be a BAD thing in some cases. What happens when the value of the unsigned variable you're comparing your signed variable to becomes greater than what the signed variable can hold? |
You hope the author has put range checks into his code,regardless of any casting or comparisons that may be done.
. |
|
| Back to top |
|
|
sibn
n00b
Joined: 15 May 2002
Posts: 36
|
| Posted: Thu Aug 15, 2002 2:33 pm Post subject: |
|
|
| Oortje wrote: | | Can you tell me with a straight face that you actually believe the developer knew what he was doing? (or has any knowledge of coding standards?) |
Yes, actually. There are a few reasons for this:
First of all, whether you want to believe it or not, the glibc, gcc, and kernel hackers are all a lot smarter than you, when it comes to programming. With that out of the way, it's important to realize that a warning is just that: A warning. It's to let you know that something MAY be going on that you didn't intend.
gcc throwing a warning is NOT equivalent to gcc throwing an error. Just think for a second, and realize that there are at least 200MB of source code (uncompressed) for linux, xfree, glibc, and gcc, etc. Warnings are plentiful enough to be noticed, but they hardly overrun the code. And they are perfectly legal, usually.
void* arithmetic may be illegal, but if gcc accepts it, then is there any real reason not to use it in the source code for gcc itself?
As somebody else said, range checks can be used to ensure that comparisons between signed and unsigned values are valid- though you assume there are no such checks. It's possible that such checks aren't even required- for example, a signed integer that's never greater than 300,000 and never less than 100,000 can always safely be compared to an unsigned integer.
I believe you can cause an "always false" conditional by using "if (DEGUB_MODE)", when DEBUG_MODE is defined as 0. why use if() instead of #ifdef? Who knows? It's not invalid or illegal to say if (0) or if (1). And any developer who does this is certainly aware of what it will do.
I could go on and on, but it's really not necessary. all you have to do is realize that warnings and errors are two entirely seperate beasts. Warnings do not indicate problems, errors do. Warnings indicate potential problems, and any intelligent developer is aware of them and prevents them from actually *being* problems.
Edit: I've just been informed by El Constipatio that part of this is wrong. However, I'm going to refuse to correct it because there's already so much blatant bullshit flying around in here that I don't want to feel left out for being the only person with any brains. You can take a guess at which part is right, although as a hint: It's related to my understanding of expressions always being false.
_________________
Hey um, this is my signature. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
