3 ms·

I wasn't aware of this gem of C minutiae: Compound assignment operators such as += are really multiple tokens. Thus, a + /* strange */ = 1 mean

I wasn't aware of this gem of C minutiae: Compound assignment operators such as += are really multiple tokens. Thus, a + /* strange */ = 1 means the same as a += 1

omoikane 2y ago
It would be a syntax error in C++. <source>:3:11: error: expected primary-expression before '=' token 3 | a + = 1; | ^
- MaxBarraclough 2y ago
  A compiler error isn't definitive about the language standard, but as a quick google search didn't turn up anything definitive, I'll do the same: I now doubt whether it's true for either language. gcc 11 does not treat i + = 8; as equivalent to i += 8;, I get the kind of error message I'd have expected to see prior to reading the article. This occurs even if passing -std=c89 (as C89 is the oldest version of the C language that it seems to support). Perhaps it was true prior to the C89 standard?
  - omoikane 2y ago
    I think it's describing a particular lexer or preprocessor bug that GCC never had, so "a + = 1" should have been a syntax error in C89 as well. Someone mirrored GCC 0.9 (1987), the relevant bits start here: https://github.com/huangguiyang/gcc-0.9/blob/a83ea1b45dc3187d9fc4f7a3d8091c1454991afe/parse.y#L1296 https://github.com/huangguiyang/gcc-0.9/blob/a83ea1b45dc3187... // Read the next non-whitespace character. 1296: c = skip_white_space(); // Match it against '+' 1618: case '+': // Tentatively give it the token 'PLUS_EXPR' 1637: case '+': 1638: yylval.code = PLUS_EXPR; break; // Read the next character, but note that whitespaces are NOT skipped here. 1663: c1 = getc(finput); // Match the second character against '=' 1665: if (c1 == '=') ... 1678: value = ASSIGN; goto done; // Unread the next charcter if it didn't match. 1700: ungetc (c1, finput); "a +/* */= 1" wouldn't have parsed either, because /**/ are translated to spaces by the preprocessor. https://github.com/huangguiyang/gcc-0.9/blob/a83ea1b45dc3187d9fc4f7a3d8091c1454991afe/cccp.c#L974 https://github.com/huangguiyang/gcc-0.9/blob/a83ea1b45dc3187...*
    - MaxBarraclough 2y ago
      The article isn't very clear but on closer reading I think it's describing quirks of certain compilers in the pre-standardisation era, which it calls older versions of C. At the risk of splitting hairs: at the time I'm not sure it would have been considered a bug.

I wasn't aware of this gem of C minutiae: Compound assignment operators such as += are really multiple tokens. Thus, a + /* strange */ = 1 means the same as a += 1

omoikane 2y ago

It would be a syntax error in C++. <source>:3:11: error: expected primary-expression before '=' token 3 | a + = 1; | ^

MaxBarraclough 2y ago
A compiler error isn't definitive about the language standard, but as a quick google search didn't turn up anything definitive, I'll do the same: I now doubt whether it's true for either language. gcc 11 does not treat i + = 8; as equivalent to i += 8;, I get the kind of error message I'd have expected to see prior to reading the article. This occurs even if passing -std=c89 (as C89 is the oldest version of the C language that it seems to support). Perhaps it was true prior to the C89 standard?
- omoikane 2y ago
  I think it's describing a particular lexer or preprocessor bug that GCC never had, so "a + = 1" should have been a syntax error in C89 as well. Someone mirrored GCC 0.9 (1987), the relevant bits start here: https://github.com/huangguiyang/gcc-0.9/blob/a83ea1b45dc3187d9fc4f7a3d8091c1454991afe/parse.y#L1296 https://github.com/huangguiyang/gcc-0.9/blob/a83ea1b45dc3187... // Read the next non-whitespace character. 1296: c = skip_white_space(); // Match it against '+' 1618: case '+': // Tentatively give it the token 'PLUS_EXPR' 1637: case '+': 1638: yylval.code = PLUS_EXPR; break; // Read the next character, but note that whitespaces are NOT skipped here. 1663: c1 = getc(finput); // Match the second character against '=' 1665: if (c1 == '=') ... 1678: value = ASSIGN; goto done; // Unread the next charcter if it didn't match. 1700: ungetc (c1, finput); "a +/* */= 1" wouldn't have parsed either, because /**/ are translated to spaces by the preprocessor. https://github.com/huangguiyang/gcc-0.9/blob/a83ea1b45dc3187d9fc4f7a3d8091c1454991afe/cccp.c#L974 https://github.com/huangguiyang/gcc-0.9/blob/a83ea1b45dc3187...*
  - MaxBarraclough 2y ago
    The article isn't very clear but on closer reading I think it's describing quirks of certain compilers in the pre-standardisation era, which it calls older versions of C. At the risk of splitting hairs: at the time I'm not sure it would have been considered a bug.