www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - assert(false) in release == splinter in eye

reply Christopher Bergqvist <chris digitalpoetry.se> writes:
--20cf304348d21250040492453bd5
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Time for some Sunday nitpicking. While reading TDPL, one thing that stuck
out to me was the special behavior of assert(false). Consider the following
program compiled with "-release".

void main()
{
    int a = 0;
    assert(a);
}

That program will run without errors. Changing the type of variable a from
"int" to "enum" results in the program segfaulting thanks to the compiler
being able to know the value of the expression "a" at compile time and
inserting a HLT/"halt" instruction. Having the ability to change something
subtle in a more complex expression or series of expressions without
realizing you made a compile time assert(false) which crashes your program
feels ugly.

I would prefer it if assert() didn't have this special type of behavior, and
that a "halt" keyword or equivalent was introduced. What do you think?

/ Chris

--20cf304348d21250040492453bd5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>Time for some Sunday nitpicking.=A0While reading TDP=
L, one thing that stuck out to me was the special behavior of assert(false)=
. Consider the following program compiled with &quot;-release&quot;.</div>
<div><br></div><div>void main()</div><div>{</div><div>=A0=A0 =A0int a =3D 0=
;</div><div>=A0=A0 =A0assert(a);</div><div>}</div><div><br></div><div>That =
program will run without errors. Changing the type of variable a from &quot=
;int&quot; to &quot;enum&quot; results in the program segfaulting thanks to=
 the compiler being able to know the value of the expression &quot;a&quot; =
at compile time and inserting a HLT/&quot;halt&quot; instruction. Having th=
e ability to change something subtle in a more complex expression or series=
 of expressions without realizing you made a compile time assert(false) whi=
ch crashes your program feels ugly.</div>
<div><br></div><div>I would prefer it if assert() didn&#39;t have this spec=
ial type of behavior, and that a &quot;halt&quot; keyword or equivalent was=
 introduced. What do you think?</div><div><br></div><div>/ Chris</div>

--20cf304348d21250040492453bd5--
Oct 10 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Christopher Bergqvist:
 I would prefer it if assert() didn't have this special type of behavior, and
 that a "halt" keyword or equivalent was introduced. What do you think?

A halt() intrinsic from sounds indeed cleaner. But I don't know if Walter is willing to add a keyword just for this purpose. Bye bearophile
Oct 10 2010
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
bearophile wrote:

 Christopher Bergqvist:
 I would prefer it if assert() didn't have this special type of behavior, and
 that a "halt" keyword or equivalent was introduced. What do you think?

A halt() intrinsic from sounds indeed cleaner. But I don't know if Walter is willing to add a keyword just for this purpose. Bye bearophile

assert(halt)? (thinking of scope) I agree btw, this is very error prone.
Oct 11 2010
parent Lutger <lutger.blijdestijn gmail.com> writes:
Simen kjaeraas wrote:

 Lutger <lutger.blijdestijn gmail.com> wrote:
 
 bearophile wrote:

 assert(halt)? (thinking of scope)

 I agree btw, this is very error prone.

Error prone? When should the program haltin debug mode, but not in release?

You're right, I wasn't thinking clear.
Oct 11 2010
prev sibling next sibling parent reply Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Christopher Bergqvist napisał:

 Hi,
 
 Time for some Sunday nitpicking. While reading TDPL, one thing that stuck
 out to me was the special behavior of assert(false). Consider the
 following program compiled with "-release".
 
 void main()
 {
     int a = 0;
     assert(a);
 }
 
 That program will run without errors. Changing the type of variable a from
 "int" to "enum" results in the program segfaulting thanks to the compiler
 being able to know the value of the expression "a" at compile time and
 inserting a HLT/"halt" instruction. Having the ability to change something
 subtle in a more complex expression or series of expressions without
 realizing you made a compile time assert(false) which crashes your program
 feels ugly.

 I would prefer it if assert() didn't have this special type of behavior,
 and that a "halt" keyword or equivalent was introduced. What do you think?

I have the same feeling. 'halt' is good, 'fail' is good too. It doesn't have to be a keyword, a function in object.d would suffice. BTW, does anybody know the reason for the assert(0) infernal syntax? -- Tomek
Oct 10 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Tomek S.:

 BTW, does anybody know the reason for the assert(0) infernal syntax?

I think it's a shorcut, to gain a functionality without adopting a specific syntax. An as it very often happens in language design, shortcuts later come back to bite your bum :-) Bye, bearophile
Oct 10 2010
prev sibling next sibling parent Christopher Bergqvist <chris digitalpoetry.se> writes:
--20cf301d3e720048ef04924bf2ba
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks for the support guys. :)

Unfortunately "halt" would still need to be a keyword if one wants to keep
the full behavior of assert(0), where the compiler knows that it affects th=
e
control-flow of the program.

Legal:
int main()
{
    assert(0);
}

Illegal (Error: function D main has no return statement, but is expected to
return a value of type int):
int main()
{
    int a =3D 0;
    assert(a);
}


2010/10/10 Tomek Sowi=C5=84ski <just ask.me>

 Christopher Bergqvist napisa=C5=82:

 Hi,

 Time for some Sunday nitpicking. While reading TDPL, one thing that stu=


 out to me was the special behavior of assert(false). Consider the
 following program compiled with "-release".

 void main()
 {
     int a =3D 0;
     assert(a);
 }

 That program will run without errors. Changing the type of variable a

 "int" to "enum" results in the program segfaulting thanks to the compil=


 being able to know the value of the expression "a" at compile time and
 inserting a HLT/"halt" instruction. Having the ability to change

 subtle in a more complex expression or series of expressions without
 realizing you made a compile time assert(false) which crashes your

 feels ugly.

 I would prefer it if assert() didn't have this special type of behavior=


 and that a "halt" keyword or equivalent was introduced. What do you

I have the same feeling. 'halt' is good, 'fail' is good too. It doesn't have to be a keyword, a function in object.d would suffice. BTW, does anybody know the reason for the assert(0) infernal syntax? -- Tomek

--20cf301d3e720048ef04924bf2ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the support guys. :)<div><br></div><div>Unfortunately &quot;halt= &quot; would still need to be a keyword if one wants to keep the full behav= ior of assert(0), where the compiler knows that it affects the control-flow= of the program.</div> <div><br></div><div>Legal:</div><div>int main()</div><div>{</div><div>=C2= =A0=C2=A0 =C2=A0assert(0);</div><div>}</div><div><br></div><div>Illegal (Er= ror: function D main has no return statement, but is expected to return a v= alue of type int):</div> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8"><d= iv>int main()</div><div>{</div><div>=C2=A0=C2=A0 =C2=A0int a =3D 0;</div><d= iv>=C2=A0=C2=A0 =C2=A0assert(a);</div><div>}</div><div><br></div><div><br><= /div><div><div class=3D"gmail_quote"> 2010/10/10 Tomek Sowi=C5=84ski <span dir=3D"ltr">&lt;<a href=3D"mailto:just= ask.me">just ask.me</a>&gt;</span><br><blockquote class=3D"gmail_quote" st= yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Chri= stopher Bergqvist napisa=C5=82:<br> <div class=3D"im"><br> &gt; Hi,<br> &gt;<br> &gt; Time for some Sunday nitpicking. While reading TDPL, one thing that st= uck<br> &gt; out to me was the special behavior of assert(false). Consider the<br> &gt; following program compiled with &quot;-release&quot;.<br> &gt;<br> &gt; void main()<br> &gt; {<br> &gt; =C2=A0 =C2=A0 int a =3D 0;<br> &gt; =C2=A0 =C2=A0 assert(a);<br> &gt; }<br> &gt;<br> &gt; That program will run without errors. Changing the type of variable a = from<br> &gt; &quot;int&quot; to &quot;enum&quot; results in the program segfaulting= thanks to the compiler<br> &gt; being able to know the value of the expression &quot;a&quot; at compil= e time and<br> &gt; inserting a HLT/&quot;halt&quot; instruction. Having the ability to ch= ange something<br> &gt; subtle in a more complex expression or series of expressions without<b= r> &gt; realizing you made a compile time assert(false) which crashes your pro= gram<br> &gt; feels ugly.<br> &gt;<br> </div><div class=3D"im">&gt; I would prefer it if assert() didn&#39;t have = this special type of behavior,<br> &gt; and that a &quot;halt&quot; keyword or equivalent was introduced. What= do you think?<br> <br> </div>I have the same feeling. &#39;halt&#39; is good, &#39;fail&#39; is go= od too. It doesn&#39;t have to be a keyword, a<br> function in object.d would suffice.<br> <br> BTW, does anybody know the reason for the assert(0) infernal syntax?<br> <br> --<br> <font color=3D"#888888">Tomek<br> </font></blockquote></div><br></div> --20cf301d3e720048ef04924bf2ba--
Oct 10 2010
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 11 Oct 2010 03:53:07 +0400, Christopher Bergqvist  
<chris digitalpoetry.se> wrote:

 Thanks for the support guys. :)

 Unfortunately "halt" would still need to be a keyword if one wants to  
 keep
 the full behavior of assert(0), where the compiler knows that it affects  
 the
 control-flow of the program.

 Legal:
 int main()
 {
     assert(0);
 }

 Illegal (Error: function D main has no return statement, but is expected  
 to
 return a value of type int):
 int main()
 {
     int a = 0;
     assert(a);
 }

Just a random thought: class Foo { this(int i) { ... } } class Bar { this(int j) { assert(false); } } Still illegal, but that's a bug I guess.
Oct 10 2010
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Mon, 11 Oct 2010 00:22:38 +0300, Tomek Sowiński <just ask.me> wrote:

 BTW, does anybody know the reason for the assert(0) infernal syntax?

From http://www.digitalmars.com/d/2.0/expression.html#AssertExpression: "The expression assert(0) is a special case; it signifies that it is unreachable code. Either AssertError is thrown at runtime if it is reachable, or the execution is halted (on the x86 processor, a HLT instruction can be used to halt execution). The optimization and code generation phases of compilation may assume that it is unreachable code." Sometimes it's useful to add an assert(0) at the end of a function which should always return at other points, but the compiler can't know that. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Oct 10 2010
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 10 Oct 2010 19:52:28 +0400, Christopher Bergqvist  
<chris digitalpoetry.se> wrote:

 Hi,

 Time for some Sunday nitpicking. While reading TDPL, one thing that stuck
 out to me was the special behavior of assert(false). Consider the  
 following
 program compiled with "-release".

 void main()
 {
     int a = 0;
     assert(a);
 }

 That program will run without errors. Changing the type of variable a  
 from
 "int" to "enum" results in the program segfaulting thanks to the compiler
 being able to know the value of the expression "a" at compile time and
 inserting a HLT/"halt" instruction. Having the ability to change  
 something
 subtle in a more complex expression or series of expressions without
 realizing you made a compile time assert(false) which crashes your  
 program
 feels ugly.

 I would prefer it if assert() didn't have this special type of behavior,  
 and
 that a "halt" keyword or equivalent was introduced. What do you think?

 / Chris

There is a C abort() function, and most compiler recognize that it doesn't return.
Oct 11 2010
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Lutger <lutger.blijdestijn gmail.com> wrote:

 bearophile wrote:

 assert(halt)? (thinking of scope)

 I agree btw, this is very error prone.

Error prone? When should the program haltin debug mode, but not in release? -- Simen
Oct 11 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/10/2010 10:52 AM, Christopher Bergqvist wrote:
 Hi,

 Time for some Sunday nitpicking. While reading TDPL, one thing that
 stuck out to me was the special behavior of assert(false). Consider the
 following program compiled with "-release".

 void main()
 {
      int a = 0;
      assert(a);
 }

 That program will run without errors. Changing the type of variable a
 from "int" to "enum" results in the program segfaulting thanks to the
 compiler being able to know the value of the expression "a" at compile
 time and inserting a HLT/"halt" instruction. Having the ability to
 change something subtle in a more complex expression or series of
 expressions without realizing you made a compile time assert(false)
 which crashes your program feels ugly.

 I would prefer it if assert() didn't have this special type of behavior,
 and that a "halt" keyword or equivalent was introduced. What do you think?

 / Chris

I followed this thread. assert(false) is clearly an unpleasant irregularity in the language. In the beginning I was really bothered by it but with time I have to admit it's not a big deal in practice. assert(false) could be in an ideal world replaced by an intrinsic called e.g. halt() that looks and feels like a regular function but is recognized by the compiler. No new keyword would be needed. But I don't think that would mark a significant improvement in the language. Andrei
Oct 11 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:

 assert(false) could be in an ideal world replaced by an intrinsic called 
 e.g. halt() that looks and feels like a regular function but is 
 recognized by the compiler. No new keyword would be needed. But I don't 
 think that would mark a significant improvement in the language.

I'd like the halt() intrinsic :-) Its main disadvantages are that you need to import it from the intrinsics core module, that you break a bit more backwards compatibility with D1 (because once halt() is present, then assert(0); must vanish in release mode). Bye, bearophile
Oct 11 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/12/10 13:58 CDT, Christopher Bergqvist wrote:
 On Tue, Oct 12, 2010 at 2:37 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org
 <mailto:SeeWebsiteForEmail erdani.org>> wrote:

     assert(false) could be in an ideal world replaced by an intrinsic
     called e.g. halt() that looks and feels like a regular function but
     is recognized by the compiler. No new keyword would be needed. But I
     don't think that would mark a significant improvement in the language.


 Would it be possible to change the compiler to only treat
 "assert(false);" specially, avoiding treating "enum a = 0; assert(a);"
 or more complex constructs that way?

Question is when to stop. assert(0), assert(false), assert(1 == 0)... Andrei
Oct 12 2010
prev sibling next sibling parent Christopher Bergqvist <chris digitalpoetry.se> writes:
--000325556ffe9bcd520492701042
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Oct 12, 2010 at 2:37 AM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:

 assert(false) could be in an ideal world replaced by an intrinsic called
 e.g. halt() that looks and feels like a regular function but is recognized
 by the compiler. No new keyword would be needed. But I don't think that
 would mark a significant improvement in the language.

Would it be possible to change the compiler to only treat "assert(false);" specially, avoiding treating "enum a = 0; assert(a);" or more complex constructs that way? --000325556ffe9bcd520492701042 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Tue, Oct 12, 2010 at 2:37 AM, Andrei Alexandr= escu=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:SeeWebsiteForEmail erdani.or= g">SeeWebsiteForEmail erdani.org</a>&gt;</span>=A0wrote:<br><blockquote cla= ss=3D"gmail_quote" style=3D"margin-top: 0px; margin-right: 0px; margin-bott= om: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb= (204, 204, 204); border-left-style: solid; padding-left: 1ex; "> <div class=3D"im">assert(false) could be in an ideal world replaced by an i= ntrinsic called e.g. halt() that looks and feels like a regular function bu= t is recognized by the compiler. No new keyword would be needed. But I don&= #39;t think that would mark a significant improvement in the language.</div=

r to only treat &quot;assert(false);&quot; specially, avoiding treating &qu= ot;enum a =3D 0; assert(a);&quot; or more complex constructs that way?</div=

--000325556ffe9bcd520492701042--
Oct 12 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, October 12, 2010 13:40:32 Andrei Alexandrescu wrote:
 On 10/12/10 13:58 CDT, Christopher Bergqvist wrote:
 On Tue, Oct 12, 2010 at 2:37 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org
 
 <mailto:SeeWebsiteForEmail erdani.org>> wrote:
     assert(false) could be in an ideal world replaced by an intrinsic
     called e.g. halt() that looks and feels like a regular function but
     is recognized by the compiler. No new keyword would be needed. But I
     don't think that would mark a significant improvement in the
     language.
 
 Would it be possible to change the compiler to only treat
 "assert(false);" specially, avoiding treating "enum a = 0; assert(a);"
 or more complex constructs that way?

Question is when to stop. assert(0), assert(false), assert(1 == 0)... Andrei

If we were to make that change, I'd say to make it simple and just use assert(0) and assert(false), but it's certainly a valid point. Personally, I don't think that it's an issue because it's really only going to happpen with compile-time constants which wouldn't normally be in an assert statement anyway. - Jonathan M Davis
Oct 12 2010