🚀 go-pugleaf

In article <4udd3i$90k@solutions.solon.com> seebs@solutions.solon.com
(Peter Seebach) writes:
>   In article <vkohklaizj.fsf@atari.connectinc.com>,
>   Bryan Ischo <bji@connectinc.com> wrote:
>   >Just out of curiosity ... why can't the compiler be sure that 'flag' 
>   >won't be modified by printf?
>
>   Because it could be modified by printf.
>
>   >After all, its type is declared as int, not int *, and
>   >the loop conditional is 'while(flag)' not 'while (*flag)'.
>
>   So?  &flag generates a pointer to it, through which it could be modified,
>   and any call to any function could possibly refer to it.  Trivally,
>	   printf("%n", &flag);
>   would be stupid but would modify flag.
>
>   >What I'm getting at is, the only way flag could be modified is if the
>   >programmer is assuming that the size of an int is the same as the size
>   >of an int * and is passing in an int in place of an int *, presumably
>   >one which has been casted from an int * somewhere earlier.
>
>   This is simply untrue.  The programmer could have put flag's address in a
>   global, and a function named printf might modify the contents.
>
>   At least, I think what you're saying is untrue; I can't honestly 
>   understand a word of it.
>
>   >Shouldn't the compiler be smart enough to know that flag can't be
>   >modified even IF the printf is in the loop, given how smart it's been
>   >about everything else?
>
>   Some versions might be, but it's an unlikely assumption.

OK, I'm sure I'll be corrected if I am wrong, but ...

C arguments are passed in by value, not by reference.  So, if I write a
function which takes an int as an argument, then the function will NOT be able
to modify the "original" value.  For example:

void foo(int a)
{
  a = a + 1;
}

void bar()
{
  int b = 3;

  foo(b);  
}

The call to foo() does NOT affect b's value in bar().  In foo(), 'a' will start
out as 3 and will increment to 4, and then promptly be popped off the stack
when the call to foo() returns.  b will be 3 before foo is called, and will
still be 3 afterwards.

Now, the only way for me to write and use foo() with the same signature which
modifies b is to do something like this:

void foo(int a)
{
   int *pa = (int *)a;

   *pa = *pa + 1;
}

void bar()
{
  int b = 3;

  foo((int)&b);
}

Note that this REQUIRES that sizeof(int) == sizeof(int *).  Not a very robust
programming practice.

What I was getting at before is, the compiler ought to be able to assume that
an int argument cannot be modified.  Sure, we could fudge foo and bar like we
did above, but that presumes things about the architecture that the compiler
ought not to allow, or at least ought to generate some pretty serious warnings
about.

To address some of the points from above ...

>   So?  &flag generates a pointer to it, through which it could be modified,
>   and any call to any function could possibly refer to it.  Trivally,
>	   printf("%n", &flag);
>   would be stupid but would modify flag.

True, but &flag was not passed in to printf in the original code.  What I am
getting at is, 'flag' in the original code was only ever used as an integer
and was only ever passed by value, so it could not be modified.  Maybe
compilers aren't written to cover rules as specific as this, but it would be
possible.  I mean, the whole notion of "volatile" is complicated enough to
require similarly convoluted optimization logic.

And I was just asking for confirmation of this idea.

Best wishes,
Bryan

-- 
------------------------------------------------------------------------
Bryan Ischo                                    mailto:bji@connectinc.com
Mountain View, CA, USA                         http://www.connectinc.com
Linux Aficionado                                         1990 Honda CB-1