code gone from cc

[erik quanstrom]

i added the part of this because the compiler wasn't
catching mod-by-zero (i'll try to find the code, it was
a complicated constant expression that was zero).
in any event, the test for divide by zero was always
there.

since this case was completely deleted, can someone
tell me where is this case caught now?

- erik

----

com.c:1032,1055 - /mnt/term/usr/quanstro/nix//sys/src/cmd/cc/com.c:1032,1037
case OASADD:
ccom(l);
ccom(r);
- if(n->op == OASMOD || n->op == OASLMOD || n->op == OASDIV || n->op == OASLDIV)
- if(r->op == OCONST){
- if(!typefd[r->type->etype] && r->vconst == 0) {
- if(n->op == OASMOD || n->op == OASLMOD)
- diag(n, "modulo by zero");
- else
- diag(n, "divide by zero");
- r->vconst = ~0;
- }
- if(typefd[r->type->etype] && r->fconst == 0.) {
- if(n->op == OASMOD || n->op == OASLMOD)
- diag(n, "modulo by zero");
- else
- diag(n, "divide by zero");
- r->fconst = 1e10;
- }
- }
-
if(n->op == OASLSHR || n->op == OASASHR || n->op == OASASHL)
if(r->op == OCONST) {
t = n->type->width * 8; /* bits per byte */

[Francisco J Ballesteros]

was it in plan 9?
was it deleted by the merge of plan 9 changes?

[Charles Forsyth]

that was not in Plan 9

[erik quanstrom]

On Thu Mar 8 08:19:25 EST 2012, charles...@gmail.com wrote:

> that was not in Plan 9

you're right. why not? i couldn't find my test code,
and my naive test gets caught by scon.

i think i added this code after somebody crashed the
compiler.

- erik

[Charles Forsyth]

I don't quite see how you'd crash the compiler with /= %= etc because the left-hand side is an lvalue, and it's not going to go near compile-time evaluation in that case.

[erik quanstrom]

i knew it was sneaky

; cat ccbug.c
#include <u.h>
#include <libc.h>

void
main(void)
{
uvlong v;

v = 0;
v /= 1 / 100;
v %= 1/100;
}
ladd; /n/sources/plan9/386/bin/8c ccbug.c
ladd; 8c ccbug.c
ccbug.c:10 divide by zero
ccbug.c:11 modulo by zero

[erik quanstrom]

charles, did you come to a conclusion on this?
i've become partial to this warning message
(as it prevents angry c compiler users), so i'm keeping
it regardless.

- erik

[Charles Forsyth]

People do that a lot? Unlike (say) silent overflow, div or mod by zero immediately produces a trap.

It seemed to me that if anything, the diagnostic ought to be for 1/100, nothing

to do with the application of the result.

i don't know how much the compiler should look for such bugs. for instance, suppose v is real. then 1/100 "probably" was meant to be 0.01, but it will be zero, so the problem is both v should be real and 1/100 should be real too.

i'd have thought as many problems arise from mixed-mode arithmetic:

  v * (1/100)

which currently won't be diagnosed either.

[erik quanstrom]

On Wed Apr 11 18:08:43 EDT 2012, charles...@gmail.com wrote:

> People do that a lot? Unlike (say) silent overflow, div or mod by zero
> immediately produces a trap.
> It seemed to me that if anything, the diagnostic ought to be for 1/100,
> nothing
> to do with the application of the result.

remember this is a clarified example. the original code had some defines
or enums which occulted the actual arithmetic in question. then in a
header file, the constant used as the divisor was changed in a seemingly
sensible way. the results unfortunately, were surprising and not sensible.

> i'd have thought as many problems arise from mixed-mode arithmetic:
> v * (1/100)
> which currently won't be diagnosed either.

it could be.

- erik