I think I found a bug. I could be wrong. ;)

bit b;

int main()
{
    if (b)
        return 0;
}

Note the lack of a return statement when b is false (which is always).

It compiles fine. At runtime, an error occurs...
Error: AssertError Failure bug.d(7)

I understand it can be difficult/undesirable for the compiler to catch a problem like this during compile. If the lack of a return is cause of the AssertError, I hope it could at least be renamed to NoReturnError or something.

(I've observed this with DMD 0.98 and DMD 0.100 on WinXP.)

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

"J C Calvarese" <jcc7@cox.net> wrote in message news:cge2ru$4gs$1@digitaldaemon.com...
> I think I found a bug. I could be wrong. ;)
>
> bit b;
>
> int main()
> {
>      if (b)
>          return 0;
> }
>
> Note the lack of a return statement when b is false (which is always).
>
> It compiles fine. At runtime, an error occurs...
> Error: AssertError Failure bug.d(7)

This is expected behaviour, and was discussed before.
Some people argued that compiler should check that every
code path ends in return or throw and i think Walter said
it was too complicated.

The only requirement now is that function has at least one return statement, so you can trick compiler to do bad things easilly:

 int func()
 {
  goto skipret;
  return 0;
  skipret:;
 }

As far as compiler is consearned this is a valid func(even though return
isn't reachable), but will also get you AssertError :(

>
> I understand it can be difficult/undesirable for the compiler to catch a problem like this during compile. If the lack of a return is cause of the AssertError, I hope it could at least be renamed to NoReturnError or something.
>
> (I've observed this with DMD 0.98 and DMD 0.100 on WinXP.)
>
> --
> Justin (a/k/a jcc7)
> http://jcc_7.tripod.com/d/

"Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:cgemi7$e6i$1@digitaldaemon.com...
>
> "J C Calvarese" <jcc7@cox.net> wrote in message news:cge2ru$4gs$1@digitaldaemon.com...
> > I think I found a bug. I could be wrong. ;)
> >
> > bit b;
> >
> > int main()
> > {
> >      if (b)
> >          return 0;
> > }
> >
> > Note the lack of a return statement when b is false (which is always).
> >
> > It compiles fine. At runtime, an error occurs...
> > Error: AssertError Failure bug.d(7)
>
> This is expected behaviour, and was discussed before.
> Some people argued that compiler should check that every
> code path ends in return or throw and i think Walter said
> it was too complicated.
>
> The only requirement now is that function has at least one return statement, so you can trick compiler to do bad things easilly:
>
>  int func()
>  {
>   goto skipret;
>   return 0;
>   skipret:;
>  }
>
> As far as compiler is consearned this is a valid func(even though return
> isn't reachable), but will also get you AssertError :(

If D's simpler than C++ to implement, and C++ compilers can do this pretty much in their sleep, then why should D not?

IMO, it's ridiculous that code such as

> > bit b;
> >
> > int main()
> > {
> >      if (b)
> >          return 0;
> > }

can get past the compiler. Period.

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cgh9ms$1ohc$1@digitaldaemon.com...
>
> "Ivan Senji" <ivan.senji@public.srce.hr> wrote in message
news:cgemi7$e6i$1@digitaldaemon.com...
> >
> > "J C Calvarese" <jcc7@cox.net> wrote in message news:cge2ru$4gs$1@digitaldaemon.com...
> > > I think I found a bug. I could be wrong. ;)
> > >
> > > bit b;
> > >
> > > int main()
> > > {
> > >      if (b)
> > >          return 0;
> > > }
> > >
> > > Note the lack of a return statement when b is false (which is always).
> > >
> > > It compiles fine. At runtime, an error occurs...
> > > Error: AssertError Failure bug.d(7)
> >
> > This is expected behaviour, and was discussed before.
> > Some people argued that compiler should check that every
> > code path ends in return or throw and i think Walter said
> > it was too complicated.
> >
> > The only requirement now is that function has at least one return statement, so you can trick compiler to do bad things easilly:
> >
> >  int func()
> >  {
> >   goto skipret;
> >   return 0;
> >   skipret:;
> >  }
> >
> > As far as compiler is consearned this is a valid func(even though return
> > isn't reachable), but will also get you AssertError :(
>
> If D's simpler than C++ to implement, and C++ compilers can do this pretty
much in their sleep, then why should D not?

You are absoulutelly right. And the problem is i can't see a problem in implementing it:

bool statementListEndsInReturn(StatementList sl)
{
    if(typeid(sl.laststatement) === typeid(ReturnStatement))return true;
    if(typeid(sl.laststatement) === typeid(IfStatement))
        return statementListEndsInReturn(sl.laststatement.truepart)
                && statementListEndsInReturn(sl.laststatement.elsepart);
    //maybe a couple of more cases
    return false;
}


> IMO, it's ridiculous that code such as
>
> > > bit b;
> > >
> > > int main()
> > > {
> > >      if (b)
> > >          return 0;
> > > }
>
> can get past the compiler. Period.
>
>
>
>

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cgh9ms$1ohc$1@digitaldaemon.com...
> If D's simpler than C++ to implement, and C++ compilers can do this pretty
much in their sleep, then why should D not?

I've never seen a C++ compiler get it completely right, and there's no way that they can. I don't like putting in meaningless return statements in code that will never be executed and that will confuse the maintenance programmer, just to get the compiler to stop issuing an error message.

But I do want to find out if that meaningless return statement ever does happen. There's no way to do it 100% without a runtime check, hence that's what the language does.

In article <cghkuj$1uni$1@digitaldaemon.com>, Walter says...

>I don't like putting in meaningless return statements in code
>that will never be executed and that will confuse the maintenance
>programmer, just to get the compiler to stop issuing an error message.

I'd rather have it that way round that the current way round. False positives
(unnecessary returns) are better than false negatives (failing to reach a return
at all) in this situation. Consider:

#    int f(int n)
#    in
#    {
#        assert(n > 3 && n < 10);
#    }
#    body
#    {
#        if (n >= 4 && n < 8) return 3;
#        if (n >= 8 && n < 10) return 4;
#        // The compiler will insist on an unnecessary return here.
#    }

So the compiler demands a superfluous return. Big deal. I can live with that. Better a statement which won't get executed (and therefore won't affect the running of my program in any way at all) than a run-time assert in a debug build and a crash in a release build.



>But I do want to find out if that meaningless return statement ever does happen. There's no way to do it 100% without a runtime check,

Yes. No-one's arguing with that. I just don't think it that important. I'd rather have a compiler which claimed that good code is bad, than a compiler which claimed that bad code is good. I've had crashes because of this situation, and I'd rather not have any more.

Arcane Jill

"Walter" <newshound@digitalmars.com> wrote in message news:cghkuj$1uni$1@digitaldaemon.com...
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cgh9ms$1ohc$1@digitaldaemon.com...
> > If D's simpler than C++ to implement, and C++ compilers can do this pretty
> much in their sleep, then why should D not?
>
> I've never seen a C++ compiler get it completely right, and there's no way that they can. I don't like putting in meaningless return statements in code that will never be executed and that will confuse the maintenance programmer, just to get the compiler to stop issuing an error message.
>
> But I do want to find out if that meaningless return statement ever does happen. There's no way to do it 100% without a runtime check, hence that's what the language does.

Well it's the "completely" that's the issue. I don't need 100%. In the code I write, I've maybe come across the C++ compiler not spot a missing return only a handful of types in 12 years.

Conversely, I've had false positives perhaps 5 or six times a year. Frankly, I'd rather have that than missing a return. I'd far rather have the slight inconvenience of having to workaround a false positive 5 times a year than the unquantifiable and unpredictable throwing of exceptions at any time after the deployment of my code. Frankly, this is another of those situations where your penchant for compiler simplicity and the influence of your own coding style are given precedence over measures of robustness and scalability to, IMO, the long-term detriment of the language.

"Walter" <newshound@digitalmars.com> wrote in message news:cghkuj$1uni$1@digitaldaemon.com...
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cgh9ms$1ohc$1@digitaldaemon.com...
> > If D's simpler than C++ to implement, and C++ compilers can do this
pretty
> much in their sleep, then why should D not?
>
> I've never seen a C++ compiler get it completely right, and there's no way that they can. I don't like putting in meaningless return statements in
code
> that will never be executed and that will confuse the maintenance programmer, just to get the compiler to stop issuing an error message.

I agree with Matthew and Arcane Jill on this. I will believe you if you
say that there are some strange code fragments for wich it is not possible
to detect a missing return or throw, but if D could get it right 95% of the
time
it would be good enough. Test only for the simplest cases with return
on the end of the function or return  in every branch or every case
of the last if or switch and ignore those like in my example where i try to
skip return with a goto. (This one can also be detected, if the last
statement
is empty and the one before it is a label=> error missing return at the
end.)


> But I do want to find out if that meaningless return statement ever does happen. There's no way to do it 100% without a runtime check, hence that's what the language does.
>
>

In article <cght30$21u3$1@digitaldaemon.com>, Matthew says...

>unquantifiable and unpredictable throwing of exceptions at any time after the deployment of my code.

It's /much/ worse than that if you compile with the "-release" flag. These are asserts, not exceptions. They vanish in a release build, leaving you with /seriously/ undefined behavior.

Arcane Jill

In article <cghkuj$1uni$1@digitaldaemon.com>, Walter says...
>
>
>"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cgh9ms$1ohc$1@digitaldaemon.com...
>> If D's simpler than C++ to implement, and C++ compilers can do this pretty
>much in their sleep, then why should D not?
>
>I've never seen a C++ compiler get it completely right, and there's no way that they can. I don't like putting in meaningless return statements in code that will never be executed and that will confuse the maintenance programmer, just to get the compiler to stop issuing an error message.
>
>But I do want to find out if that meaningless return statement ever does happen. There's no way to do it 100% without a runtime check, hence that's what the language does.

I wasn't trying to get into this debate. It's already been debated and I agree with your position. I know the compiler isn't psychic and I don't want it second-guessing every branch in my program.

I was just hoping that we could have a more descriptive runtime error than: Error: AssertError Failure bug.d(7)

Maybe that can't be done. I just thought it was a possibility.

(It only took me a few minutes to figure out what the problem was when I ran into  it, but it could have taken a lot longer if I had made more changes or had a larger program.)

jcc7