July 10, 2008
On Thu, 10 Jul 2008 10:01:25 +0100, Manfred_Nowak <svv1999@hotmail.com> wrote:

> JAnderson wrote:
>
>> The more warnings as errors the better.  If I have to suffer a
>> little for false positives *shrug*
>
> What do you understand by "a little"?
>
> Please look at the example from
> http://www.digitalmars.com/webnews/newsgroups.php?
> art_group=digitalmars.D&article_id=73441
>
> Do you recognize how many warnings a lint tool might emit on that code?
> Would you admit then, that a paranoic lint would be quite useless, even
> if it detects that the variable `p' should be accessed? Would you
> admit, that you yourself are unable to decide whether the presence of
> some access statements to `p' should suppress the warning?

Generally there are two types of code. Code for which warnings are allowed
and warning free code. Transitioning from code that's been allowed to have warnings
for a long time to warning free code takes effort. I still think the long
term benefits make it worth it.

> My understanding of lint tools is, that they incorporate a collection
> of programming patterns together with a fuzzy recognition algorithm. If
> there are enough hits for a specific pattern, but it is still only
> partial implemented, then warnings are generated. Under this the
> primary question is: what is so special to the collection of
> programming patterns that they can be formalized into a lint tool but
> not be used as paradigms in the source language?
>
> -manfred
>
The reason is that the language specification is low level. It tells you how you
are allowed to put bricks together. Static analysis tools work at a much higher
level. They say things like, this is a load bearing wall putting a door here without a
lintal (pardon the pun) is unwise.
Semantic checks rely on trying to work out what your code is trying to do, its not just
following the steps to needed execute it (with certain exceptions).

Regards,

Bruce.
July 10, 2008
Nick Sabalausky Wrote:

> As just a few examples: http://www.digitalmars.com/d/1.0/warnings.html

yarp i'm so happy you sent those. let's take'em 1 by 1. please let me know agree or disagree.

1. warning - implicit conversion of expression expr of type type to type can cause loss of data

it's a shame this is allowed at all. any conversion that involves a loss must require a cast right there. as far as the example give goes:

byte a, b;
byte c = a + b;

compiler can't know a + b is in byte range so a cast is good. but take this now:

byte c = a & b;

in this case the compiler must accept code. so what i'm saying is that better operator types will help a ton.

2. warning - array 'length' hides other 'length' name in outer scope

i seem to recall andrei pissed on this one until it dissolved into the fucking ground. can't agree more. it is a crying shame that this stupid length thing is still in the language. just get rid of it already.

3. warning - no return at end of function

now what a sick decision was it to accept that in the first place. an overwhelming percentage of functions *can* and *will* be written to have a meaningful return at the end. then why the fuck cater for the minority and hurt everybody else. just require a return or throw and call it a day. people who can't return something meaningful can just put a throw. code growth is negligible. impact on speed is virtually nil. why the hell do we even bother arguing over it.

4. warning - switch statement has no default

another example of a motherfuck. just require total coverage. in closed-set cases i routinely write anyway:

switch (crap)
{
case a: ...; break;
case b: ...; break;
default: assert(crap == c): ...; break;
}

again: vast majority of code already has a default. the minority just has to add a little code. make it an error.

5. warning - statement is not reachable

this is a tad more messy. people routinely insert a premature return in there to check for stuff. it pisses me off when that won't compile. i discovered i could do this:

if (true) return crap;

that takes care of the error. and i think it's actually good for me because it really is supposed to be temporary code. it jumps at me in a review. as it should.
July 10, 2008
On Thu, 10 Jul 2008 14:55:49 -0400, Nick Sabalausky wrote:

> I'm not sure I see the need for as many as four warning levels (though I suppose I could be convinced given an appropriate argument), but something like this sounds ideal to me:
> 
> - enable typically-useful warnings
> - enable anally-retentive, only sometimes-helpful, warnings
> 
> - treat typically-useful warnings as errors - treat all warnings as errors

What I think is that the basic compiler needs following:

- A set of warnings, that usually indicate bugs in the code and are relatively easy to circumvent (like unused vars and such), but which may be looked to be at least some sort frequent things while sketching software

- Basically two warning levels: either to generate code while there are warnings, or not generate code (treating them errors)

Suppressing the output of warnings? Why? What use? If you are not going to correct the warnings in your code when completing it, why you then even read the output of the compiler (if the code is generated)? Closing eyes does not make the things behind the warnings to go away :)

Then, when dealing with larger software and looking for good places for refactoring, there could be an external "anally-retentive" lint-like tool :)
July 10, 2008
On Thu, 10 Jul 2008 15:20:54 -0400, Nick Sabalausky wrote:

About that "warnings as errors"; for me the reason for that behavior is that I usually include executing the code to the command line when coding (and use up arrow to rerun it, if the compiler didn't accept my code):

$ make && ./myProgram

If the compiler does not stop for warnings, I'd need some sort of build log to examine the warnings after execution. But if the compiler returns error value (like -1) when meeting warnings, the program was not executed and I can easily examine the reasons.

This same happens of course with IDEs, when using "Run" instead of first compiling/building the software.

> Also, while I
> can't confirm or deny this at the moment, someone here said that -w
> compiles currently halt at the first warning.

No, it shows all warnings it generates. But IMO it does not generate enough warnings.
July 10, 2008
Walter Bright, el  9 de julio a las 13:41 me escribiste:
> Piping the output into a file and then perusing it manually looking for warning statements is never going to happen.

I code using VIM. VIM has a very convenient feature that recolects the make (compiler output) and let you you iterate over warnings/errors (using :cn, and :cp). So yes. It's going to happen. It happens all the time.

And I think most decent IDEs/Editor do that, so it's not something VIM-specific.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Me duele encontrarte en mis sueños muertos
July 10, 2008
Leandro Lucarella wrote:
> Walter Bright, el  9 de julio a las 13:41 me escribiste:
>> Piping the output into a file and then perusing it manually looking for warning statements is never going to happen.
> 
> I code using VIM. VIM has a very convenient feature that recolects the
> make (compiler output) and let you you iterate over warnings/errors (using
> :cn, and :cp). So yes. It's going to happen. It happens all the time.
> 
> And I think most decent IDEs/Editor do that, so it's not something
> VIM-specific.

Emacs has it too!  M-x `

--bb
July 11, 2008
"Markus Koskimies" <markus@reaaliaika.net> wrote in message news:g55tmb$1h9i$17@digitalmars.com...
> On Thu, 10 Jul 2008 14:55:49 -0400, Nick Sabalausky wrote:
>
>> I'm not sure I see the need for as many as four warning levels (though I suppose I could be convinced given an appropriate argument), but something like this sounds ideal to me:
>>
>> - enable typically-useful warnings
>> - enable anally-retentive, only sometimes-helpful, warnings
>>
>> - treat typically-useful warnings as errors - treat all warnings as errors
>
> What I think is that the basic compiler needs following:
>
> - A set of warnings, that usually indicate bugs in the code and are relatively easy to circumvent (like unused vars and such), but which may be looked to be at least some sort frequent things while sketching software
>
> - Basically two warning levels: either to generate code while there are warnings, or not generate code (treating them errors)
>
> Suppressing the output of warnings? Why? What use? If you are not going to correct the warnings in your code when completing it, why you then even read the output of the compiler (if the code is generated)? Closing eyes does not make the things behind the warnings to go away :)
>
> Then, when dealing with larger software and looking for good places for refactoring, there could be an external "anally-retentive" lint-like tool :)

You've convinced me :)


July 11, 2008
"Markus Koskimies" <markus@reaaliaika.net> wrote in message news:g55u4d$1h9i$18@digitalmars.com...
> On Thu, 10 Jul 2008 15:20:54 -0400, Nick Sabalausky wrote:
>
> About that "warnings as errors"; for me the reason for that behavior is that I usually include executing the code to the command line when coding (and use up arrow to rerun it, if the compiler didn't accept my code):
>
> $ make && ./myProgram
>
> If the compiler does not stop for warnings, I'd need some sort of build log to examine the warnings after execution. But if the compiler returns error value (like -1) when meeting warnings, the program was not executed and I can easily examine the reasons.
>
> This same happens of course with IDEs, when using "Run" instead of first compiling/building the software.
>
>> Also, while I
>> can't confirm or deny this at the moment, someone here said that -w
>> compiles currently halt at the first warning.
>
> No, it shows all warnings it generates. But IMO it does not generate enough warnings.

I suppose I should point out that I have nothing against treating warnings as errors, per se. I just think it should be optional and not forced by the compiler to be either "always treated as errors and there's nothing you can do about it" or "never treated as errors and there's nothing you can do about it"


July 11, 2008
"Bill Baxter" <dnewsgroup@billbaxter.com> wrote in message news:g561hh$2g6g$2@digitalmars.com...
> Leandro Lucarella wrote:
>> Walter Bright, el  9 de julio a las 13:41 me escribiste:
>>> Piping the output into a file and then perusing it manually looking for warning statements is never going to happen.
>>
>> I code using VIM. VIM has a very convenient feature that recolects the
>> make (compiler output) and let you you iterate over warnings/errors
>> (using
>> :cn, and :cp). So yes. It's going to happen. It happens all the time.
>>
>> And I think most decent IDEs/Editor do that, so it's not something VIM-specific.
>
> Emacs has it too!  M-x `
>

Every IDE I've ever used does it. And I'm constantly IDE-hopping.


July 11, 2008
On Thu, 10 Jul 2008 20:28:53 -0400, Nick Sabalausky wrote:

> I suppose I should point out that I have nothing against treating warnings as errors, per se. I just think it should be optional and not forced by the compiler to be either "always treated as errors and there's nothing you can do about it" or "never treated as errors and there's nothing you can do about it"

Honestly,

(1) I was using D compiler happily for some years and I thought that it generates warnings just like other compilers do. I was shocked to recognize, that it really does not do that.

(2) I realized that there is some kind of fundamentalist ideology not to produce warnings from compiler (that's extremely silly from my point of view); that's why I suggested, that combining the current D possibilities it would really make no big difference to treat warnings as errors (since it seems, that it is more likely to get errors to the compiler, not warnings),

(3) From the point of both programmer, and compiler designer, I see
absolutely no point not generating warnings, when the compiler knows it
has done something probably silly. The more optimizations the compiler
does, the more aware it is about the source code. What v*#p%&"/(¤ %&#s¤/&/
# %¤yh&/&/"&/&# %&/#¤ (*) is the sole reason not to show the analysis
compiler has already made (about unused vars, private methods, dead code,
unused imports etc. etc).

---
(*) Those are Finnish swearing words, that does not compile to English. You may use "f**k" for every character ;)