In article [EMAIL PROTECTED] you write:
Both OpenSSL and Apache programmers did this, in carefully reviewed
code which was written in response to a security report. They simply
didn't know that there is a potential problem. The reason for this
gap in knowledge isn't quite clear to me.
Well,
Gabriel Dos Reis wrote:
You may not have noticed but this issue is primarily about C and C++
and we're discussing what the relevant standard says and what
engineering decision we would take. Please, let's not get into
more distractions. We already have plenty of them (many orginating
from
Gabriel Dos Reis wrote:
Then, one wonders why the GNAT is not bug free ;-p
Making programs bug free has more to it than understanding the language
you are writing in, but it is a useful step forward to avoid problems
that come from simply not knowing the rules of the language you are
writing
* Robert Dewar:
Making programs bug free has more to it than understanding the language
you are writing in, but it is a useful step forward to avoid problems
that come from simply not knowing the rules of the language you are
writing in (I can't guarantee that GNAT is bug free in that regard,
Florian Weimer wrote:
* Robert Dewar:
Making programs bug free has more to it than understanding the language
you are writing in, but it is a useful step forward to avoid problems
that come from simply not knowing the rules of the language you are
writing in (I can't guarantee that GNAT is
Robert Dewar [EMAIL PROTECTED] writes:
[...]
| The issue is whether they need to become expect in red herring or just
| know how to write good and correct programs. Interestingly, backis
| the old days KR put emphasis on how to write good and useful programs
| rather than academic exercise
* Robert Dewar:
I am puzzled, why would *ANYONE* who knows C use int
rather than unsigned if they want wrap around semantics?
Both OpenSSL and Apache programmers did this, in carefully reviewed
code which was written in response to a security report. They simply
didn't know that there is a
Florian Weimer [EMAIL PROTECTED] writes:
| * Robert Dewar:
|
| I am puzzled, why would *ANYONE* who knows C use int
| rather than unsigned if they want wrap around semantics?
|
| Both OpenSSL and Apache programmers did this, in carefully reviewed
| code which was written in response to a
On Sat, 2 Jul 2005, Florian Weimer wrote:
I am puzzled, why would *ANYONE* who knows C use int
rather than unsigned if they want wrap around semantics?
Both OpenSSL and Apache programmers did this, in carefully reviewed
code which was written in response to a security report. They simply
Florian Weimer wrote:
Probably it's hard to accept for hard-code C coders that a program
which generates correct machine code with all GCC versions released so
far (modulo bugs in GCC) can still be illegal C and exhibit undefined
behavior. IIRC, I needed quite some time to realize the full
Gabriel Dos Reis wrote:
We need to be careful not to to substitute illegal for undefined
behaviour. GCC is not a court.
Note that in Ada, illegal is a technical term, it refers to a program
that fails to meet the syntactic or static semantic rules for a correct
Ada program, and must be
Robert Dewar [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
|
| We need to be careful not to to substitute illegal for undefined
| behaviour. GCC is not a court.
|
| Note that in Ada,
You may not have noticed but this issue is primarily about C and C++
and we're discussing what the
Robert Dewar [EMAIL PROTECTED] writes:
| Florian Weimer wrote:
|
| Probably it's hard to accept for hard-code C coders that a program
| which generates correct machine code with all GCC versions released so
| far (modulo bugs in GCC) can still be illegal C and exhibit undefined
| behavior.
Does -ftrapv ever take advantage of trapping instructions where the
hardware has them available?
Yes, for example Alpha.
OK, but it's the only example. :-)
Does anyone make substantial use of -ftrapv in production
There are rarely bug reports about it; for example pointer difference
Andrew Pinski [EMAIL PROTECTED] writes:
| On Jun 28, 2005, at 1:12 AM, Gabriel Dos Reis wrote:
|
| Andrew Pinski [EMAIL PROTECTED] writes:
|
| | On Jun 28, 2005, at 12:34 AM, Gabriel Dos Reis wrote:
| |
| | The attitude that undefined behaviour should be interpreted
| | as we should not
On Tuesday 28 June 2005 07:12, Gabriel Dos Reis wrote:
For the concrete case at issue, if the hardware I'm writing the C/C++
programs for consistently displays modulo arithmetics for signed
integer type, Andrew can you tell me why GCC should deny me access
to that functionally where it
Steven Bosscher wrote on 28/06/2005 09:55:03:
On Tuesday 28 June 2005 07:12, Gabriel Dos Reis wrote:
For the concrete case at issue, if the hardware I'm writing the C/C++
programs for consistently displays modulo arithmetics for signed
integer type, Andrew can you tell me why GCC
Michael Veksler [EMAIL PROTECTED] writes:
So maybe introduce a -fsigned-wraps flag, that the user can use
to make 'int' wrap even in loops.
We have that already, it's called -fwrapv.
--
Falk
Gabriel Dos Reis wrote:
and it should also be able to take your life. Do you want it to actually
do it? If yes, I suggest you create your own compiler that does that
and leave us work on a compiler that does something more positive.
-- Gaby
Obviously no one programs a compiler to
Michael Veksler wrote:
I don't mind MAX_INT+1 being undefined by gcc. I object to drawing from
undefined to conclude that is_modulo should be true. This does not
make a practical sense. Drawing conclusions from undefined can yield
absurd results.
Yes, but trying to define what you mean by
Steven Bosscher [EMAIL PROTECTED] writes:
| On Tuesday 28 June 2005 07:12, Gabriel Dos Reis wrote:
| For the concrete case at issue, if the hardware I'm writing the C/C++
| programs for consistently displays modulo arithmetics for signed
| integer type, Andrew can you tell me why GCC should
Gabriel Dos Reis wrote:
The issue here is whether if the hardware consistently display a
semantics, GCC should not allow access to that consistent semantics
under the name that the standard says it is undefined behaviour.
Consider the case of converting a void* to a F*, where F is a function
Falk Hueffner [EMAIL PROTECTED] writes:
| Michael Veksler [EMAIL PROTECTED] writes:
|
| So maybe introduce a -fsigned-wraps flag, that the user can use
| to make 'int' wrap even in loops.
|
| We have that already, it's called -fwrapv.
In the case of C++, it leads to ODR violation because of
Gabriel Dos Reis wrote:
I saw your passsword example but I think it is largely beside the point.
I'm not interested in programming undefined behaviour. I'm looking
for way to take advantage of that liberty we accept more useful
programs where we can.
The password example is just an example
Robert Dewar [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
|
| The issue here is whether if the hardware consistently display a
| semantics, GCC should not allow access to that consistent semantics
| under the name that the standard says it is undefined behaviour.
| Consider the case
Robert Dewar [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
|
| I saw your passsword example but I think it is largely beside the point.
| I'm not interested in programming undefined behaviour. I'm looking
| for way to take advantage of that liberty we accept more useful
| programs
Gabriel Dos Reis wrote:
=
Please do remember that this is hardware dependent. If you have
problems with x86, it does not mean you have the same witha PPC or a
Sparc.
But the whole idea of hardware semantics is bogus, since you are
assuming some connection between C and the hardware which
Robert Dewar [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
| =
| Please do remember that this is hardware dependent. If you have
| problems with x86, it does not mean you have the same witha PPC or a
| Sparc.
|
| But the whole idea of hardware semantics is bogus, since you are
|
On Tue, Jun 28, 2005 at 02:32:04PM +0200, Gabriel Dos Reis wrote:
Robert Dewar [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
|
| The issue here is whether if the hardware consistently display a
| semantics, GCC should not allow access to that consistent semantics
| under the name
On Jun 28, 2005, at 9:46 AM, Gabriel Paubert wrote:
Now in practice what would be the cost of checking that the divisor
is -1 and take an alternate path that computes the correct
results (in modulo arithmetic) for this case ?
Small compared the division it self but if it is in an inner loop,
On Tue, Jun 28, 2005 at 08:57:20AM -0400, Robert Dewar wrote:
But the whole idea of hardware semantics is bogus, since you are
assuming some connection between C and the hardware which does not
exist. C is not an assembly language.
A non-negligible part of the use of C and even C++ is as a
- sizeof(int) == 4, sizeof(long long) == 8
I swear 16 bit compilers have sizeof(int) = 2 with sizeof(long) = 4
Gabriel Paubert wrote:
Now in practice what would be the cost of checking that the divisor
is -1 and take an alternate path that computes the correct
results (in modulo arithmetic) for this case ?
We actually had to do this on the x86 early on for GNAT, UGH!
Original Message
From: Olivier Galibert
Sent: 28 June 2005 15:25
In particular, a very large number of C and C++ programs are written
with the assumptions:
This is a bad line of reasoning in general. There is a vast amount of bad
software in the world, some blatantly buggy, some
On Tue, Jun 28, 2005 at 10:30:39PM +0800, Jonathan Wilson wrote:
- sizeof(int) == 4, sizeof(long long) == 8
I swear 16 bit compilers have sizeof(int) = 2 with sizeof(long) = 4
Yes, and some computers have 9-bit bytes too. Tried running linux,
gnome, kde, gimp, cdrecord, mame, qemu... on them
Olivier Galibert [EMAIL PROTECTED] writes:
| On Tue, Jun 28, 2005 at 08:57:20AM -0400, Robert Dewar wrote:
| But the whole idea of hardware semantics is bogus, since you are
| assuming some connection between C and the hardware which does not
| exist. C is not an assembly language.
|
| A
On Tue, Jun 28, 2005 at 03:39:38PM +0100, Dave Korn wrote:
Original Message
From: Olivier Galibert
Sent: 28 June 2005 15:25
In particular, a very large number of C and C++ programs are written
with the assumptions:
This is a bad line of reasoning in general. There is a vast
Olivier Galibert wrote:
IA-64 may have an issue with sizeof(void (*)()) from what I've heard,
but they have been laughed out of the market.
And this comment is supposed to be from the real world? I think not.
Olivier Galibert writes:
On Tue, Jun 28, 2005 at 03:39:38PM +0100, Dave Korn wrote:
Original Message
From: Olivier Galibert
Sent: 28 June 2005 15:25
In particular, a very large number of C and C++ programs are written
with the assumptions:
This is a bad line
On Tue, Jun 28, 2005 at 10:23:51AM +0300, Michael Veksler wrote:
On Jun 28, 2005, at 1:12 AM, Gabriel Dos Reis wrote:
So,
please, do refrain from reasoning like since we did X for Y and Y was
undefined behaviour, we should do the same for Z. Undefined
behaviour isn't a 0 or 1
On Tue, Jun 28, 2005 at 03:39:38PM +0100, Dave Korn wrote:
Original Message
From: Olivier Galibert
Sent: 28 June 2005 15:25
In particular, a very large number of C and C++ programs are written
with the assumptions:
This is a bad line of reasoning in general. There is a vast
On Tue, Jun 28, 2005 at 09:32:49AM -0700, Joe Buck wrote:
/* int a, b, c; */
if (b 0) {
a = b + c;
int count;
for (int i = c; i = a; i++)
count++;
some_func(count);
}
I forgot to initialize count to 0, of course.
In particular, a very large number of C and C++ programs are written
with the assumptions:
- signed and unsigned types are modulo, except in loop induction
variables where it's bad taste
Well, as demonstrated by INT_MIN/-1, gcc has NEVER fulfilled such assumptions
on i86 and, quite likely,
Joe Buck [EMAIL PROTECTED] writes:
| On Tue, Jun 28, 2005 at 10:23:51AM +0300, Michael Veksler wrote:
|
|
| On Jun 28, 2005, at 1:12 AM, Gabriel Dos Reis wrote:
| So,
|please, do refrain from reasoning like since we did X for Y and Y was
|undefined behaviour, we should do the same
Original Message
From: Joe Buck
Sent: 28 June 2005 17:42
On Tue, Jun 28, 2005 at 03:39:38PM +0100, Dave Korn wrote:
Original Message
From: Olivier Galibert
Sent: 28 June 2005 15:25
In particular, a very large number of C and C++ programs are written
with the assumptions:
On Tue, Jun 28, 2005 at 04:03:49PM +0100, Andrew Haley wrote:
Olivier Galibert writes:
On Tue, Jun 28, 2005 at 03:39:38PM +0100, Dave Korn wrote:
Original Message
From: Olivier Galibert
Sent: 28 June 2005 15:25
In particular, a very large number of C and C++
On Tue, Jun 28, 2005 at 06:10:26PM +0100, Dave Korn wrote:
- sizeof(int) == 4, sizeof(long long) == 8
- sizeof(long) == sizeof(void *) == sizeof(void (*)())
And what about 64 bit architectures? Your assumptions are already
widely invalid and only going to get more so.
No, all
On Tue, Jun 28, 2005 at 07:02:49PM +0200, Gabriel Dos Reis wrote:
| Since behavior on integer overflow is undefined, we can optimize assuming
| that overflow has not occurred. Then a c, so the for loop always
| executes b+1 times, and we end up with
|
| if (b 0)
| some_func(b+1);
On Tue, Jun 28, 2005 at 07:02:49PM +0200, Gabriel Dos Reis wrote:
We document that
a = (int) ((unsigned) b + c)
is well-defined and given by the wrapping semantics. Does the current
optimizer takes that into account or will it assume b+1 execution times?
I fixed this bug
Original Message
From: Olivier Galibert
Sent: 28 June 2005 18:18
On Tue, Jun 28, 2005 at 04:03:49PM +0100, Andrew Haley wrote:
Olivier Galibert writes:
On Tue, Jun 28, 2005 at 03:39:38PM +0100, Dave Korn wrote:
Original Message From: Olivier Galibert
Sent: 28 June
Gabriel Dos Reis writes:
Steven Bosscher [EMAIL PROTECTED] writes:
| On Tuesday 28 June 2005 07:12, Gabriel Dos Reis wrote:
| For the concrete case at issue, if the hardware I'm writing the C/C++
| programs for consistently displays modulo arithmetics for signed
| integer type, Andrew can you
On Tue, Jun 28, 2005 at 07:17:52PM +0200, Olivier Galibert wrote:
On Tue, Jun 28, 2005 at 04:03:49PM +0100, Andrew Haley wrote:
This is childish and insulting.
Calling a large part of the programs out there, including a non
negligible subpart of what I personally write either blatantly
On Tue, Jun 28, 2005 at 06:36:26PM +0100, Dave Korn wrote:
It certainly wasn't meant to be. It was meant to be a dispassionate
description of the state of facts. Software that violates the C standard
just *is* buggy or incorrect, and your personal pride has absolutely
nothing to do with
Joe Buck [EMAIL PROTECTED] writes:
| On Tue, Jun 28, 2005 at 07:02:49PM +0200, Gabriel Dos Reis wrote:
| | Since behavior on integer overflow is undefined, we can optimize assuming
| | that overflow has not occurred. Then a c, so the for loop always
| | executes b+1 times, and we end up with
Joe Buck [EMAIL PROTECTED] writes:
| On Tue, Jun 28, 2005 at 07:17:52PM +0200, Olivier Galibert wrote:
| On Tue, Jun 28, 2005 at 04:03:49PM +0100, Andrew Haley wrote:
| This is childish and insulting.
|
| Calling a large part of the programs out there, including a non
| negligible subpart
On Tue, Jun 28, 2005 at 10:50:39AM -0700, Joe Buck wrote:
On Tue, Jun 28, 2005 at 07:17:52PM +0200, Olivier Galibert wrote:
On Tue, Jun 28, 2005 at 04:03:49PM +0100, Andrew Haley wrote:
This is childish and insulting.
Calling a large part of the programs out there, including a non
Original Message
From: Olivier Galibert
Sent: 28 June 2005 19:02
On Tue, Jun 28, 2005 at 06:36:26PM +0100, Dave Korn wrote:
It certainly wasn't meant to be. It was meant to be a dispassionate
description of the state of facts. Software that violates the C standard
just *is* buggy
Original Message
From: Olivier Galibert
Sent: 28 June 2005 19:29
Incidentally, gcc itself makes most of these assumptions in its own
code. I kinda doubt you can run it on a dsp or a machine with 16-bits
ints. Which is different than generating code for them.
They aren't
Morten Welinder wrote on 28/06/2005 19:59:10:
In particular, a very large number of C and C++ programs are written
with the assumptions:
- signed and unsigned types are modulo, except in loop induction
variables where it's bad taste
Well, as demonstrated by INT_MIN/-1, gcc has
Olivier Galibert wrote:
Calling a large part of the programs out there, including a non
negligible subpart of what I personally write either blatantly buggy
or subtly-incorrect is somewhat childish and insulting.
nope, I don't see it that way at all, this is just a statement of fact
wrt the
Gabriel Dos Reis wrote:
But the compiler miscompiled the Unix kernel -- which, apart from has
history intermixed with the C language design, was relying on
undocumented aspect of undefined behaviour. Nobdoy was willing to
buy the compiler. The company ran out of business.
Could you please
On Tue, Jun 28, 2005 at 07:36:00PM +0100, Dave Korn wrote:
Original Message
From: Olivier Galibert
Sent: 28 June 2005 19:02
On Tue, Jun 28, 2005 at 06:36:26PM +0100, Dave Korn wrote:
It certainly wasn't meant to be. It was meant to be a dispassionate
description of the state
On Jun 28, 2005, at 3:10 PM, Olivier Galibert wrote:
Well, I don't utterly _anything_ about either his position or
yours. C is
not just a high level assembler, it has complex and abstract semantics
imposed on that;
Yes. But C is _also_ a high level assembler, and ignoring that is
On Tue, Jun 28, 2005 at 02:52:10PM -0400, Robert Dewar wrote:
Olivier Galibert wrote:
On Tue, Jun 28, 2005 at 06:36:26PM +0100, Dave Korn wrote:
It certainly wasn't meant to be. It was meant to be a dispassionate
description of the state of facts. Software that violates the C standard
Andrew Pinski wrote:
No it is not. It was when it was designed yes but since the C standard has
come out and the aliasing rules really show that it is not a high level
assembler language any more.
Even when it was designed there was more abstraction than you think (e.g.
cannot convert *char
I am puzzled, why would *ANYONE* who knows C use int
rather than unsigned if they want wrap around semantics?
Andrew Pinski [EMAIL PROTECTED] writes:
| On Jun 28, 2005, at 3:10 PM, Olivier Galibert wrote:
|
|
|Well, I don't utterly _anything_ about either his position or
| yours. C is
| not just a high level assembler, it has complex and abstract semantics
| imposed on that;
|
| Yes. But C
Gabriel Dos Reis wrote:
The strict aliasing rule by itself does not show it is not a high level
assembly language. There are chips out there where you cannot access
data willy-nilly through random register types.
And there are chips for which signed arithmetic is not wrap around!
Robert Dewar [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
| Robert Dewar [EMAIL PROTECTED] writes:
| | Olivier Galibert wrote:
| | | Calling a large part of the programs out there, including a non
| | negligible subpart of what I personally write either blatantly buggy
| | or
Andrew Pinski wrote:
The first change in GCC which changed signed overflow/wrapping to be
undefined
was added back in 1992 in loop.c.
Why are we talking about this now, instead of back
when they were added ?
Well, I don't know about the rest of the GCC developers at that time
(1992), but
Robert Dewar [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
|
| The strict aliasing rule by itself does not show it is not a high level
| assembly language. There are chips out there where you cannot access
| data willy-nilly through random register types.
|
| And there are chips for
Robert == Robert Dewar [EMAIL PROTECTED] writes:
Robert I am puzzled, why would *ANYONE* who knows C use int rather
Robert than unsigned if they want wrap around semantics?
Because most people don't follow the rule that always use unsigned
variables unless you know that it really needs to be
Paul Koning wrote:
And also because most people believe that C applies normal computer
arithmetic, and they believe that normal computer arithmetic is
wrapped 2's complement. (And indeed it usually is, give or take some
bizarre exceptions like MAX_INT % -1)
and not so bizarre exceptions like
Gabriel Dos Reis wrote:
C and C++ are general programming language geared toward system
programming.
Yes, and my two examples are completely consistent with that. A C
compiler that uses the trapping arithmetic on the MIPS is entirely
conforming, and has the advantage that if you develop
Gabriel Dos Reis wrote:
Robert Dewar [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
|
| The strict aliasing rule by itself does not show it is not a high level
| assembly language. There are chips out there where you cannot access
| data willy-nilly through random register types.
|
Robert Dewar [EMAIL PROTECTED] writes:
| has the semantics that Gabriel Dos Reis wants is not an evaluable
| predicate!
You completely missed the point, but I guess it is consistent with
your denying that there is any connection between C or C++ and
hardware.
-- Gaby
Robert Dewar [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
| Robert Dewar [EMAIL PROTECTED] writes:
| | Gabriel Dos Reis wrote:
| | | The strict aliasing rule by itself does not show it is not a
| high level
| | assembly language. There are chips out there where you cannot access
|
Gabriel Dos Reis wrote:
Robert Dewar [EMAIL PROTECTED] writes:
| has the semantics that Gabriel Dos Reis wants is not an evaluable
| predicate!
You completely missed the point, but I guess it is consistent with
your denying that there is any connection between C or C++ and
hardware.
So,
Robert Dewar [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
| Robert Dewar [EMAIL PROTECTED] writes:
| | has the semantics that Gabriel Dos Reis wants is not an evaluable
| | predicate!
| You completely missed the point, but I guess it is consistent with
| your denying that there is any
Gabriel == Gabriel Dos Reis [EMAIL PROTECTED] writes:
Robert Dewar [EMAIL PROTECTED] writes:
Gabriel Dos Reis wrote:
Robert Dewar [EMAIL PROTECTED] writes:
has the semantics that Gabriel Dos Reis wants is not an evaluable
predicate!
You completely missed the point, but I guess it is
On Tue, Jun 28, 2005 at 11:19:18PM +0200, Gabriel Dos Reis wrote:
Robert Dewar [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
| Robert Dewar [EMAIL PROTECTED] writes:
| | has the semantics that Gabriel Dos Reis wants is not an evaluable
| | predicate!
| You completely missed the
Paul Koning [EMAIL PROTECTED] writes:
Gabriel == Gabriel Dos Reis [EMAIL PROTECTED] writes:
Gabriel When it comes down for the compiler writer to chose
Gabriel something for undefined behaviour, it is hardly solely based
Gabriel on the C standard. In fact, the C standard is of much less
On Tue, Jun 28, 2005 at 04:24:38PM -0400, Robert Dewar wrote:
Paul Koning wrote:
And also because most people believe that C applies normal computer
arithmetic, and they believe that normal computer arithmetic is
wrapped 2's complement. (And indeed it usually is, give or take some
bizarre
On Tue, Jun 28, 2005 at 03:31:59PM -0400, Robert Dewar wrote:
Gabriel Dos Reis wrote:
The strict aliasing rule by itself does not show it is not a high level
assembly language. There are chips out there where you cannot access
data willy-nilly through random register types.
And there are
On Tue, Jun 28, 2005 at 03:20:01PM -0400, Robert Dewar wrote:
Andrew Pinski wrote:
No it is not. It was when it was designed yes but since the C standard has
come out and the aliasing rules really show that it is not a high level
assembler language any more.
Even when it was designed
On Tue, Jun 28, 2005 at 02:44:40PM -0700, Joe Buck wrote:
I challenge you, Robert, to find us a C compiler that generates trapping
instructions for integer adds by default. I do not believe that such a
compiler exists.
Perusing the manpage of SGI's cc and CC on IRIX, there isn't even an
Robert Dewar wrote on 28/06/2005 22:20:56:
I am puzzled, why would *ANYONE* who knows C use int
rather than unsigned if they want wrap around semantics?
int saturated_mul(int a, int b)
{
int ret= a*b;
if (a == 0 || ret % a == 0)
return ret;
else if ( (a0) == (b0) ) //
Gabriel Dos Reis wrote:
In case you may not have noticed, people offered to run tests and send
some numbers.
Right, I think further discussion until these numbers arrive is of
dubious value, so I am suspending the thread till later :-)
Joe Buck wrote:
I challenge you, Robert, to find us a C compiler that generates trapping
instructions for integer adds by default. I do not believe that such a
compiler exists.
Probably there is no production compiler that does, MIPS would be the only
possibility I think in practice.
On Jun 28, 2005, at 5:57 AM, Robert Dewar wrote:
C is not an assembly language.
My head explodes.
On Tue, 28 Jun 2005, Robert Dewar wrote:
are preserved. For instance on the IBM mainframe one might use signed
or unsigned operations to implement int operations. On the original
MIPS one might use trapping or non-trapping arithmetic (either would
be valid).
Does -ftrapv ever take advantage
Joseph S. Myers [EMAIL PROTECTED] writes:
Does -ftrapv ever take advantage of trapping instructions where the
hardware has them available?
Yes, for example Alpha.
Does anyone make substantial use of -ftrapv in production
There are rarely bug reports about it; for example pointer difference
Joseph S. Myers wrote:
Does anyone make substantial use of -ftrapv in production (whether as a
tool for detecting bugs, or as a security tool where the performance cost
is acceptable)? Or is it still at the stage of being a tool which would
be useful in principle for some purposes but still
Joe Buck wrote:
32-bit integers are going to remain useful types, and
LP64 architectures finally have char = 8, short = 16, int = 32, long = 64,
which is too useful to break.
Hmm... pratically,
Handle and Pointer Sizes in
Gabriel Dos Reis wrote:
Robert Dewar [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
|
| But the whole idea of hardware semantics is bogus, since you are
| assuming some connection between C and the hardware which does not
| exist. C is not an assembly language.
If you live in a
Michael Veksler wrote on 29/06/2005 00:53:33:
Robert Dewar wrote on 28/06/2005 22:20:56:
I am puzzled, why would *ANYONE* who knows C use int
rather than unsigned if they want wrap around semantics?
int saturated_mul(int a, int b)
{
int ret= a*b;
if (a == 0 || ret % a == 0)
Georg Bauhaus [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
| Robert Dewar [EMAIL PROTECTED] writes:
| | Gabriel Dos Reis wrote:
| | | But the whole idea of hardware semantics is bogus, since you are
| | assuming some connection between C and the hardware which does not
| | exist. C is
Gabriel Dos Reis wrote:
C is
trustworthy (and preferred over SML for that curcial part of the proof
checker) because the mapping of the C code to the generated assembly
code is straighforward and amenable to inspection.
This kind of traceability is of course vital for such applications, but
Robert Dewar [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
|
| C is
| trustworthy (and preferred over SML for that curcial part of the proof
| checker) because the mapping of the C code to the generated assembly
| code is straighforward and amenable to inspection.
|
| This kind of
Gabriel Dos Reis wrote:
Robert Dewar [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
|
| C is
| trustworthy (and preferred over SML for that curcial part of the proof
| checker) because the mapping of the C code to the generated assembly
| code is straighforward and amenable to
1 - 100 of 109 matches
Mail list logo
