If the compiler supports "-E", there absolutely is some equivalent of the expanded text, with (somewhat limited) whitespace info available: if you insert whitespace into between "b" and the comma in "b,", then "-E" invocation will dutifully show it. Yes, multiple spaces are collapsed into one, but their presence/absence is tracked already.

> Expanding just one line of the source file would either require re-invoking the preprocessor from the beginning or storing already consumed preprocessor tokens.

Yeah, keep the whole expansion of the latest top-level (not nested) macro. I believe some bytecode-like compression scheme (a replay of that state machine you mentioned) à la LZ would work fairly well, with minor additional memory necessary. Hell, scratch that: since #define/#undef are impossible inside a macro, you don't even need to remember the expansion of the macro, you simply need to keep the current macro definitions and remember what was the last macro you tried to expand — if your error happened inside its expansion, just re-expand again. Zero additional memory needed, since this information is already stored for the current way of error reporting — you can see in the current output that it remembers what macros it expanded and where, the whole path down to the offending token: at 1:21 "in expansion of macro 'W'" which was at 2:18 "in expansion of macro 'X'" which was at 5:13.

> And re-invoking the preprocessor to show you one line on every error message makes error reporting slow.

Eh, it's on the whole faster than making the programmer re-run with "-E" option manually.

Tangential note but: why does this require a separate re-invocation of the compiler with the '-E' flag? Say I have this silly example with a comma instead of the semicolon inside W() macro:

    #define W(a, b)  b, int a
    #define X(a, b)  W(b, a)

    int kekw(int x) {
        int z = X(23, k) = x;
        return z + k;
    }

    : In function 'int kekw(int)':
    :1:21: error: expected unqualified-id before 'int'
        1 | #define W(a, b)  b, int a
          |                     ^~~
    :2:18: note: in expansion of macro 'W'
        2 | #define X(a, b)  W(b, a)
          |                  ^
    :5:13: note: in expansion of macro 'X'
        5 |     int z = X(23, k) = x;
          |             ^
    :6:16: error: 'k' was not declared in this scope
        6 |     return z + k;
          |       

    : In function 'int kekw(int)':
    :1:21: error: expected unqualified-id before 'int'
        1 | #define W(a, b)  b, int a
          |                     ^~~
    :2:18: note: in expansion of macro 'W'
        2 | #define X(a, b)  W(b, a)
          |                  ^
    :5:13: note: in expansion of macro 'X'
        5 |     int z = X(23, k) = x;
          |             ^
    :5:-: note: the expanded source text is
          |     int z = 23, int k = x;
          |                 ^~~
    :6:16: error: 'k' was not declared in this scope
        6 |     return z + k;
          |       

Also, what is this first error message about in the first place? Why the hell does it expect unqualified-id before "int"? If you put "int" after the unqualified-id, it still would be illegal; and an unqualified-id is not the only thing that can follow the comma in this context anyway.

Well, they are. Just as drinking fountains.

> Public restrooms don't come from Santa Claus, and they cost a lot both to build and maintain. Then there are the costs and miseries of security. Gratitude toward business providing restrooms seems nonexistent.

s/restroom/park/g. Hey, it's still true! And explains why there are almost no public parks around.

Edit: oh, and before someone comments on unhygienicity of drinking fountains: you're not supposed to kiss the nozzle or, heavens forbid, to fellate it to drink. Let about 1/2–1/3 of the top of the spout inside of your mouth and drink it; leave the rest outside.

Although GLib indeed has some rather weird design/taste.

> and why is it called gpointer?

    An untyped pointer, exactly equivalent to void*.

    The standard C void* type should usually be preferred in new code, but gpointer
    can be used in contexts where a type name must be a single word, such as in the
    GType name of G_TYPE_POINTER or when generating a family of function names for
    multiple types using macros.

In any case, thanks; it's nice to see C++ at least fully embracing the mandate on integers being two's complement, finally. There is enough footguns already without basic arithmetic operators being UB half of the time.

    1) ........................ The behavior is undefined if the right operand is negative,
    or greater than or equal to the width of the promoted left operand.

    2) The value of E1 << E2 is the unique value congruent to E1 × 2**E2 modulo 2**N, where
    N is the width of the type of the result.

    [Note 1 : E1 is left-shifted E2 bit positions; vacated bits are zero-filled. — end note]

    3) The value of E1 >> E2 is E1 / 2**E2, rounded down.

    [Note 2 : E1 is right-shifted E2 bit positions. Right-shift on signed integral types is
    an arithmetic right shift, which performs sign-extension. — end note]

[0] https://news.ycombinator.com/item?id=50117296

But yeah, that's precisely what contracts are (at least originally) intended to be, but you can quite clearly see from this comment section that this is not how they're going to be used. Well, this surely gonna be "fun" experience down the line for the C++ programmers...

    4) The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits
    are filled with zeros. If E1 has an unsigned type, the value of the result
    is E1 × 2**E2, wrapped around. If E1 has a signed type and nonnegative value,
    and E1 × 2**E2 is representable in the result type, then that is the resulting
    value; otherwise, the behavior is undefined.

    5) The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an
    unsigned type or if E1 has a signed type and a nonnegative value, the value of
    the result is the integral part of the quotient of E1 / 2**E2. If E1 has a
    signed type and a negative value, the resulting value is implementation-defined.

But if it is true, then yeah, that'd make (some) sense. I say "some" because surely in this case the implementations could simply emit the "logical shift left" instruction for the shift operation both for ints and unsigned ints? I don't think there ever was a machine that actually tracked the signedness/unsignedness of registers.

    4   Conformance

    A strictly conforming program shall use only those features of the language and
    library specified in this document.

    [...]

    The two forms of conforming implementation are hosted and freestanding. A
    conforming hosted implementation shall accept any strictly conforming program.

Wait. An implementation-defined behaviour isn't allowed to be trap/termination of execution? Okay, make it unspecified then, with the options of trapping or calculating some unspecified (not indeterminate) integer value.

> N3863

Hm?

    Because implementation-defined behavior relies on the definition of unspecified behavior, it
    means that implementation-defined behavior requires two or more possibilities to be defined in
    the standard. However, a brief look at its uses in the standard clearly shows that there isn’t
    always a list of potential behaviors to pick from.

    N3783 5.2.1.2p1.1: Physical source file multibyte characters are mapped, in an implementation-
    defined manner, to the source character set (introducing new-line characters for end-of-line
    indicators) if necessary.

    N3783 5.2.1.3p1: A conforming implementation shall produce at least one diagnostic message
    (identified in an implementation-defined manner)

    N3783 5.2.2.2p1-2: In a freestanding environment (in which C program execution can take
    place without any benefit of an operating system), the name and type of the function called at
    program startup are implementation-defined.

At least make it "change of the sign bit is UB" — if 0 shifts into the sign-bit of a positive number, or 1 shifts into the sign-bit of a negative number, that shouldn't be UB. This would make left-shifts of negative numbers well-defined, their behaviour being that of two's complement numbers. And C23 already demands two's complement from the implementations, doesn't?

> signed overflow UB can be turned into traps using sanitizers.

Well, yeah, sure, but shifting -1 one place to the left doesn't overflow, it produces -2; only shifting INT_MIN or something up to and including INT_MIN + (INT_MAX/2) would overflow.