Unintuitive behavior when omitting type specifier: APPROX x = 1;

[billzorn]

Explanation in comments.

/*
 * So this clearly shouldn't be allowed. What we observe is that the program
 * returns 0, not 10000 as we might expect it to, even on precise runs.
 */

#include <enerc.h>

int main() {

  int x = 0;
  for(int i = 0; i < 1000; ++i) {
    // huh?
    APPROX x = x + 10;
    /*
     * I *think* it's declaring a new variable.
     *
     * We do get a compiler warning about this:
     *
     * main.c:14:12: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
     *     APPROX x = x + 10;
     *     ~~~~~~ ^
     *
     * Writing "APPROX int x = x + 10;" instead produces the same behavior
     * but no warning.
     *
     * I suppose this is actually working as intended, but it has some very
     * surprising consequences for cetain typos. I was not aware that you
     * were allowed to redefine variables like this inside a loop, but accept
     * doesn't complain about it even without any annotations. Nor does gcc.
     */    
  }

  return x;
}

[andreolb]

I don't understand what "clearly shouldn't be allowed".

Declaring another variable inside the loop scope is allowed in C++.

And the "x" the return statement refers to is the one outside the loop. The loop itself touches the redefined "x" which doesn't exist after the loop anymore. So I expect this program to return 0.

On Monday, February 9, 2015, Bill notifications@github.com wrote:

Explanation in comments.

/* * So this clearly shouldn't be allowed. What we observe is that the program * returns 0, not 10000 as we might expect it to, even on precise runs. */

include

int main() {

int x = 0; for(int i = 0; i < 1000; ++i) { // huh? APPROX x = x + 10; /* * I think it's declaring a new variable. * * We do get a compiler warning about this: * * main.c:14:12: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] * APPROX x = x + 10; * ~~ ^ * * Writing "APPROX int x = x + 10;" instead produces the same behavior * but no warning. * * I suppose this is actually working as intended, but it has some very * surprising consequences for cetain typos. I was not aware that you * were allowed to redefine variables like this inside a loop, but accept * doesn't complain about it even without any annotations. Nor does gcc. */ }

return x; }

— Reply to this email directly or view it on GitHub https://github.com/uwsampa/accept/issues/34.

André Oliveira

[sampsyo]

@andreolb It's the APPROX x = ... that should be illegal. That's an assignment, not a declaration. APPROX int x = ... is fine, but without the type it should be an error.

[andreolb]

Right, I understand now. Thanks!

On Mon, Feb 9, 2015 at 10:44 PM, Adrian Sampson notifications@github.com wrote:

@andreolb https://github.com/andreolb It's the APPROX x = ... that should be illegal. That's an assignment, not a declaration. APPROX int x = ... is fine, but without the type it should be an error.

— Reply to this email directly or view it on GitHub https://github.com/uwsampa/accept/issues/34#issuecomment-73652261.

André Oliveira

[andreolb]

Actually, thinking more carefully about it, maybe it's just fine (tell me if you think I'm trying to turn a bug into a feature :) :

ACCEPT just recognizes statements that starts with "APPROX" as a declaration, which is correct. And in this case, because the type is missing in a declaration, the C compiler assumes it's an implicit "int".

On Mon, Feb 9, 2015 at 10:47 PM, Andre Oliveira andreolb@gmail.com wrote:

Right, I understand now. Thanks!

On Mon, Feb 9, 2015 at 10:44 PM, Adrian Sampson notifications@github.com wrote:

@andreolb https://github.com/andreolb It's the APPROX x = ... that should be illegal. That's an assignment, not a declaration. APPROX int x = ... is fine, but without the type it should be an error.

— Reply to this email directly or view it on GitHub https://github.com/uwsampa/accept/issues/34#issuecomment-73652261.

André Oliveira

André Oliveira

[sampsyo]

Yeah, I guess it does—the error message does say that. I mostly just wish the error said "did you mean to leave off APPROX?" instead of "did you mean to insert int?" which seems less likely.

[andreolb]

I agree, but maybe the misunderstanding is due to the C compiler, not to ACCEPT. I say this because when I see code like

foo(int a) { .... }

I think it's much more likely that the programmer forgot to specify the return type than that he wanted an int.

On Mon, Feb 9, 2015 at 10:59 PM, Adrian Sampson notifications@github.com wrote:

Yeah, I guess it does—the error message does say that. I mostly just wish the error said "did you mean to leave off APPROX?" instead of "did you mean to insert int?" which seems less likely.

— Reply to this email directly or view it on GitHub https://github.com/uwsampa/accept/issues/34#issuecomment-73653449.

André Oliveira

[billzorn]

Based on my experience, this wouldn't be a problem if the warning were more visible to the user.

In practice, it's highly likely that whatever warning is generated will blend in with all the other warnings that the APPROX notation tends to cause. I first hit this feature while annotating the perfect benchmarks, and had no idea it even produced a warning until I tried to reproduce it.