lkml.org 
[lkml]   [1998]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:1.710 / U:0.804 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site