July 09, 2008
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
"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
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
"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
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
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
"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
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
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
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.