D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 4667 - Goto skipping variable initializations
Summary: Goto skipping variable initializations
Status: RESOLVED DUPLICATE of issue 602
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: x86 Windows
: P2 normal
Assignee: No Owner
URL:
Keywords: diagnostic
Depends on:
Blocks:
 
Reported: 2010-08-17 07:49 UTC by bearophile_hugs
Modified: 2010-08-18 09:02 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description bearophile_hugs 2010-08-17 07:49:03 UTC
This D2 code runs with no errors (DMD 2.048):

import std.c.stdio: printf;
void main(string[] args) {
    if (args.length < 2)
        goto FOO1;
    int x = 100;
  FOO1:
    printf("%d\n", x);

    goto FOO2;
    for (int i = 0; i < 10; i++) {
        FOO2:
        printf("%d\n", i);
        break;
    }
}



But that's not good code, the initialization of i is always skipped, and the initialization of x is sometimes skipped.

bernardh in IRC #D quotes from TDPL:
"another restriction is that a goto cannot skip the definition point of a value that's visible at the landing point."

See also bug 3820


Similar code in C99:

#include "stdio.h"
int main(int argc, const char* argv[]) {
    if (argc < 2)
        goto FOO1;
    int x = 100;
  FOO1:
    printf("%d\n", x);

    goto FOO2;
    for (int i = 0; i < 10; i++) {
      FOO2:
        printf("%d\n", i);
        break;
    }

    return 0;
}


Compiled with GCC 4.5.0 shows a warning:

...>gcc -Wall -std=c99 -m32 test.c -o test
test.c: In function 'main':
test.c:13:15: warning: 'i' is used uninitialized in this function
Comment 1 Lars T. Kyllingstad 2010-08-17 09:51:02 UTC

*** This issue has been marked as a duplicate of issue 602 ***
Comment 2 bearophile_hugs 2010-08-17 10:51:52 UTC
Thank you and sorry for the dupe.
(I hope the people that try to fix one bug take a look at all the contents of the 'duplicated' bugs, because sometimes they may be not fully duplicated.)
Comment 3 Stewart Gordon 2010-08-18 09:02:59 UTC
If a duplicate bug provides more information or a testcase that might still fail after the original is fixed, then it's a good idea to add it as a comment to the original bug report, possibly with a note at the beginning like "From duplicate bug 4667".

But looking at duplicate bug reports just in case is probably indeed also a good idea.