Tips from the compiler

Nick Sabalausky a at a.a
Sun Oct 17 22:00:34 PDT 2010



-- 

-------------------------------
Not sent from an iPhone.

"Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
news:mailman.685.1287377033.858.digitalmars-d at puremagic.com...
> On Sunday 17 October 2010 19:40:36 bearophile wrote:
>> In Bugzilla I have some compiler messages that don't fit in the set of
>> error messages nor in the set of normal warnings. Like:
>> http://d.puremagic.com/issues/show_bug.cgi?id=5056
>>
>> So I have proposed a third kind of compiler message, that are
>> tips/suggestions to avoid possible bugs, improve the shape or performance
>> of the code, and so on. The compiler shows those tips only on request.
>>
>> My usage of C lints has shown me that such tips sometimes are very useful
>> to avoid coding pitfalls, etc.
>>
>> Here you may see some simple example of compiler tips from the 
>> CommonLips,
>> that the compiler shows only when the higher optimization levels are 
>> used:
>> http://shootout.alioth.debian.org/u32/program.php?test=mandelbrot&lang=sbc
>> l&id=1
>>
>> Bye,
>> bearophile
>
> I think that what we should really look at doing is to have either dmd or 
> some
> other tool built on dmd's front-end be able to do lint-like examination of
> source code (if it were dmd itself rather than an external tool, it would 
> be a
> flag which presumably did that only rather than compile your code). That 
> way, all
> of the various warning and error messages that you and others keep coming 
> up
> with but will never end up in dmd can be put in there. That tool could 
> provide a
> way to find all of the weird, stray cases that could result in errors, and 
> anyone
> who wants to examine their code on that level could use it. Then we 
> wouldn't
> have all of these potential warnings sitting around which Walter will 
> never put
> into dmd.
>
> And honestly, I think that things like dangling else, unused variables, 
> and
> redundant code make a lot more sense it a tool that is looking for 
> potential
> programming errors rather than the compiler. It's the compiler's job to
> correctly generate the code that it's given, not worry about all of the 
> possible
> ways that the programmer could have screwed up when they wrote the code.
>
> - Jonathan M Davis

The problem I've always seen with lint tools is you have two choices: A. Run 
them occasionally, or B. Set up the build system to run them on every 
compile. So:

If you do A, you minimize the usefulness because you're not informed of 
potential issues until likely well after they've been introduced into the 
code.

If you do B, then you may as well just have them built right into the 
compiler. And, in fact, outside of planet Mars, that's what's done: We call 
them "warnings".




More information about the Digitalmars-d mailing list