«

Le 29/12/10 19:24, christian.bau a écrit :
> On Dec 29, 5:44 pm, jacob navia<ja...@spamsink.net> wrote:
>
>> Many implementations of calloc(count size) just multiply count*size
>> ignoring overflow with catastrophic results. We had a discussion about
>> that in comp.lang.c
>
> See, you are lacking _precision_.
>
> If an implementation of calloc written in C just multiplies its two
> arguments of type size_t, there _cannot_ be an overflow. The result
> can be a number that is much too small for (count) elements of (size)
> bytes each, but it's not an overflow.

Of course a cat isn't a cat. It is "felis domesticus".

How can you DARE just call it a cat?



YES, there is no overflow OF COURSE.

but... as you yourself said:

> The result
> can be a number that is much too small for (count) elements of (size)
> bytes each

jacob

P.S. your idea of an argument to _overflow() is quite clever.
Thanks for that, I think I will change lcc-win for it,
since the generated
code is exactly the same as if you write

c = a+b;
if (_overflow())

-->

if (_overflow(a+b))

Looks much better and generates the same code:
movl a,%eax
movl b,%ecx
addl %eax,%ecx
movl $0,%eax
seto %al

Now, eax contains either 1 or zero depending on
the value in the overflow flag.

The pseudofunction _overflow() will just generate the
conditional jump, and the arguments will be evaluated as
normal function arguments that aren't pushed in the stack

"jacob navia" <> wrote in message
news:ifg6aa$vim$...
> Le 29/12/10 19:24, christian.bau a écrit :

[
>> Better solution:
>>
>> bool _overflow (int arg);
]

> P.S. your idea of an argument to _overflow() is quite clever.
> Thanks for that, I think I will change lcc-win for it,
> since the generated
> code is exactly the same as if you write
>
> c = a+b;
> if (_overflow())
>
> -->
>
> if (_overflow(a+b))
>
> Looks much better and generates the same code:
> movl a,%eax
> movl b,%ecx
> addl %eax,%ecx
> movl $0,%eax
> seto %al
>
> Now, eax contains either 1 or zero depending on
> the value in the overflow flag.

I thought the proposal was quite different: to be able to specify an
expression of any complexity, and perhaps to bail out as soon as any
overflow status is seen.

Keeping _overflow() distinct from the expression also makes it easier to
make it optional.

--
Bartc

Le 29/12/10 22:29, BartC a écrit :
>
> I thought the proposal was quite different: to be able to specify an
> expression of any complexity, and perhaps to bail out as soon as any
> overflow status is seen.
>

You obtain that if you set the

#pragma overflow on/off

construct.


But that will check ALL expressions and ALL concerned integer
operations. If you are interested in a few operations only,
this second form is much better.

> Keeping _overflow() distinct from the expression also makes it easier to
> make it optional.

Of course not.

Look:

#ifndef STDC_OVERFLOW_SUPPORT
#define _overflow(a) a
#endif

jacob navia <> writes:
> Le 28/12/10 22:46, Keith Thompson a écrit :
[...]
>> I'm almost tempted to suggest that adding exception handling to
>> the language might not be a completely horrible idea.
>>
> lcc-win proposes:

Can you clarify what you mean by "lcc-win proposes"? If you're
proposing that this should be added to a future C standard, it would
make more sense to say that *you* propose it; if not, I suggest that
"lcc-win implements" would make more sense. (I'm not picking on you,
just trying to understand.)

> int a,b,c;
> // ...
> c = a+b;
> if (_overflow()) {
> }
>
> What's wrong with that?

I won't say there's something *wrong* with it, and it's better
than nothing, but the precise semantics of _overflow() are not
at all obvious. It shares the same problems we already have with
errno, except that it applies to operators with expressions rather
than function calls. For one thing, unlike C++-style exceptions,
it's not scoped. Suppose I write:

x = y * z;
c = a + b;
if (_overflow()) {
...
}

If the multiplication overflows and the addition doesn't, what does
_overflow() return? What if there are multiple operations within
an expression? If each operation clears the overflow flag, undefined
evaluation orders mean that you can't safely use _overflow() unless
you restrict yourself to very simple expressions. And if it's
"sticky", is there a separate operation that clears the flag?

You probably have specific answers to most or all of these questions.
My point is that it's not obvious at the language level what those
answers should be.

I suggest that a mechanism that tells you whether an overflow
occurred anywhere within a specified chunk of code, perhaps
within the execution of a given expression, would be clearer.
Perhaps something like:

if (_overflow(c = a + b)) {
/* an overflow occurred */
}
else {
/* no overflow occurred */
}

Or just C++-like exception handling, for which we have ample existing
practice.

> In i386asm:
> addl %eax,%ecx
> jo _overflowhandler

If this were to be added to the language, its semantics would have
to be defined in terms of actual program behavior, not in terms of
x86 instructions. Not all CPUs have overflow flags that behave
exactly like the x86 overflow flag.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

BGB <> writes:
> On 12/28/2010 2:46 PM, Keith Thompson wrote:
[...]
>> I'm almost tempted to suggest that adding exception handling to
>> the language might not be a completely horrible idea.
>>
>
> one could use thread-local storage for this...
>
> AFAIK pretty much all (common?) OS's with threads also provide for TLS
> and similar...
>
> if errno was accessed via a function call, little would stop putting
> this in TLS as well (however, as-is, doing so requires using compiler
> specific extensions, such as the "__thread" modifier or similar for
> MSVC, ...).

No compiler magic is needed. The standard specifically says that
errno is a macro that expands to a modifiable lvalue. For example,
on one implementation it expands to (*__errno_location ());
presumably the __errno_location function returns a pointer to an
object in thread-local storage, at least for programs that use
threading.

> this way, one doesn't need to bother with providing a convoluted API to
> manage status, ....
>
> for example, AFAIK, OpenGL contexts are often handled via TLS, ...
>
> or such...

Sure, and as we've seen over the last N decades this is usable. But
it's not terribly clean.

One consequence of the use of errno is that this expression:

sin(x) + cos(x)

may invoke undefined behavior. If sin() and cos() are both
implemented as macros, it could modify the object referred to
by errno twice between sequence points. (I suspect this doesn't
cause problems on any real-world implementations, but the potential
is there.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

jacob navia <> writes:
[...]
> There is no processor that hasn't an overflow flag.
[...]

I don't believe this is correct. In fact I seem to recall that
concrete counterexamples have been posted here.

And even if you're right, are you sure that all CPUs' overflow
flags behave the same way as the x86 overflow flag?

Performing a simple arithmetic operation with a check for overflow
is a fundamental operation, and I do find it frustrating that C
doesn't support it directly and makes it inordinately difficult to
support it indirectly. I'd love to see a good clean way to do this.
I just don't think that adding an intrinsic that queries the overflow
flag is the way to do it.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

jacob navia <> writes:
> Le 29/12/10 15:34, christian.bau a écrit :
[...]
>> What _precisely_ is the semantics of the "_overflow" function?
>
> It returns 1 if the last operation overflowed, zero if not.
> Concerned operations: signed +,-,*, and /.

What about shift operators? ++? --? Conversions? Array indexing?
Pointer arithmetic? What about division by 0? What *exactly*
does "the last operation" mean?

[...]
> What bothers me is that you seem so upset that I offer a SOLUTION
> instead of just allowing UB. Maybe you can offer a BETTER solution?
>
> I am all ears.

Nobody is upset with you for offering a solution. We are offering
criticisms of the solution you're offering. If you don't want
criticism, I suggest not posting here. (That last was not meant
seriously; what I actually suggest is that you post here *and*
accept criticism.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

"jacob navia" <> wrote in message
news:ifg9hp$7hm$...
> Le 29/12/10 22:29, BartC a écrit :
>>
>> I thought the proposal was quite different: to be able to specify an
>> expression of any complexity, and perhaps to bail out as soon as any
>> overflow status is seen.
>>
>
> You obtain that if you set the
>
> #pragma overflow on/off
>
> construct.
>
>
> But that will check ALL expressions and ALL concerned integer
> operations. If you are interested in a few operations only,
> this second form is much better.

OK. It's that clear exactly how _overflow() works. Your docs suggest that it
simply returns the processor's overflow flag, rather than a separate
'sticky' flag.

In what way does turning on this pragma change that?

And what would the new code look like when used as:

if (_overflow(a+b+c))... ?


>> Keeping _overflow() distinct from the expression also makes it easier to
>> make it optional.
>
> Of course not.
>
> Look:
>
> #ifndef STDC_OVERFLOW_SUPPORT
> #define _overflow(a) a
> #endif

I was thinking of just commenting out the overflow checking lines...

--
Bartc

Le 29/12/10 22:54, Keith Thompson a écrit :
> jacob navia<> writes:
>> Some people here aren't aware of the problems overflow can produce. Just
>> remember the calloc example
>>
>> Many implementations of calloc(count size) just multiply count*size
>> ignoring overflow with catastrophic results. We had a discussion about
>> that in comp.lang.c
>
> Such implementations are non-conforming.
>

Bugs are non-conforming, Mr Thompson. And calling them names
will not make them go away.

Le 29/12/10 22:45, Keith Thompson a écrit :
> jacob navia<> writes:
> [...]
>> There is no processor that hasn't an overflow flag.
> [...]
>
> I don't believe this is correct. In fact I seem to recall that
> concrete counterexamples have been posted here.
>

Sure the DeathStar 9000... I know. But in that machine you can
always test for overflow as stated in the FAQ...


> And even if you're right, are you sure that all CPUs' overflow
> flags behave the same way as the x86 overflow flag?
>

I haven't come around a processor that couldn't test for overflow.

Maybe there are some micro-controllers that do not have that, but...

who cares?


> Performing a simple arithmetic operation with a check for overflow
> is a fundamental operation, and I do find it frustrating that C
> doesn't support it directly and makes it inordinately difficult to
> support it indirectly. I'd love to see a good clean way to do this.
> I just don't think that adding an intrinsic that queries the overflow
> flag is the way to do it.
>

I have never said that there should be "an intrinsic". That is how
it can be implemented it in the Power PC, for instance, or in the intel
machines, but it could be implemented differently in other machines.

You are reading things I did not write. Please keep centered in
what I actually said.

Thanks