david2ndaccount

The answer is they don't in practical code but they come up in generic code, where you want to wrap something that is already returning an optional in your optional. In languages that do support optional[optional[whatever]], if you every actually write that you know you've messed up your API.

I was unclear in the article, but in my defense I wrote it in a hurry on the couch after seeing the convoluted backwards loop an llm had extruded. I meant if you are actually doing something with the index variable other than indexing. Mixing signed and unsigned types, possibly of different sizes, has surprising behavior to many programmers who don’t have the “usual arithmetic conversions” memorized. If you’re working in size_t the result simplifies: everything becomes size_t. And you generally have size_t anyway as you’re using the result of sizeof or an allocation size passed to your allocation function.

In general I want to avoid signed types for counts and sizes as then you have to consider both boundary conditions which is easy to mess up.

Counter point: a buddy of mine who doesn’t know how to program has been vibe-coding a video game for the last month. He got very excited early on with what he thought was quick progress, but it’s been a month and he still doesn’t have anything approaching a game or even what he wants.

There’s no contradiction. Consider this thought experiment: the real range of possible outcomes is a number from 1-100, but your model is a six-sided die so it produces a number from 1-6. It is random, unpredictable and non-deterministic and yet you will get “samey” results compared to the real range of possible outcomes.

Right, you can work around it with things like this, but it means you’re forcing the C compiler to parse a compound literal just to get its length, 5 times! when the preprocessor already knows the length of `__VA_ARGS__`. Such contortions when you want a little bit of info that the compiler already has are what cause your compiler times to blow up if you try to do anything sophisticated with the cpp.

Your version expands `sum(1, 2, 3, 4, 5, 6)` to:

    sum(sizeof ((int []){0, 1, 2, 3, 4, 5, 6}) / sizeof *((int []){0, 1, 2, 3, 4, 5, 6}) - 1, ((int []){0, 1, 2, 3, 4, 5, 6}) + (sizeof ((int []){0, 1, 2, 3, 4, 5, 6}) / sizeof *((int []){0, 1, 2, 3, 4, 5, 6}) > 1))

whereas with __VA_COUNT__ it is just:

    sum(6, (int[]){1, 2, 3, 4, 5, 6})

__map() expands its arguments, like other function-like macros.

We’ll get there in this series.

> 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.

Whitespace is significant in the preprocessor so of course it tracks whitespace. Whitespace isn’t dropped until phase 7 when pp-tokens are converted to C tokens.

As I said it’s not impossible, write the patch and see if GCC accepts it.

During translation of source text to a C program, the source text goes through several phases. It turns raw bytes into preprocessor tokens, then preprocessor tokens get expanded into more preprocessor tokens and then preprocessor tokens get translated into C tokens, which are fed into the C parser. There is no “expanded text”, only expanded tokens. Generally this is implemented as a state machine that produces tokens on demand, so there is no expanded text. When GCC shows you that error message, it uses the recorded source location and looks it up in the original source file. This is trivial to do. Expanding just one line of the source file would either require re-invoking the preprocessor from the beginning or storing already consumed preprocessor tokens.

Obviously this is possible, but no one has gotten around to implementing this feature and it’s not clear you would want either solution: buffering preprocessor tokens in case you need to expand a line for an error message greatly increases memory usage and the vast majority of compilations are successful ones with no errors, slowing down the normal case. And re-invoking the preprocessor to show you one line on every error message makes error reporting slow.

The article shows how to implement map, but it should be a builtin

"In the face of ambiguity, refuse the temptation to guess."

Their specification is pretty bad, allowing code like:

    #include <stdio.h>
    #include <stddef.h>
    void v(int y[printf("hello world!\n")]){ 
    }

    int main(){
        v(NULL);
        typedef int wut[printf("oh no\n")];
    }
    $ cc vla.c && ./a.out
    hello world!
    oh no

`typedef`s with side effects...

I agree. Alas I have a day job and my other hobby is going for long hikes. But when the days get shorter and the weather is worse I’ll write some more!