Re: Should we warn if we detect null derefernces or void value uses ?
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.
Re: Should we warn if we detect null derefernces or void value uses ?
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/
Re: Should we warn if we detect null derefernces or void value uses ?
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
Re: Should we warn if we detect null derefernces or void value uses ?
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
Re: Should we warn if we detect null derefernces or void value uses ?
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!
Re: Should we warn if we detect null derefernces or void value uses ?
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.
Re: Should we warn if we detect null derefernces or void value uses ?
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 :-)
Re: Should we warn if we detect null derefernces or void value uses ?
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
Re: Should we warn if we detect null derefernces or void value uses ?
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 = ...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.
Re: Should we warn if we detect null derefernces or void value uses ?
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 =
...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)
Re: Should we warn if we detect null derefernces or void value uses ?
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 =
...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.]
Re: Should we warn if we detect null derefernces or void value uses ?
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.
Re: Should we warn if we detect null derefernces or void value uses ?
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.
Re: Should we warn if we detect null derefernces or void value uses ?
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.
Re: Should we warn if we detect null derefernces or void value uses ?
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
Re: Should we warn if we detect null derefernces or void value uses ?
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
Re: Should we warn if we detect null derefernces or void value uses ?
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
Re: Should we warn if we detect null derefernces or void value uses ?
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.
Re: Should we warn if we detect null derefernces or void value uses ?
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
Re: Should we warn if we detect null derefernces or void value uses ?
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!
Re: Should we warn if we detect null derefernces or void value uses ?
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.
Re: Should we warn if we detect null derefernces or void value uses ?
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.
Re: Should we warn if we detect null derefernces or void value uses ?
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.
Re: Should we warn if we detect null derefernces or void value uses ?
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.
Should we warn if we detect null derefernces or void value uses ?
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.
