This code fails, with -unittest:

unittest {} void main() {}


This bug is just a variant of:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2677

And the suggested (partial) patch:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2853

--anders

On Tue, 01 Mar 2005 12:02:15 +0100, Anders F Björklund wrote:

> This code fails, with -unittest:
> 
> unittest {} void main() {}
> 
> 
> This bug is just a variant of:
> 
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2677
> 
> And the suggested (partial) patch:
> 
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2853
> 
> --anders

It doesn't fail on Windows XP.

f:\temp>type test.d
unittest {} void main() {}


f:\temp>dmd test.d -unittest f:\dmd\bin\..\..\dm\bin\link.exe test,,,user32+kernel32/noi;

f:\temp>test

f:\temp>dmd
Digital Mars D Compiler v0.114
Copyright (c) 1999-2005 by Digital Mars written by Walter Bright


-- 
Derek
Melbourne, Australia

Derek wrote:

>>This code fails, with -unittest:
>>
>>unittest {} void main() {}
> 
> It doesn't fail on Windows XP.

I meant the return code. Not sure how you use those on windows... ?

On unix, you can do stuff like: ./unittest && echo PASS || echo FAIL

--anders

On Tue, 01 Mar 2005 12:29:32 +0100, Anders F Björklund wrote:

> Derek wrote:
> 
>>>This code fails, with -unittest:
>>>
>>>unittest {} void main() {}
>> 
>> It doesn't fail on Windows XP.
> 
> I meant the return code. Not sure how you use those on windows... ?
> 
> On unix, you can do stuff like: ./unittest && echo PASS || echo FAIL
> 
> --anders

With people like me, you have just gotta be a whole lot more specific, and show examples ;-)

Ok, so you are saying that using 'void main()' causes a non-zero return code to be sent back to the operating system.

Well, I can confirm that in Windows too then.

--- First with a definite ZERO returned ----
f:\temp>type test.d
unittest {} int main() {return 0;}


f:\temp>dmd -unittest test.d f:\dmd\bin\..\..\dm\bin\link.exe test,,,user32+kernel32/noi;

f:\temp>test & if errorlevel 1 echo fail

f:\temp>

Okay that worked as expected. Now the VOID version ...

f:\temp>type test.d
unittest {} void main() {}


f:\temp>dmd -unittest test.d f:\dmd\bin\..\..\dm\bin\link.exe test,,,user32+kernel32/noi;

f:\temp>test & if errorlevel 1 echo fail
fail

f:\temp>

So a 'void main()' returns a non-zero.

I guess it would be nice if it returned zero. Sure make some people's work easier.

BTW, what has -unittest got to do with this bug?

-- 
Derek
Melbourne, Australia

Derek wrote:

> With people like me, you have just gotta be a whole lot more specific, and
> show examples ;-)
> 
> Ok, so you are saying that using 'void main()' causes a non-zero return
> code to be sent back to the operating system.

Yes, I didn't bother repeating myself but just linked... :-)

> So a 'void main()' returns a non-zero.
> 
> I guess it would be nice if it returned zero. Sure make some people's work
> easier.
> 
> BTW, what has -unittest got to do with this bug?

It means you always have to use "int main" and "return EXIT_SUCCESS",
or your unit tests will always fail. Like you say, that's a pain...

Otherwise, the other bug is unrelated.
> cdouble main() { return 1.0 + 2.0i; }

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:d01i3p$2d7p$1@digitaldaemon.com...
> This code fails, with -unittest:
>
> unittest {} void main() {}
>
>
> This bug is just a variant of:
>
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2677
>
> And the suggested (partial) patch:
>
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2853
>
> --anders

Techinically this isn't a bug, right? The compiler is behaving exactly as designed.

Ben Hinkle wrote:

>>This bug is just a variant of:
>>
>>http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2677
> 
> Techinically this isn't a bug, right? The compiler is behaving exactly as designed. 

Not really a bug, no. Just a "missed opportunity" to be better than C...

I like "void main() {}" a lot, and wish that it will be fixed and stay.

--anders

I'd say you're both right here - void main() is nice - I use it a lot, but
generally not
where the return code is of some use. I don't really see how you can decide
how
to set it otherwise - the program may actually have failed, in which case
returning
success is just as disastrous.

One possible approach - to contradict myself :) - would be to have void
main()
return 0 normally, but nonzero if main() was exited by an unhandled
exception ?

Rob

"Anders F Björklund" <afb@algonet.se> wrote in message news:d01o9v$2jsg$1@digitaldaemon.com...
> Ben Hinkle wrote:
>
>>>This bug is just a variant of:
>>>
>>>http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2677
>>
>> Techinically this isn't a bug, right? The compiler is behaving exactly as designed.
>
> Not really a bug, no. Just a "missed opportunity" to be better than C...
>
> I like "void main() {}" a lot, and wish that it will be fixed and stay.
>
> --anders

Rob Grainger wrote:

> I'd say you're both right here - void main() is nice - I use it a lot, but generally not
> where the return code is of some use. I don't really see how you can decide how
> to set it otherwise - the program may actually have failed, in which case returning
> success is just as disastrous.

If you do need to return a code, you use "int main" instead.

Similar to parameters:
no need for parameters => "main()"
want to access them => "main(char[][] args)"

And if you change your mind, there's always:
std.c.stdlib.exit(1);

> One possible approach - to contradict myself :) - would be to have void main()
> return 0 normally, but nonzero if main() was exited by an unhandled exception ?

It already does that, which was part of the point of the unittest issue.

int main()
{
  throw new Exception("");
  return 0;
}

This program has an exit code of "1".

--anders

Anders F Björklund <afb@algonet.se> wrote:

[...]
> int main()
> {
>    throw new Exception("");
>    return 0;
> }
> 
> This program has an exit code of "1".

According to Matthew this program shouldn't be compilable.

-manfred