www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Should we warn if we detect null derefernces or void value uses ?

reply Stefan Koch <uplink.coder googlemail.com> writes:
Hi Guys,
What is your opinion, should we warn if we unambiguously detect 
something that is clearly unwanted ?

int fn(int y)
{
   int x = void;
   ++x;
   return x+y;
}

  This requires data-flow analysis (The same kind that tells you 
if you are skipping a statement)
And will slow down compilation a little if we enable such a 
warning.
Dec 04 2016
next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Monday, 5 December 2016 at 04:41:55 UTC, Stefan Koch wrote:

 And will slow down compilation a little if we enable such a 
 warning.


I have thought it over again. We can make it such that, hit will 
be unnoticeable if you never use = void.
Dec 04 2016
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Monday, 5 December 2016 at 04:41:55 UTC, Stefan Koch wrote:

 Hi Guys,
 What is your opinion, should we warn if we unambiguously detect 
 something that is clearly unwanted ?

 int fn(int y)
 {
   int x = void;
   ++x;
   return x+y;
 }

  This requires data-flow analysis (The same kind that tells you 
 if you are skipping a statement)
 And will slow down compilation a little if we enable such a 
 warning.


no need to. if i explicitly wrote `=void` there, i know what i am 
doing. maybe i want that UB. or something. and i tried to tell 
the compiler STFU. please, don't make it harder, and don't force 
me to invent another ways to say STFU.
Dec 04 2016
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Monday, 5 December 2016 at 04:59:01 UTC, ketmar wrote:

 On Monday, 5 December 2016 at 04:41:55 UTC, Stefan Koch wrote:

 Hi Guys,
 What is your opinion, should we warn if we unambiguously 
 detect something that is clearly unwanted ?

 int fn(int y)
 {
   int x = void;
   ++x;
   return x+y;
 }

  This requires data-flow analysis (The same kind that tells 
 you if you are skipping a statement)
 And will slow down compilation a little if we enable such a 
 warning.


 no need to. if i explicitly wrote `=void` there, i know what i 
 am doing. maybe i want that UB. or something. and i tried to 
 tell the compiler STFU. please, don't make it harder, and don't 
 force me to invent another ways to say STFU.


Even if you want that ub.
A warning will not halt the compilation.
Dec 04 2016
next sibling parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 5.12.2016 v 06:03 Stefan Koch via Digitalmars-d napsal(a):


 On Monday, 5 December 2016 at 04:59:01 UTC, ketmar wrote:

 On Monday, 5 December 2016 at 04:41:55 UTC, Stefan Koch wrote:

 Hi Guys,
 What is your opinion, should we warn if we unambiguously detect 
 something that is clearly unwanted ?

 int fn(int y)
 {
   int x = void;
   ++x;
   return x+y;
 }

  This requires data-flow analysis (The same kind that tells you if 
 you are skipping a statement)
 And will slow down compilation a little if we enable such a warning.


 no need to. if i explicitly wrote `=void` there, i know what i am 
 doing. maybe i want that UB. or something. and i tried to tell the 
 compiler STFU. please, don't make it harder, and don't force me to 
 invent another ways to say STFU.


 Even if you want that ub.
 A warning will not halt the compilation.


Yes, but still will be there. I always try to have no warnings, maybe as 
a special compilation flag could enable this.
Dec 04 2016
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Monday, 5 December 2016 at 07:25:20 UTC, Daniel Kozak wrote:

 Dne 5.12.2016 v 06:03 Stefan Koch via Digitalmars-d napsal(a):


 On Monday, 5 December 2016 at 04:59:01 UTC, ketmar wrote:

 On Monday, 5 December 2016 at 04:41:55 UTC, Stefan Koch wrote:

 Hi Guys,
 What is your opinion, should we warn if we unambiguously 
 detect something that is clearly unwanted ?

 int fn(int y)
 {
   int x = void;
   ++x;
   return x+y;
 }

  This requires data-flow analysis (The same kind that tells 
 you if you are skipping a statement)
 And will slow down compilation a little if we enable such a 
 warning.


 no need to. if i explicitly wrote `=void` there, i know what 
 i am doing. maybe i want that UB. or something. and i tried 
 to tell the compiler STFU. please, don't make it harder, and 
 don't force me to invent another ways to say STFU.


 Even if you want that ub.
 A warning will not halt the compilation.


 Yes, but still will be there. I always try to have no warnings, 
 maybe as a special compilation flag could enable this.


It will warn on something that is almost always bad!
Dec 04 2016
next sibling parent Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 5.12.2016 v 08:39 Stefan Koch via Digitalmars-d napsal(a):

 On Monday, 5 December 2016 at 07:25:20 UTC, Daniel Kozak wrote:

 Dne 5.12.2016 v 06:03 Stefan Koch via Digitalmars-d napsal(a):


 On Monday, 5 December 2016 at 04:59:01 UTC, ketmar wrote:

 On Monday, 5 December 2016 at 04:41:55 UTC, Stefan Koch wrote:

 Hi Guys,
 What is your opinion, should we warn if we unambiguously detect 
 something that is clearly unwanted ?

 int fn(int y)
 {
   int x = void;
   ++x;
   return x+y;
 }

  This requires data-flow analysis (The same kind that tells you if 
 you are skipping a statement)
 And will slow down compilation a little if we enable such a warning.


 no need to. if i explicitly wrote `=void` there, i know what i am 
 doing. maybe i want that UB. or something. and i tried to tell the 
 compiler STFU. please, don't make it harder, and don't force me to 
 invent another ways to say STFU.


 Even if you want that ub.
 A warning will not halt the compilation.


 Yes, but still will be there. I always try to have no warnings, maybe 
 as a special compilation flag could enable this.


 It will warn on something that is almost always bad!


https://github.com/g0tmi1k/debian-ssh#information
Dec 04 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/4/2016 11:39 PM, Stefan Koch wrote:

 It will warn on something that is almost always bad!


Warnings cause problems in that they fracture the language into different, 
confusing dialects. Let's say you've joined a new group, and you're expected to 
maintain some D codebase you are totally unfamiliar with. It compiles with 
warnings. Is that a problem or not?

Every warning in the compiler is a problem with the language specification, not 
a solution.
Dec 07 2016
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, December 07, 2016 02:14:38 Walter Bright via Digitalmars-d 
wrote:

 On 12/4/2016 11:39 PM, Stefan Koch wrote:

 It will warn on something that is almost always bad!


 Warnings cause problems in that they fracture the language into different,
 confusing dialects. Let's say you've joined a new group, and you're
 expected to maintain some D codebase you are totally unfamiliar with. It
 compiles with warnings. Is that a problem or not?


Warnings drive me nuts in C++ - especially with Visual Studio. It warns
about all kinds of stupid stuff that makes no sense, much of which is
perfectly valid C++ that gcc and clang don't complain about. And even when
the warning does make sense, once you have to deal with 3rd party libraries,
you can't rely on what warnings they were set up to work with. This is
particularly fatal if the code is compiled with warnings being errors.

Maybe if warnings were completely standardized, it wouldn't be so bad, but
as soon as it's up to the compiler vendor, it can get disgusting fast -
especially for cross-platform code. But since it's bad practice to leave
warnings in your code, ultimately, they might as well be errors. And if they
aren't something that should _always_ be fixed, then they have no business
as warnings. Stuff that only _could_ be a problem should be left to a linter
IMHO.

So, I'm all for avoiding adding more warnings, though I wouldn't mind if
Stefan's idea were implemented as an error in the cases where it's
_guaranteed_ that the code is wrong. As soon as "might" gets involved, then
the compiler should ignore it.


 Every warning in the compiler is a problem with the language
 specification, not a solution.


+1

- Jonathan M Davis
Dec 07 2016
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/7/2016 4:40 AM, Jonathan M Davis via Digitalmars-d wrote:

 Warnings drive me nuts in C++ - especially with Visual Studio. It warns
 about all kinds of stupid stuff that makes no sense, much of which is
 perfectly valid C++ that gcc and clang don't complain about.


Warnings proliferate like bedbugs in C and C++ compilers because the vendors 
cannot fix the language, so they more or less invent their own language by 
generating warnings.

As you pointed out, though, each vendor produces a different set of warnings, 
and trying to make code "warning portable" can be an annoying exercise in 
frustration.

Standardizing warnings will never work, because that means modifying the 
language standard, but warning were invented as a workaround for not being able 
to modify the standard!

Note that the C and C++ Standards do not specify any warnings.

---------------------

Warnings are useful as a first step in a deprecation process, but when people 
debate a language restriction, cannot agree, and so compromise by generating a 
warning, things have failed.
Dec 07 2016
parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, December 07, 2016 05:14:47 Walter Bright via Digitalmars-d 
wrote:

 Warnings are useful as a first step in a deprecation process


Yeah, but at this point, we have a separate mechanism for deprecations, and
it doesn't stop compilation (as originally happened with deprecations),
making warnings unnecessary for that.


 but when
 people debate a language restriction, cannot agree, and so compromise by
 generating a warning, things have failed.


Definitely. And I think that the mess with C++ and warnings is proof of
that.

- Jonathan M Davis
Dec 07 2016
prev sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Wed, 07 Dec 2016 04:40:02 -0800, Jonathan M Davis via Digitalmars-d
wrote:

 Maybe if warnings were completely standardized, it wouldn't be so bad,


Warnings that depend on flow analysis will be a problem. You can't write 
a compliant compiler unless you implement this level of flow analysis -- 
but then it's a problem if any compiler produces better flow analysis!
Dec 07 2016
parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, December 07, 2016 22:10:57 Chris Wright via Digitalmars-d 
wrote:

 On Wed, 07 Dec 2016 04:40:02 -0800, Jonathan M Davis via Digitalmars-d

 wrote:

 Maybe if warnings were completely standardized, it wouldn't be so bad,


 Warnings that depend on flow analysis will be a problem. You can't write
 a compliant compiler unless you implement this level of flow analysis --
 but then it's a problem if any compiler produces better flow analysis!


Well, if the code is unambiguously wrong, and it's just that some compilers
catch it and some don't, I'm not sure that that's a big deal, since as soon
as one compiler catches it, you know about it, and you fix it, and since
it's definitely wrong, there should be no problem with fixing it. But it
must be unambiguously bad code, or it definitely is a problem.

- Jonathan M Davis
Dec 07 2016
prev sibling next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Monday, 5 December 2016 at 05:03:36 UTC, Stefan Koch wrote:

 A warning will not halt the compilation.


it will: all my projects are built in "-Werror" mode (the only 
warning i made explicitly switchable in dmd is "statement 
unreachable" -- it is completely useless for me).

i'd prefer to have `pragma(warning/info, msg);` instead, so i can 
issue informational messages when i want to.
Dec 05 2016
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, December 05, 2016 05:03:36 Stefan Koch via Digitalmars-d wrote:

 On Monday, 5 December 2016 at 04:59:01 UTC, ketmar wrote:

 On Monday, 5 December 2016 at 04:41:55 UTC, Stefan Koch wrote:

 Hi Guys,
 What is your opinion, should we warn if we unambiguously
 detect something that is clearly unwanted ?

 int fn(int y)
 {

   int x = void;
   ++x;
   return x+y;

 }

  This requires data-flow analysis (The same kind that tells

 you if you are skipping a statement)
 And will slow down compilation a little if we enable such a
 warning.


 no need to. if i explicitly wrote `=void` there, i know what i
 am doing. maybe i want that UB. or something. and i tried to
 tell the compiler STFU. please, don't make it harder, and don't
 force me to invent another ways to say STFU.


 Even if you want that ub.
 A warning will not halt the compilation.


It will with -w. And even if you build with -wi, it's bad practice to leave
warnings in. So, really, we should _never_ warn about anything where it
would be reasonable for the programmer to not fix whatever is causing the
warning.

That being said, if we're dealing with something that is clearly never okay,
a warning is fine. And I don't know how anyone can claim that doing
something like ++x on a variable that was initialized with null or void is
rasonable. But if such a warning were introduced, it would have to be done
carefully and only used when it was totally certain that what the programmer
was doing was invalid. For instance, taking the address of the variable or
passing it to a function would potentially be perfectly fine, whereas
calling a member function on it when nothing could have possibly given it a
value wouldn't be.

Java sometimes gets annoying with how it requires that you initialize a
variable before you use it, because its detection simply isn't smart enough,
and we don't want to get into a similar boat with D. So, if such detection
really _is_ smart enough, then fine, but it should never have false
positives, or it's making things worse than they are now.

- Jonathan M Davis
Dec 05 2016
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/04/2016 11:41 PM, Stefan Koch wrote:

 Hi Guys,
 What is your opinion, should we warn if we unambiguously detect
 something that is clearly unwanted ?

 int fn(int y)
 {
   int x = void;
   ++x;
   return x+y;
 }


No new warnings please. If something (such as the above) is definitely 
wrong - the code is not memory unsafe but is definitely in error - then 
just issue an error. That should be done whether or not the function is 
used in CTFE. -- Andrei
Dec 05 2016
parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, December 05, 2016 08:35:34 Andrei Alexandrescu via Digitalmars-d 
wrote:

 On 12/04/2016 11:41 PM, Stefan Koch wrote:

 Hi Guys,
 What is your opinion, should we warn if we unambiguously detect
 something that is clearly unwanted ?

 int fn(int y)
 {

   int x = void;
   ++x;
   return x+y;

 }


 No new warnings please. If something (such as the above) is definitely
 wrong - the code is not memory unsafe but is definitely in error - then
 just issue an error. That should be done whether or not the function is
 used in CTFE. -- Andrei


+1

- Jonathan M Davis
Dec 05 2016
prev sibling next sibling parent reply burjui <bytefu gmail.com> writes:
On Monday, 5 December 2016 at 04:41:55 UTC, Stefan Koch wrote:

 Hi Guys,
 What is your opinion, should we warn if we unambiguously detect 
 something that is clearly unwanted ?

 int fn(int y)
 {
   int x = void;
   ++x;
   return x+y;
 }

  This requires data-flow analysis (The same kind that tells you 
 if you are skipping a statement)
 And will slow down compilation a little if we enable such a 
 warning.


Yes, but we should issue an error, like Andrei said. A language 
is only as useful as it's best implementation, so diagnostics 
like that are essential. Data-flow analysis shouldn't even be 
optional or lacking in any modern compiler.
Dec 06 2016
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 7 December 2016 at 06:47:56 UTC, burjui wrote:

 Yes, but we should issue an error, like Andrei said. A language 
 is only as useful as it's best implementation, so diagnostics 
 like that are essential. Data-flow analysis shouldn't even be 
 optional or lacking in any modern compiler.


you know, D has variable initialization with default values. that 
allows to skip DFA, and still be sure that variable is 
initialized.

also, that thing can be done in *backend*, if it is really 
necessary, along with eliminating needless loads. such 
warning/error absolutely unnecessary in frontend, it only adds 
more code to maintain, and slows down compiling.
Dec 06 2016
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/4/2016 8:41 PM, Stefan Koch wrote:

 What is your opinion, should we warn if we unambiguously detect something that
 is clearly unwanted ?

 int fn(int y)
 {
   int x = void;
   ++x;
   return x+y;
 }


It's an old idea, and comes up regularly.

This all sounds like a great idea, and I've tried it. Unfortunately, it runs 
afoul of code like this:

   int i;
   int* p = null;
   if (c)
     p = &i;
   ...code...
   if (c)
     *p = 3; // Warning Will Robinson! p could be null!

Now, one could say "improve the flow analysis to prove that the first `if(c)`
is 
the same as the second `if(c)`. Unfortunately, `c` can be arbitrarily complex 
and it is one of those unresolvable problems proving that two expressions 
produce the same result, even if the programmer finds it obvious.

Does this happen in real code? As I discovered, yes. Often enough that I had to 
back out that feature.

[Other, more subtle issues like this can come from machine generated code paths 
that will never execute, but are difficult to not generate. So the poor schleb 
writing the generator has to spend a lot of time on this to work around 
shortcomings in the compiler flow analysis - and he'll be guaranteed to not be 
happy about it.]
Dec 07 2016
next sibling parent Andrea Fontana <nospam example.com> writes:
On Wednesday, 7 December 2016 at 10:25:56 UTC, Walter Bright 
wrote:

 On 12/4/2016 8:41 PM, Stefan Koch wrote:

 What is your opinion, should we warn if we unambiguously 
 detect something that
 is clearly unwanted ?

 int fn(int y)
 {
   int x = void;
   ++x;
   return x+y;
 }


 It's an old idea, and comes up regularly.

 This all sounds like a great idea, and I've tried it. 
 Unfortunately, it runs afoul of code like this:

   int i;
   int* p = null;
   if (c)
     p = &i;
   ...code...
   if (c)
     *p = 3; // Warning Will Robinson! p could be null!


Yes here it *could* be null but here it is for sure:

int* p = null;
...
// p never used here inside or outside code blocks
...
*p = 3;

So I think we can safely halt compilation with an error.

(The same goes on void example above)
Dec 07 2016
prev sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Wednesday, 7 December 2016 at 10:25:56 UTC, Walter Bright 
wrote:

 On 12/4/2016 8:41 PM, Stefan Koch wrote:

 What is your opinion, should we warn if we unambiguously 
 detect something that
 is clearly unwanted ?


 It's an old idea, and comes up regularly.

 This all sounds like a great idea, and I've tried it. 
 Unfortunately, it runs afoul of code like this:

   int i;
   int* p = null;
   if (c)
     p = &i;
   ...code...
   if (c)
     *p = 3; // Warning Will Robinson! p could be null!


That is why I said unambiguously.
We will neither warn or error in the above case, because p could 
have been assigned to.
Only if we directly read from something uninitialized will we 
error.
Dec 07 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/7/2016 3:52 AM, Stefan Koch wrote:

 That is why I said unambiguously.


Ok.


 We will neither warn or error in the above case, because p could have been
 assigned to.
 Only if we directly read from something uninitialized will we error.


The dmd optimizer does global data flow analysis:

int fn(int y)
{
   int x = void;
   ++x;
   return x+y;
}

----

dmd -c test7 -O
test7.d(4): Error: variable x used before set

----

https://github.com/dlang/dmd/blob/master/src/backend/gother.c#L418

dmd's back end has done global data flow analysis since about 1985, even though 
popular opinion holds that clang invented it :-)
Dec 07 2016
prev sibling parent reply qznc <qznc web.de> writes:
On Monday, 5 December 2016 at 04:41:55 UTC, Stefan Koch wrote:

  This requires data-flow analysis (The same kind that tells you 
 if you are skipping a statement)
 And will slow down compilation a little if we enable such a 
 warning.



I would rather see a separate tool for stuff like this. It can be 
much slower and do much more analysis.

Compare: clang-analyzer http://clang-analyzer.llvm.org/
Dec 08 2016
parent Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 8 December 2016 at 08:52:45 UTC, qznc wrote:

 On Monday, 5 December 2016 at 04:41:55 UTC, Stefan Koch wrote:

  This requires data-flow analysis (The same kind that tells 
 you if you are skipping a statement)
 And will slow down compilation a little if we enable such a 
 warning.



 I would rather see a separate tool for stuff like this. It can 
 be much slower and do much more analysis.

 Compare: clang-analyzer http://clang-analyzer.llvm.org/


Due to D's stronger focus on correctness,
something like the clang static analyzer has importance in D then 
it has in C++.

Also If we don't stick to unambiguous errors, there will be a LOT 
of false positives.
Dec 08 2016