LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices


Reply
  Search this Thread
Old 01-13-2020, 07:18 AM   #1
hazel
Senior Member
 
Registered: Mar 2016
Location: Harrow, UK
Distribution: LFS, AntiX, Slackware, OpenBSD
Posts: 4,069
Blog Entries: 11

Rep: Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245
A general question about compiler warnings


People who start programming are usually told to take compiler warnings seriously, or even to compile with the -werror flag which treats warnings as errors. That's because they often are errors. For example, if the types in an assignment don't match, the chances are quite high that you have accidentally used the wrong variable name. The result will be compilable but it won't do what you intended.

But when you build packages from source, there are always loads of warnings and you learn to ignore them. Why don't the people who write the code follow their own guidelines?

Last edited by hazel; 01-13-2020 at 07:53 AM.
 
Old 01-13-2020, 08:17 AM   #2
boughtonp
Member
 
Registered: Feb 2007
Location: UK
Distribution: Debian
Posts: 255

Rep: Reputation: 147Reputation: 147
Well you're assuming that they're the same people, which isn't necessarily the case.

But even when they are the same, there are various potential reasons.

For example, some people get stuck at places where code needs to be "working" and there "isn't time" to make it well-written; the developer might always intend to go back later and fix it, but doesn't get the chance. If they later find themselves helping a new developer, it's natural to advise against repeating their mistakes.

Or perhaps the code was simply written against a previous version of the language/compiler which didn't feature those warnings, and because nobody has raised issues about the warnings the developer assumes all is fine.

 
1 members found this post helpful.
Old 01-13-2020, 08:27 AM   #3
SoftSprocket
Member
 
Registered: Nov 2014
Posts: 220

Rep: Reputation: Disabled
That's a good question Hazel. C allows the programmer so much leeway that warnings are invaluable in helping find issues. Real problems can hide in lists of warnings.

I keep my warnings turned up and clear them. My cflags typically looks like this:

Code:
-std=c11 -g -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wconversion -I$(IDIR) -D_POSIX_SOURCE
Once code runs clear I then run valgrind on an executable - writing tests if the code is library code. valgring can find more then memory leaks.

Code:
 valgrind --track-origins=yes --leak-check=full
My belief is that since C allows so much flexibility compiler warnings are our best friends and I'm not satisfied until they clear.
 
2 members found this post helpful.
Old 01-13-2020, 09:11 AM   #4
rtmistler
Moderator
 
Registered: Mar 2011
Location: USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu, Debian
Posts: 8,455
Blog Entries: 13

Rep: Reputation: 3773Reputation: 3773Reputation: 3773Reputation: 3773Reputation: 3773Reputation: 3773Reputation: 3773Reputation: 3773Reputation: 3773Reputation: 3773Reputation: 3773
Personally I put in as many compiler switches as I can to catch warnings and I also treat them as errors so that the build fails.

And would prefer to maintain this in work code.

Boughtonp has several good points about the authors, long term maintenance, inheriting code bases, etc.

I will also add that if you purchase code from a company, such as a software stack, or algorithm, the same applies. There can be warnings and then you're inheriting them. Many of the vendors do strive to ensure that they do not have them, and are also responsive if you report finding them, or other bugs. To summarize there: If the vendor is not responsive, does not take you seriously, this tells you something about how professional they are and how serious they are at selling software source.

In my workplace, we have several tools, astyle and Klocwork are some of them, which we use to check our code as we perform continuous integration.

I can say that with the several consumer products and their various software builds which I do work with, we have no warnings, they are not allowed.

Meanwhile, nobody outside of our organization would know this, because they are not building our code, only we are doing that.

I can't speak for Linux package compilations, except to agree with you that there are warnings when there shouldn't be.

Here's my current list, but I haven't revised it in a few years:
Code:
-O0 // This sets optimization off, not a forever recommendation, use selectively
-ggdb // This compiles for GDB debugging capabilities
-Wformat=2
-Werror
-Wall
-Wextra
-Wswitch-default
-Wswitch-enum
-Wstrict-prototypes
-Wmissing-prototypes
-Wmissing-declarations
-Wmissing-noreturn
 
Old 01-13-2020, 09:17 AM   #5
hazel
Senior Member
 
Registered: Mar 2016
Location: Harrow, UK
Distribution: LFS, AntiX, Slackware, OpenBSD
Posts: 4,069

Original Poster
Blog Entries: 11

Rep: Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245
I was talking about all those packages that go to make up Linux. I've never built any commercial software, but I've been building and using LFS/BLFS for years. Before that, I used Crux, which is source-based. There are always loads of warnings in those packages. Why is that?
 
Old 01-13-2020, 10:22 AM   #6
pan64
LQ Guru
 
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 13,622

Rep: Reputation: 4369Reputation: 4369Reputation: 4369Reputation: 4369Reputation: 4369Reputation: 4369Reputation: 4369Reputation: 4369Reputation: 4369Reputation: 4369Reputation: 4369
You can write almost anything in C. Most of them can be compiled and executed. Warnings mean some kind of "illogical" programming or contravention of some "natural" rules.
Usually these warnings means incorrect logic or improper handling of variables/structs/whatever, but allowed, still can be compiled and executed.
The syntax checker tries to find all of these problems. Sometimes the programmer really knows if the reported issue was a false positive and ignored. Sometimes we know the program is working well, nobody will modify anything just for eliminating those warnings. Sometimes we inherit a piece of code from somewhere and don't want to alter it at all.
Oh yes, additionally new compilers will give more warnings....

Last edited by pan64; 01-13-2020 at 10:35 AM.
 
Old 01-14-2020, 07:57 PM   #7
Geist
Member
 
Registered: Jul 2013
Distribution: Slackware 14 / current
Posts: 367

Rep: Reputation: Disabled
It's like drawing anime or cartoons, only not like drawing anime or cartoons, at all.
You do live drawings, realistic, studies of the anatomy, bones, fat, etc.

And once you know those rules, you bend them into style.

But that's comparing apples and oranges since programming is logical and art is subjective, but both also deal with breaking of rules.
It can be deliberate.

The C64 for example thrived from exploits and tricks not immediately intended by the engineers. I mean, one version of the sound chip had a flaw where every time a filter was changed, a click was produced.
This click was exploited to generate waveforms/pcm playback despite the chip not having that.
(Note,details might be sketchy of my retelling, but its a fact that one version of the SID was exploited for that effect.)

So even something revolutionary might come from flipping the compiler (or hardware) the bird, not just "oh the software had to be shipped or we'd have lost our heads" or other such things.
Jaywalking is also great, entire road free of traffic? It's a bad move and you'd be warned to not do it cause it's frowned upon or maybe even carry a fine but...there's no danger right now.

Oh yeah, I think "the fastest possible delegates in C++" from some long time ago I think were created by not adhering to strict standards, too and probably many, many other things.

Last edited by Geist; 01-14-2020 at 08:01 PM.
 
Old 01-15-2020, 06:48 AM   #8
hazel
Senior Member
 
Registered: Mar 2016
Location: Harrow, UK
Distribution: LFS, AntiX, Slackware, OpenBSD
Posts: 4,069

Original Poster
Blog Entries: 11

Rep: Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245Reputation: 2245
Meaning that people like me must program correctly but longtime hackers can break the rules if they like because they know how to get away with it.
 
Old 01-15-2020, 07:00 AM   #9
pan64
LQ Guru
 
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 13,622

Rep: Reputation: 4369Reputation: 4369Reputation: 4369Reputation: 4369Reputation: 4369Reputation: 4369Reputation: 4369Reputation: 4369Reputation: 4369Reputation: 4369Reputation: 4369
not really. Meaning you can break those rules if you know [what are you doing] better than the team who implemented the compiler.
 
Old 01-15-2020, 09:18 AM   #10
SoftSprocket
Member
 
Registered: Nov 2014
Posts: 220

Rep: Reputation: Disabled
I would guess the number of times when expertise above and beyond explains a large number of warnings is rare. Excepting legacy code I would say, for the few times breaking the rules is required, an "expert hacker" might also know a pragma that can quiet the warning. In any event I don't expect the large number of warnings found in some code bases to be a result of that.

I'm grateful for warnings when the compiler reminds me that this:
Code:
 
size_t s_len = strlen (str);
...
for (int i = s_len; i >= 0; --i)
Is going to spin its wheels forever. It's a trivial example but errors hidden in endless warnings hide such things.
 
Old 01-15-2020, 12:00 PM   #11
rtmistler
Moderator
 
Registered: Mar 2011
Location: USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu, Debian
Posts: 8,455
Blog Entries: 13

Rep: Reputation: 3773Reputation: 3773Reputation: 3773Reputation: 3773Reputation: 3773Reputation: 3773Reputation: 3773Reputation: 3773Reputation: 3773Reputation: 3773Reputation: 3773
Quote:
Originally Posted by hazel View Post
Meaning that people like me must program correctly but longtime hackers can break the rules if they like because they know how to get away with it.
The only formal rules are the syntax of the language, but they are not draconian as you're seeing, there are true errors from compiling and there are warnings.

I'd prefer that it not be treated as "people like me" concept. I can't control what anyone else thinks, but I do not feel it should be classified as anything like novices, experts, intermediates, and etc. We're all programmers of some type, talent, and experience, however it has been plainly shown that there are plenty of programmers with extensive experience who are ignoring warnings and perpetuating that versus doing something about it.

I know you were talking about Linux source distributions and packages. I absolutely cannot speak for the authors and maintainers of those.

My experiences as cited have been commercial and while things have gotten better, there clearly were, and continue to be times where the whole code base is h$%# in a handbasket, there seem to be elusive bugs in a variety of locations, one team is accusing another, or things like this. Some voice of sanity says, "Well, we're going to fix this!" And they're high enough of authority that they win. As part of that, the fact that there are xxxx warnings becomes an issue and there's a global effort to reduce/eliminate them, and see that more are not introduced. Meanwhile, it's always been about delivery, there's always one or two that came from source we bought and it doesn't seem to be correct to fix those because when we update their code, it'll be repeated, so we try to speak to the vendor of the software, or things like that.

it's not a perfect world.

Think of other situations in the world where things are allowed to be sloppy. Hopefully it is not a catastrophic failure, like the O-rings on the US Space Shuttle, but obviously that is an example of a very large integrations effort which failed somewhere and allowed a critically dangerous situation to exist. Once all the circumstances lined up to allow that failure to occur, it obviously did so at the worst possible time. But when people are delivering new commercial product software, priorities can be conflicted.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: GVFS 1.16.1 Fixes Compiler Warnings and Other Issues LXer Syndicated Linux News 0 04-29-2013 11:51 PM
Beginning C programming- stuck on trivial program (compiler warnings) keithostertag Programming 18 02-12-2012 04:21 AM
problem with compiler warnings rheosiva Linux - Kernel 4 06-05-2009 07:24 AM
LXer: Linux: Compiler Warnings LXer Syndicated Linux News 0 05-24-2007 10:01 PM
java compiler warnings exodist Programming 2 05-09-2004 02:42 AM

LinuxQuestions.org > Forums > Non-*NIX Forums > Programming

All times are GMT -5. The time now is 05:22 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration