On Saturday, 14 October 2017 at 09:32:32 UTC, Timon Gehr wrote:
The compiler can easily prove that the value of data.length
does not change between the two points in the program.
According to the specification, the behavior of the program is
undefined in case the assertion fails, not just the b
On 14.10.2017 23:36, kdevel wrote:
On Saturday, 14 October 2017 at 09:32:32 UTC, Timon Gehr wrote:
Also, UB can and does sometimes mean that the program can execute
arbitrary code. It's called "arbitrary code execution":
https://en.wikipedia.org/wiki/Arbitrary_code_execution
This confuses dif
On Saturday, 14 October 2017 at 09:32:32 UTC, Timon Gehr wrote:
Also, UB can and does sometimes mean that the program can
execute arbitrary code. It's called "arbitrary code execution":
https://en.wikipedia.org/wiki/Arbitrary_code_execution
This confuses different levels of reasoning. In C/C++
On 14.10.2017 07:20, Jesse Phillips wrote:
On Thursday, 12 October 2017 at 15:37:23 UTC, John Burton wrote:
This is an example of what I mean :-
undefined what it is meant to do anyway, so the compiler can
"optimize" out the if condition as it only affects the case where the
language doesn't
On Saturday, October 14, 2017 05:20:47 Jesse Phillips via Digitalmars-d-
learn wrote:
> The point is assert tells the compiler something it can use to
> reason about its job, not that it can insert additional runtime
> checks to see if you code is invalid an then add new jumps to
> execute whatever
On Thursday, 12 October 2017 at 15:37:23 UTC, John Burton wrote:
This is an example of what I mean :-
undefined what it is meant to do anyway, so the compiler can
"optimize" out the if condition as it only affects the case
where the language doesn't define what it's supposed to do
anyway, an
On Friday, October 13, 2017 11:26:54 kdevel via Digitalmars-d-learn wrote:
> On Friday, 13 October 2017 at 02:22:24 UTC, Jonathan M Davis
>
> wrote:
> > You've told it that i should never be 3 at that point and that
> > it's a bug if it is, and as such, it is free to assume that i
> > is never 3 af
On Friday, 13 October 2017 at 02:22:24 UTC, Jonathan M Davis
wrote:
You've told it that i should never be 3 at that point and that
it's a bug if it is, and as such, it is free to assume that i
is never 3 after the assertion even if the assertion is
compiled out with -release - that is the only
On Thursday, October 12, 2017 21:22:29 kdevel via Digitalmars-d-learn wrote:
> On Thursday, 12 October 2017 at 20:27:03 UTC, Jonathan M Davis
>
> wrote:
> > On Thursday, October 12, 2017 20:15:41 kdevel via
> >
> >> ---
> >> void main ()
> >> {
> >>
> >> assert (false);
> >>
> >> }
> >> ---
> >
On Thursday, 12 October 2017 at 20:27:03 UTC, Jonathan M Davis
wrote:
On Thursday, October 12, 2017 20:15:41 kdevel via
---
void main ()
{
assert (false);
}
---
qualifies as "invalid, and therefore has undefined behaviour."
A statement, which makes no sense to me. Either it is a
"debuggin
On Thursday, October 12, 2017 20:15:41 kdevel via Digitalmars-d-learn wrote:
> On Thursday, 12 October 2017 at 15:37:23 UTC, John Burton wrote:
> > C++ compilers can and do perform such optimizations so I was
> > wondering if assert in D could cause such behavior according to
> > the spec.
>
> In t
On Thursday, 12 October 2017 at 15:37:23 UTC, John Burton wrote:
C++ compilers can and do perform such optimizations so I was
wondering if assert in D could cause such behavior according to
the spec.
In the context of ISO-C++ it is meaningless to reason about the
"actual behavior" of a non-co
On Thursday, 12 October 2017 at 14:22:43 UTC, Timon Gehr wrote:
On 11.10.2017 11:27, John Burton wrote:
Yes, that's what it is saying. (The other answers, that say or
try to imply that this is not true or true but not a bad thing,
are wrong.)
...
However, in practice, I think none of the
On 11.10.2017 11:27, John Burton wrote:
The spec says this :-
"As a contract, an assert represents a guarantee that the code must
uphold. Any failure of this expression represents a logic error in the
code that must be fixed in the source code. A program for which the
assert contract is false
On Wednesday, 11 October 2017 at 09:39:04 UTC, user1234 wrote:
On Wednesday, 11 October 2017 at 09:27:49 UTC, John Burton
wrote:
[...]
I therefore feel like I ought to not use assert and should
instead validate my assumptions with an if statement and a
throw or exit or something.
Yes, that's
On 10/11/2017 02:27 AM, John Burton wrote:
> The spec says this :-
>
> "As a contract, an assert represents a guarantee that the code must
> uphold. Any failure of this expression represents a logic error in the
> code that must be fixed in the source code. A program for which the
> assert contrac
On Wednesday, October 11, 2017 09:27:49 John Burton via Digitalmars-d-learn
wrote:
> The spec says this :-
>
> "As a contract, an assert represents a guarantee that the code
> must uphold. Any failure of this expression represents a logic
> error in the code that must be fixed in the source code.
On Wednesday, 11 October 2017 at 09:27:49 UTC, John Burton wrote:
[...]
I therefore feel like I ought to not use assert and should
instead validate my assumptions with an if statement and a
throw or exit or something.
Yes, that's the way of doing. assert() are just used to test the
program.
On 11/10/2017 10:27 AM, John Burton wrote:
The spec says this :-
"As a contract, an assert represents a guarantee that the code must
uphold. Any failure of this expression represents a logic error in the
code that must be fixed in the source code. A program for which the
assert contract is fa
The spec says this :-
"As a contract, an assert represents a guarantee that the code
must uphold. Any failure of this expression represents a logic
error in the code that must be fixed in the source code. A
program for which the assert contract is false is, by definition,
invalid, and therefo
20 matches
Mail list logo
