Re: New const function detection code and infinite loops.

[John Wehle <john at feith dot com>]

Mark Mitchell writes:

> But that's a bug.  This program is guaranteed not to call abort in
> ANSI C:
> 
>   void f() {
>     while (1);
>   }
> 
>   int main () {
>     f();
>     abort ();
>   }
> 
> I think we need to find a way to solve this problem.

The current const detection code in the mainline sources will not
mark f as const since it is externally visable and void type.  It
will however mark f as const in the following example:

  static int f() {
    while (1);
    return 0;
  }

  int main () {
    f();
    abort();
  }

I take it that this example is also guaranteed not to call abort according
to the ANSI C standard?

I can prepare a patch to fix the problem (Jan, let me know if you're already
handling this).  BTW, is it easily provable that a loop will always terminate,
or must we simply avoid marking the function as const if any type of loop
construct is present?

I guess this raises for me a more general question of how loops (any type
of loop) should be handled.  Loops create delays (infinite loops merely
create infinite delays :-).  At what point is a delay considered an
observable event that is part of the program's behavior and should not
be changed by the compiler?  Granted an infinite loop is somewhat a
special case.

-- John

PS: I see that the egcs mail server was changed to reject posts while
    I was following this thread and bounced an earlier reply to the list.
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------