Messages in this thread | | | From | "Khimenko Victor" <> | Date | Sun, 17 May 1998 22:41:49 +0400 (MSD) | Subject | Re: Egcs 1.0.3 & Linux |
| |
PB> Interesting point ... PB> PB> "A month of sundays ago Khimenko Victor wrote:" PB> > PB> > #include <stdio.h> PB> > int a=0; PB> > int f(void) { a=1;return 1; } PB> > void main(void) { printf("%d",f()+a); } PB> PB> Of course this is really PB> PB> print (a=1)+a PB> PB> in disguise, and depends on the order of evaluation of expressions with PB> side effects. PB> Yes. But some compilers will warn you about (a=1)+a all known to me will not warn about program above.
PB> > Of course this code contains nasty bug and two compilers could generate two PB> > programs with different behaviour -- one will write 1 and other will write 2. PB> PB> Indeed. Indeed the code is not in error. PB> PB> > if code is compiled bu compiler without bugs and works just fine still does PB> > not mean that code does not contains bugs! And looks like it's possible to PB> > prove that you could not write program able to catch all such bugs (this is PB> PB> You are asking if a compiler can detect when the defined semantics of the PB> programming language does not assign a uniquely determined semantics to PB> a given program? Durrrrrrrrrrrrr ... well if it could, then I could PB> take any program A(x) and write the program A'[k];B, where B is your PB> example program above and A'[k] is the version of A with all its printfs PB> removed and an "x=k;" inserted at the beginning, so that it can't do PB> anything except terminate or not. PB> PB> A'[k];B is a nondeterministic program precisely when A(k) halts (because PB> B can be any of two things) and deterministic when A(k) does not halt PB> (it does nothing). A compiler which correctly detected these two PB> situations would be solving the halting problem for A(k), which is PB> impossible for a machine. PB> Yes. But I am NOT TALKING about program "as whole". I am talking about potential ambiguities. I.e. it's does not matter -- could be some code executed or no. In this situation you could not use trick above.
PB> So no. No compiler can detect the ambiguities CORRECTLY. It can however PB> warn you that you may have dangerous constructs around, and err on the PB> side of caution. Or it may consistently ignore dangers like that. It PB> must do one or the other. PB> C compiler could not do this is in A LOT OF cases. If you have f() in one file and main in other compiler simple does not have enough information. If compiler will warn about any + sign ... Hm. Thare are will be to many such warnings: if (sin(x)+y) will generate warning... Hm.
PB> PB> > not trivial task, unfortunatelly) ! Really this is exactly situation with egcs PB> PB> Trivial. PB> No. "Trivial" != "easily". We need a lot of definitions, etc to be able correcly talks about question. Thus this is not trivial question.
PB> > and kernel -- there are few known (and god knows how many unknown :-) places PB> > where egcs will generate wrong code since source code contans bugs like PB> > bug above... Most of them is cleaned out in 2.1.102 but noone knows -- how PB> > many still left there :-(( By the way I am using pgcc 1.0.2 for all compilations PB> > (including kernel, of course). I am not using 2.0.x kernels through ... PB> > PB> PB> Nice.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |