Joe Buck <[EMAIL PROTECTED]> writes:
| On Sat, Jul 02, 2005 at 07:15:17PM -0400, Robert Dewar wrote:
| > Gabriel Dos Reis wrote:
| > >
| > > for (int i = min; i < max; ++i)
| > >
| > >
| > >and i, min and max don't change in the body, no matter what you think
| > >of C's general "for"
Robert Dewar <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| >for (int i = min; i < max; ++i)
| >
| > and i, min and max don't change in the body, no matter what you think
| > of C's general "for" not being a FOR loop, the above is a FOR loop.
|
| But this normal paradigm
On Sat, Jul 02, 2005 at 07:15:17PM -0400, Robert Dewar wrote:
> Gabriel Dos Reis wrote:
> >
> > for (int i = min; i < max; ++i)
> >
> >
> >and i, min and max don't change in the body, no matter what you think
> >of C's general "for" not being a FOR loop, the above is a FOR loop.
>
> B
Gabriel Dos Reis wrote:
for (int i = min; i < max; ++i)
and i, min and max don't change in the body, no matter what you think
of C's general "for" not being a FOR loop, the above is a FOR loop.
But this normal paradigm for representing a FOR loop does not work for
all possible
Robert Dewar <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| > As we have briefly discussed in mails, the most critical part of the
| > issue seems to be what can be assumed for loop variables. I countend
| > that for many if not most practical loops, the variable can be assumed
| > no
Gabriel Dos Reis wrote:
As we have briefly discussed in mails, the most critical part of the
issue seems to be what can be assumed for loop variables. I countend
that for many if not most practical loops, the variable can be assumed
not to overflow and apply the transformation. But we need not
Paul Schlie wrote:
My primary concern is about predictability, and could live with undefined
integer overflow if it were likely reasonably possible to verify that in
the general case an overflow would not occur, as otherwise an undefined
behavior may result. (which I can't believe is acceptable
Andrew Pinski wrote:
But the reason question is why make it an undefined behavior instead of
an implementation defined? This would have made it clearer instead of
allowing the compiler not document what happens. Or is C++
just following C here? In which case it might be better to ask the C
co
Gabriel Dos Reis wrote:
What I'm claiming is that he thinks "undefined behaviour" in the
standard should not be taken as meaning "go to hell" (or punishment to
borrow words from you) or absolute liberty for compiler writers to do
just about everything that is imaginable, regardless of expectatio
Andrew Pinski <[EMAIL PROTECTED]> writes:
| On Jul 1, 2005, at 12:49 AM, Gabriel Dos Reis wrote:
|
| >
| > As I said, if you let user tell you that his loop behaves well, i.e.
| > bounds do not rely on wrapping semantics, and yet he writes his loop to
| > deceive the compiler, then he loses. Let
Andrew Pinski <[EMAIL PROTECTED]> writes:
| On Jul 1, 2005, at 12:06 AM, Gabriel Dos Reis wrote:
| >
| > There are of course coner and pathological cases, but I don't think we
| > should worry too much about missing them. Let's first cover the
| > structured loops, and address the contorsed ones
On Jul 1, 2005, at 12:49 AM, Gabriel Dos Reis wrote:
As I said, if you let user tell you that his loop behaves well, i.e.
bounds do not rely on wrapping semantics, and yet he writes his loop to
deceive the compiler, then he loses. Let him choose his own poinson,
don't think you have to choose
On Jul 1, 2005, at 12:06 AM, Gabriel Dos Reis wrote:
There are of course coner and pathological cases, but I don't think we
should worry too much about missing them. Let's first cover the
structured loops, and address the contorsed ones later if they become
really important.
And I just submi
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Fri, 2005-07-01 at 03:39 +0200, Gabriel Dos Reis wrote:
| > Joe Buck <[EMAIL PROTECTED]> writes:
| >
| > | On Thu, Jun 30, 2005 at 09:02:48PM -0400, Andrew Pinski wrote:
| > | > But the reason question is why make it an undefined behavior instead of
On Fri, 2005-07-01 at 03:39 +0200, Gabriel Dos Reis wrote:
> Joe Buck <[EMAIL PROTECTED]> writes:
>
> | On Thu, Jun 30, 2005 at 09:02:48PM -0400, Andrew Pinski wrote:
> | > But the reason question is why make it an undefined behavior instead of
> | > an implementation defined? This would have mad
Joe Buck <[EMAIL PROTECTED]> writes:
| On Thu, Jun 30, 2005 at 09:02:48PM -0400, Andrew Pinski wrote:
| > But the reason question is why make it an undefined behavior instead of
| > an implementation defined? This would have made it clearer instead of
| > allowing the compiler not document what h
> Joe Buck <[EMAIL PROTECTED]>
> Undefined behavior doesn't mean that we should attempt to arbitrarily
> punish those who cross the line; that's why I don't think forcing integer
> overflows to trap (at least by default) is a good idea. In many cases,
> "assume no overflow, but don't trap" can pro
On Thu, Jun 30, 2005 at 09:02:48PM -0400, Andrew Pinski wrote:
> But the reason question is why make it an undefined behavior instead of
> an implementation defined? This would have made it clearer instead of
> allowing the compiler not document what happens. Or is C++
> just following C here? I
Andrew Pinski <[EMAIL PROTECTED]> writes:
| On Jun 30, 2005, at 8:48 PM, Gabriel Dos Reis wrote:
|
| > | Really? You've talked to Stroustrup?
| >
| > I work with him on daily basis, and as a matter of fact we've discussed
| > the heart of this topic of this thread yesterday over lunch. But, as
> Joe Buck <[EMAIL PROTECTED]>
> Undefined behavior doesn't mean that we should attempt to arbitrarily
> punish those who cross the line; that's why I don't think forcing integer
> overflows to trap (at least by default) is a good idea. In many cases,
> "assume no overflow, but don't trap" can pro
On Jun 30, 2005, at 8:48 PM, Gabriel Dos Reis wrote:
| Really? You've talked to Stroustrup?
I work with him on daily basis, and as a matter of fact we've discussed
the heart of this topic of this thread yesterday over lunch. But, as
much as I hate argument by authority I could not let this d
Joe Buck <[EMAIL PROTECTED]> writes:
| On Fri, Jul 01, 2005 at 12:25:58AM +0200, Gabriel Dos Reis wrote:
| > Joe Buck <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | Given your biases, you might be happier with Java as a language (than C or
| > | C++). The Java language designers decided to
On Fri, Jul 01, 2005 at 12:25:58AM +0200, Gabriel Dos Reis wrote:
> Joe Buck <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | Given your biases, you might be happier with Java as a language (than C or
> | C++). The Java language designers decided to strictly define many cases
> | that are not defined
Joe Buck <[EMAIL PROTECTED]> writes:
[...]
| Given your biases, you might be happier with Java as a language (than C or
| C++). The Java language designers decided to strictly define many cases
| that are not defined in C (example: the order side effects is always
| strictly left to right, float
On Thu, Jun 30, 2005 at 03:14:54PM -0400, Paul Schlie wrote:
> Given that the formal implication of GCC's choice not define signed integer
> overflow semantics as being other than undefined will be to guaranteed that
> all programs, with reachable signed integer arithmetic operations which can
> no
(sorry, meant additive/multiplicative inverse +/- MAX/MIN_ value;
but even that's wrong, which is why it seems that leaving signed overflow
as being undefined is such a bad idea, as it becomes correspondingly very
difficult to even try determine if a program is warranted to have a
deterministic
Given that the formal implication of GCC's choice not define signed integer
overflow semantics as being other than undefined will be to guaranteed that
all programs, with reachable signed integer arithmetic operations which can
not warrant that their respective operand expressions are recursively
c
27 matches
Mail list logo
