View mode: basic / threaded / horizontal-split · Log in · Help
July 09, 2008
Re: Wish: Variable Not Used Warning
Reply to Bill,

> BCS wrote:
> 
>> Reply to tomD,
>> 
>>> BCS Wrote:
>>> [...]
>>>> I think grep is more useful there. I have a few builds that have
>>>> several pages of output on a successful build and I sometimes miss
>>>> even the errors.
>>>> 
>>>> (I once had an error that didn't even fit in the scroll back
>>>> buffer, but that was just a bit nuts ;)
>>>> 
>>> That's why I think having a "tee" is even better :-) Anyway, you
>>> cannot do anything useful under Windows unless it is in a Cygwin
>>> bash...
>>> 
>> <sarcastic>No? You can't?!</sarcastic> <G/>
>> 
>> Your right and Oooh do i feel it now and again.
>> 
> I agree Cygwin is nice, but go get yourself the gnuwin32 tools.  Then
> you'll be able to use all your favorite unix commands (like 'tee')
> from the dos box.  Makes it much less painful.  And get Console2 also.
> 
> --bb
> 

six of one half dozon of the other just Give Me My Linux CLI Tools!
July 09, 2008
Re: Wish: Variable Not Used Warning
"superdan" wrote
> Steven Schveighoffer Wrote:
>
>> "Walter Bright" wrote
>> > The reason for treating warnings as errors when warnings are enabled is 
>> > so
>> > that, for a long build, they don't scroll up and off your screen and go
>> > unnoticed.
>>
>> I've been following this thread, and I'm not really sure which side of 
>> the
>> issue I'm on, but this, sir, is one of the worst explanations for a 
>> feature.
>> Ever heard of 'less'?  or 'more' on Windows?  Maybe piping to a file? 
>> Maybe
>> using an IDE that stores all the warnings/errors for you?
>>
>> Please stop saving poor Mr. ignorant programmer from himself.  Education 
>> is
>> the key to solving this problem, not catering to the ignorance.
>>
>> Sorry for the harshness, but seriously!
>
> in c++ this kind of argument that contains "it's an issue of education and 
> shit" in it has been used for many years. after a lot of experience in the 
> field nowadays everyone silently agrees that that argument is useless. 
> folks on comp.lang.c++ start mocking you if u bring that argument up.
>
> i am 110% on walter's side on this shit. there should be no warnings and 
> shit. only errors. it is not catering to the ignorant. it is a matter of a 
> properly defined language.

I think you missed my point.  Walter's position on warnings being errors 
(mind you, not by default, only when the -w (show me the warnings) switch is 
applied) is that people run out of screen space.  To me, that's just plain 
silly as an argument.  If you're gonna have warnings, which aren't 
considered errors by default, at least have it possible to configure so the 
compiler doesn't error out on the 1st warning.

By education I mean, tell the ignorant programmer how to use his shell to 
pipe the warnings into a paged format, or to a file, or whatever.  Don't 
hinder the knowlegable programmers who want to have everything at once.

Regarding whether warnings should be in a lint tool or not, I'm undecided on 
the issue, as I have been hit by both sides (too many useless warnings, or 
gee it would have been nice for the compiler to tell me I did this wrong).

-Steve
July 09, 2008
Re: Wish: Variable Not Used Warning
Steven Schveighoffer Wrote:

> "superdan" wrote
> > Steven Schveighoffer Wrote:
> >
> >> "Walter Bright" wrote
> >> > The reason for treating warnings as errors when warnings are enabled is 
> >> > so
> >> > that, for a long build, they don't scroll up and off your screen and go
> >> > unnoticed.
> >>
> >> I've been following this thread, and I'm not really sure which side of 
> >> the
> >> issue I'm on, but this, sir, is one of the worst explanations for a 
> >> feature.
> >> Ever heard of 'less'?  or 'more' on Windows?  Maybe piping to a file? 
> >> Maybe
> >> using an IDE that stores all the warnings/errors for you?
> >>
> >> Please stop saving poor Mr. ignorant programmer from himself.  Education 
> >> is
> >> the key to solving this problem, not catering to the ignorance.
> >>
> >> Sorry for the harshness, but seriously!
> >
> > in c++ this kind of argument that contains "it's an issue of education and 
> > shit" in it has been used for many years. after a lot of experience in the 
> > field nowadays everyone silently agrees that that argument is useless. 
> > folks on comp.lang.c++ start mocking you if u bring that argument up.
> >
> > i am 110% on walter's side on this shit. there should be no warnings and 
> > shit. only errors. it is not catering to the ignorant. it is a matter of a 
> > properly defined language.
> 
> I think you missed my point.  Walter's position on warnings being errors 
> (mind you, not by default, only when the -w (show me the warnings) switch is 
> applied) is that people run out of screen space.  To me, that's just plain 
> silly as an argument.  If you're gonna have warnings, which aren't 
> considered errors by default, at least have it possible to configure so the 
> compiler doesn't error out on the 1st warning.

yarp i also didn't exactly get high on walter's argument. 

> By education I mean, tell the ignorant programmer how to use his shell to 
> pipe the warnings into a paged format, or to a file, or whatever.  Don't 
> hinder the knowlegable programmers who want to have everything at once.

fair enough. by the way i'm of with that gun zealot (what's his name) that good shit should output exactly nothing on success.

> Regarding whether warnings should be in a lint tool or not, I'm undecided on 
> the issue, as I have been hit by both sides (too many useless warnings, or 
> gee it would have been nice for the compiler to tell me I did this wrong).

that's a good argument that there should be no two ways about it.

walter, make all warnings errors without -w and get rid of -w.
July 09, 2008
Re: Wish: Variable Not Used Warning
"superdan" <super@dan.org> wrote in message 
news:g53831$20jk$1@digitalmars.com...
> Steven Schveighoffer Wrote:
>
>> "Walter Bright" wrote
>> > The reason for treating warnings as errors when warnings are enabled is 
>> > so
>> > that, for a long build, they don't scroll up and off your screen and go
>> > unnoticed.
>>
>> I've been following this thread, and I'm not really sure which side of 
>> the
>> issue I'm on, but this, sir, is one of the worst explanations for a 
>> feature.
>> Ever heard of 'less'?  or 'more' on Windows?  Maybe piping to a file? 
>> Maybe
>> using an IDE that stores all the warnings/errors for you?
>>
>> Please stop saving poor Mr. ignorant programmer from himself.  Education 
>> is
>> the key to solving this problem, not catering to the ignorance.
>>
>> Sorry for the harshness, but seriously!
>
> in c++ this kind of argument that contains "it's an issue of education and 
> shit" in it has been used for many years. after a lot of experience in the 
> field nowadays everyone silently agrees that that argument is useless. 
> folks on comp.lang.c++ start mocking you if u bring that argument up.
>

That's probably because over the past ten years, the people who care more 
about doing things the right way than catering to the status quo have been 
leaving C++ en masse (hence, D). It's no surprise that the people still 
remaining onboard C++ are either A. people who hold that particular 
viewpoint or B. people who are required to use C++ for some reason and have 
long since gotten used to the fact that C++ is never going to fix most of 
its problems. So I wouldn't place too much weight on the "comp.lang.c++" 
take on this particular issue; their consensus is likely just a reflection 
of group dynamics.

> i am 110% on walter's side on this shit. there should be no warnings and 
> shit. only errors. it is not catering to the ignorant. it is a matter of a 
> properly defined language.
>

That's right, no true warnings, but just a handful of what are in effect 
"optional errors".

In a "properly defined language", how would you solve the problem of 
unintentionally-unused variables?

Adopt the "unused" keyword that Koroskin Denis proposed and say that an 
unused var without the unused keyword is an error, and accessing a var that 
does have the unused keyword is also an error? That sounded good to me at 
first but then I realized: What happens when you're in the middle of an 
implementation and you stick the "unused" keyword on a variable in a 
function that you've only partially implemented just because you want to 
test the partial implementation. Then you fix any problems, get distracted 
by something else, and forget to finish (it happens more than you may 
think). Well great, now that wonderful compiles/errors dichotomy has just 
*created* a hole for that bug to slip in, whereas a real warning (the true 
kind, not the "warnings as errors" kind) would have caught it.

So how else could a "properly defined language" solve it? Just simply treat 
it as a non-error as it is now and be done with it? That turns 
potentially-noisy errors into silent errors which is one of the biggest 
design mistakes of all.

Any other suggestions on how to "properly design" a fix for that? If it 
works, I'd be all for it.

Suppose that does get fixed. Now, when some other common gotcha is 
discovered in a language, or a particular version of a language, that's had 
a design freeze (like D1), then what do you do? Stick to your "warnings are 
bad" guns and just leave everyone tripping over the gotcha in the dark, 
maybe hoping that someone else could come along and create a lint tool that 
would do the job that you could have already done?

Designing everything to fit into a compiles/errors dichotomy is great, in 
theory. But in practice it's just unrealistic. Even Walter ended up having 
to add a few "warnings" to D (even if he implemented them more as optional 
errors than as true warnings). Which is why, as I was saying in the 
beginning, trying to eliminate the need for a specific warning is great - 
*if* it actually pans out. But that doesn't always happen.

> a lint tool should not be folded into d. such a tool could e.g. follow 
> pointers, do virtual execution, and some other weird shit. it could run 
> for hours and produce output that takes an expert to interpret. that kind 
> of shit does not belong in the compiler.

Anything like that can be attached to an optional command-line parameter 
that defaults to "off". Problem solved.
July 09, 2008
Re: Wish: Variable Not Used Warning
Walter Bright wrote:
> Nick Sabalausky wrote:
>> "Walter Bright" <newshound1@digitalmars.com> wrote in message 
>> news:g530j8$18th$1@digitalmars.com...
>>> The reason for treating warnings as errors when warnings are enabled 
>>> is so that, for a long build, they don't scroll up and off your 
>>> screen and go unnoticed.
>>
>> Pardon me for saying so, but that doesn't sound like a very convincing 
>> reason to turn every warning (which, by it's very nature, is something 
>> that might not be a bug) into something that splits the language into 
>> what are effectively different languages.
> 
> I'll draw on my 25 years of experience with warnings to answer this.
> 
> If you turn warnings on, then you want to see them and presumably deal 
> with them. If you don't deal with them, then they persist every time you 
> compile, and either they get very irritating and you fix them anyway, or 
> you develop a blind spot for them and never see the ones you do want to 
> fix.

This is true.  However, warnings are often related to code structure and 
the compiler isn't perfect at identifying real problems... and code 
changes to work around deficiencies in the checking tool aren't always 
appealing.  For example, there is a file in the GC code, if I remember 
correctly, that doesn't compile correctly with warnings enabled because 
it uses a goto or some such that confuses the compiler about what's 
going on.  If this were C++ I might be inclined to pragma out that 
particular warning for the area where the warning is displayed.

Another issue is with third-party libraries.  I always compile my code 
with the strictest warning settings, yet some of the libraries I use 
aren't so careful.  With them, the easiest thing to do it often to 
assume that they work correctly despite the warnings and disable warning 
messages for the relevant headers.

> Piping the output into a file and then perusing it manually looking for 
> warning statements is never going to happen. Complex builds tend to 
> produce a lot of output, and poking through it looking for warnings 
> every time you build is not practical. Changing your build process to 
> point out warnings is the same thing as the compiler treating them as 
> errors, except it's extra work for the build master.

It isn't practical to do so for every build, but it's not uncommon for a 
team to set aside some time to address warnings in bulk, say between 
releases.

> Trying to educate your programmers into doing extra work to deal with 
> warnings that scroll off the screen is a lost cause.
> 
> If you're using a static analysis tool, such as Coverity, which produces 
> lots of spurious warnings, it is not put in the build process. It's run 
> occasionally as a separate evaluation tool.

That's certainly an option, and probably a preferable one overall.


Sean
July 09, 2008
Re: Wish: Variable Not Used Warning
On Tue, 08 Jul 2008 14:40:26 -0700, Walter Bright  
<newshound1@digitalmars.com> wrote:

> Nick Sabalausky wrote:
>> Ok, so the different warnings should be able to be turned on and off.  
>> If you don't agree with a particular type of warning then you turn it  
>> off. That's the nice thing about warnings as opposed to errors: they're  
>> optionally letting you know about certain conditions that you might  
>> want to be aware of, and they do it without changing, redefining, or  
>> otherwise affecting the language itself.
>
> That situation exists today for C++ compilers, and it's not so good. You  
> have, as I mentioned previously, n factorial different languages instead  
> of 1. Portability becomes a problem. Confusion about whether the code  
> should compile or not reigns.
>
>>> If it was in the compiler, it would inhibit development of static  
>>> analysis tools,
>> Can you elaborate on how this would happen?
>
> It's the same reason why "m4" never caught on as a C preprocessor,  
> despite being vastly superior, and despite everyone who wanted a better  
> CPP being told to use m4.
>
>
>>> and would confuse the issue of what was correct D code.
>>  Anything that generates a warning instead of an error is by definition  
>> valid code. If it wasn't valid it would generate an error instead of a  
>> warning.
>
> That's true, but it is not what happens in the real world with warnings.  
> I've dealt with warnings on C/C++ compilers for 25 years, and the  
> practice is very different from the theory.

I agree with Walter. One of the driving forces behind D was a desire *not*  
to have the quirks, corners and obscurities that grew within C++ over the  
years because Stroustrup wanted full backwards compatibility with C, etc.  
I want a compiler that says *this* is legal D, *that* is not, and there's  
an end on it.

I *also* want a tool (or sheaf of tools, smart editor, etc.) that will do  
lint-like static analysis and style vetting to warn me that, yes, this is  
legal D but you're using it in an obscure or unmaintainable or not easily  
extensible or not easily understood manner.  
_But_I_don't_want_that_tool_to_be_the_compiler_!

Walter is right that you end up with effectively 2**n different languages  
depending, not only on which warnings you enable|disable, but also on  
whether the shop you work for demands that you compile at /W1 or /W3 or  
/W4 and does or doesn't treat warnings as errors.

Yes, having the full parse tree available makes it easier to find some  
(not all) of those sorts of... not "errors", call them "infelicities". So  
compiler writers have tried to be generous and give their users more  
information "for free", and by doing so have made IMHO a design error. It  
is exactly analogous to overloading an operator with functionality that  
doesn't properly apply to that operation. You're trying to do too much  
with one tool.

I applaud Walter for not making that error. And I want him focused on  
writing a knife-clean compiler that stabs illegal code in the heart, and  
trusts the programmer to have meant what he said when the code is legal,  
even if it's "excessively clever".

Let someone *else* write "Clippy for D".

-- Dai
July 09, 2008
Re: Wish: Variable Not Used Warning
"Walter Bright" <newshound1@digitalmars.com> wrote in message 
news:g537q0$1vi0$1@digitalmars.com...
> Nick Sabalausky wrote:
>> "Walter Bright" <newshound1@digitalmars.com> wrote in message 
>> news:g530j8$18th$1@digitalmars.com...
>>> The reason for treating warnings as errors when warnings are enabled is 
>>> so that, for a long build, they don't scroll up and off your screen and 
>>> go unnoticed.
>>
>> Pardon me for saying so, but that doesn't sound like a very convincing 
>> reason to turn every warning (which, by it's very nature, is something 
>> that might not be a bug) into something that splits the language into 
>> what are effectively different languages.
>
> I'll draw on my 25 years of experience with warnings to answer this.
>
> If you turn warnings on, then you want to see them and presumably deal 
> with them. If you don't deal with them, then they persist every time you 
> compile, and either they get very irritating and you fix them anyway, or 
> you develop a blind spot for them and never see the ones you do want to 
> fix.
>

First of all, if you don't want to deal with warnings, then along with what 
you said, you presumably wouldn't have turned them on in the first place. So 
I'm not sure you'd be developing a blind spot (unless you're being required 
to use them, which goes back to the management discussion).

Aside from that, I'll fully agree that cerain warnings can get annoying and 
eventually overlooked, *if* you're using a language like C/C++ that has 
accumulated decades of warnings that resulted from design issues that could 
have been fixed by a design change but never were simply because maintaining 
full backwards compatibility (across all those years) was considered more 
important than never fixing a problem properly. D's not really in that boat. 
But even if it did end up in that boat someday, I'd much rather have the 
*chance* of not noticing a particular warning, than be guaranteed never to 
notice it simply because it was decided not to even offer the warning out of 
fear that it might get ignored.

> Piping the output into a file and then perusing it manually looking for 
> warning statements is never going to happen. Complex builds tend to 
> produce a lot of output, and poking through it looking for warnings every 
> time you build is not practical. Changing your build process to point out 
> warnings is the same thing as the compiler treating them as errors, except 
> it's extra work for the build master.
>
> Trying to educate your programmers into doing extra work to deal with 
> warnings that scroll off the screen is a lost cause.
>

I think you misunderstood me. What I was talking about would only involve 
the makers of things like rebuild or make. All we need is a cumulative "x 
errors, x warnings" at the end of the build process. That's enough to let 
people know that there were warnings they should scroll up and look at (if 
they care about warnings in the first place). That would elininate the need 
to always force warnings as errors out of the mere worry that someone might 
not see it because it scrolled away.

And if a so-called "programmer" has a problem looking at the "x errors, x 
warnings" display, then they themselves are already a lost cause, period. I 
don't to have to put up with gimped tools just because some incompetent 
morons are masquerading as real programmers.

> If you're using a static analysis tool, such as Coverity, which produces 
> lots of spurious warnings, it is not put in the build process. It's run 
> occasionally as a separate evaluation tool.

I can agree with that, but with the caveat that I, for one, would at the 
very least choose the most useful subset of those warnings to run during 
each compile.

As an example, the last time I was using ActionScript 1 (ECMAScript without 
any of the improvements from v3 or beyond), I was constantly running into 
problems that a compiler like DMD would have caught (and considered errors) 
but ended up spending half an hour, a full hour, etc, trying to debug. I 
incorporated a JavaScript lint tool into my workflow (ran it every time I 
saved and was about to test something), and it helped immensely. Never gave 
me any problem.

My point is, I *do* want certain warnings to be checked for on every 
compile. Now yes, there can be extra ones that are really anal and only 
occasionally useful. But in a normal setup where warnings are only 
*optionally* treated as errors *and* I can select which warnings I want, 
then those really anal annoying warnings can just be run on occasion, and I 
can still have my more common and highly-useful ones caught right away - 
which is what I want. And I seriously doubt I'm any sort exceptional case by 
feeling that way about it.
July 10, 2008
Re: Wish: Variable Not Used Warning
On Wed, 09 Jul 2008 09:34:30 +0100, Don <nospam@nospam.com.au> wrote:

> Bruce Adams wrote:
>> On Mon, 07 Jul 2008 09:23:15 +0100, Don <nospam@nospam.com.au> wrote:
>>
>>>
>>> I agree. Unfortunately, there's a problem with the 'optional' warnings  
>>> we have in DMD right now. They are not optional for libraries. If a  
>>> library generates warnings, then it is not usable by anyone who wants  
>>> to compile with warnings enabled.
>>>
>>> I'd love to see the warnings tightened up so that they can become bugs.
>>>
>>  That is questionably a flaw in the way D processes libraries. But the  
>> same flaw as in C++.
>
> It's even worse in D, though, because with warnings switched on the  
> library won't compile at all.
>
I was assuming you've already compiled the library with whatever options  
it needs
and you are only parsing the D to import interfaces etc. for your code.

>> If your include file has warnings you have to surpress them when using  
>> the library.
>
> And D has no way to do that.
>
>> Presumably if you use .di files (created/compiled with warnings  
>> switched off) this won't
>> happen?
>
> That's an interesting idea. That might well work.
>
July 10, 2008
Re: Wish: Variable Not Used Warning
On Wed, 09 Jul 2008 09:49:34 +0100, Walter Bright  
<newshound1@digitalmars.com> wrote:

> Here are some horrid examples from my own code which, to please the  
> client, had to compile with all warnings on for MSVC:
>
> ---
>    p = NULL;  // suppress spurious warning
> ---
>    b = NULL;  // Needed for the b->Put() below to shutup a compiler  
> use-without-init warning
> ---
>    #if _MSC_VER
>    // Disable useless warnings about unreferenced formal parameters
>    #pragma warning (disable : 4100)
>    #endif
> ---
>    #define LOG 0       // 0: disable logging, 1: enable it
>
>    #ifdef _MSC_VER
>    #pragma warning(disable: 4127)      // Caused by if (LOG)
>    #endif // _MSC_VER
> ---
>
> Note the uglification this makes for code by forcing useless statements  
> to be added. If I hadn't put in the comments (and comments are often  
> omitted) these things would be a mystery.

I would contend this is a problem with the quality of headers provided by  
M$.
Library code has a greater need to be high quality than regular code.
Operating system APIs even more so.
Removing warnings from C/C++ headers requires you to write them carefully  
to
remove the ambiguity that leads to the warning. That is, this definition of
quality is a measure that increases with decreasing semantic ambiguity.
Asking users of your library code to disable warnings with a #pragma is  
laziness
that a big monopoly like M$ can get away with. Then people wrongly start  
to think
its okay because the big monopoly does it.

Regards,

Bruce.
July 10, 2008
Re: Wish: Variable Not Used Warning
On Wed, 09 Jul 2008 21:41:35 +0100, Walter Bright  
<newshound1@digitalmars.com> wrote:

> Nick Sabalausky wrote:
>> "Walter Bright" <newshound1@digitalmars.com> wrote in message  
>> news:g530j8$18th$1@digitalmars.com...
>>> The reason for treating warnings as errors when warnings are enabled  
>>> is so that, for a long build, they don't scroll up and off your screen  
>>> and go unnoticed.
>>  Pardon me for saying so, but that doesn't sound like a very convincing  
>> reason to turn every warning (which, by it's very nature, is something  
>> that might not be a bug) into something that splits the language into  
>> what are effectively different languages.
>
> I'll draw on my 25 years of experience with warnings to answer this.
>
> If you turn warnings on, then you want to see them and presumably deal  
> with them. If you don't deal with them, then they persist every time you  
> compile, and either they get very irritating and you fix them anyway, or  
> you develop a blind spot for them and never see the ones you do want to  
> fix.
>
> Piping the output into a file and then perusing it manually looking for  
> warning statements is never going to happen. Complex builds tend to  
> produce a lot of output, and poking through it looking for warnings  
> every time you build is not practical. Changing your build process to  
> point out warnings is the same thing as the compiler treating them as  
> errors, except it's extra work for the build master.
>
> Trying to educate your programmers into doing extra work to deal with  
> warnings that scroll off the screen is a lost cause.
>
> If you're using a static analysis tool, such as Coverity, which produces  
> lots of spurious warnings, it is not put in the build process. It's run  
> occasionally as a separate evaluation tool.

Focussing mainly on your last point...
Whenever I work with static analysis tools (I'm talking C++ here obviously)
the first thing I do is to put them into the build process right after the  
compiler.
If you run one just occasionally you will get lost in a sea of spurious  
warnings.
Eliminating warnings and hence the slight possibility of error that goes  
with them
takes effort and that effort can be focussed on problem areas.
You can use a different lint configuration for a different set of files  
and gradually
crank up the quality. If necessary enabling one type of warning for only a  
few files
at a time.
A similar approach is to record the warning count and require that it  
never increases
and occasionally work to lower the limit.
Instead of educating programmers to deal with screen fulls of messages the  
focus should be
on educating them that code quality is important and that removing  
warnings is one way of
improving quality. It is not the be all and end all and not nearly as good  
as say automated
testing. Personally I insist on both wherever I can.

Regards,

Bruce.
3 4 5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home