If we assume that nullptr and auto mean the same as in C++ then what problem does nullptr fix in C? In C++ i can understand the need to use nullptr to distinguish between overloaded functions. Is the only use of nullptr in C to know what the type of an auto variable will be (which would be funny because if you care about what type it is you wouldn't use auto) or why would you need it?
Not something I agree with, but so it is with some circles where C is the only true path.
Lambdas were also part of the initial proposals, but it seems they were dropped.
You can read more about it about the original proposals at WG14.
For starters, it fixes the same problems it fixed on C++. I'm talking about stuff like automatic type conversion to ints and consequently being forced to babysit when your compiler called foo(int) instead of food(bar *) just because you passed NULL.
Also, keep in mind that these features are low-hanging fruits to any compiler writer, especially those who already maintain compilers that support C and C++. Thus the argument you should be making is not "why should C have these features" but "why should C be deprived from these features".
https://stackoverflow.com/questions/54098794/is-null-guarant...
That's what I meant that we don't have to worry about in C since you can't even have two different functions with the same name (assuming you meant foo instead of food).
> Thus the argument you should be making is not "why should C have these features" but "why should C be deprived from these features".
That's not an argument; that's a question. I wanted to know whether there was any reason to start using nullptr, like if there is a risk of making a bug if I use NULL. I did later find a page about nullptr in C [1] that talks about some risks of using NULL with varargs.
[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3039.htm
But you can have a macro foo which expands to a generic selection: <https://docs.microsoft.com/en-us/cpp/c-language/generic-sele...>