3 ms·
> the results can be almost impossible to diagnose Humor me - concote a case with a standard header using __f name in a way that will make a conflict with this
by apankrat 7y ago
> the results can be almost impossible to diagnose
Humor me - concote a case with a standard header using __f name in a way that will make a conflict with this particular __f() macro "almost impossible to diagnose". I can't think of any.
Following overly broad rules that go against established practices without any due need is exactly that - pedantry.
Look at it this way - if a language spec was serious about reserving the __ name prefix, it's not hard to enforce it at the compiler level. But it's been a while since this made it into a spec and yet it's not enforced. So whatever the good reasons were behind this bit of spec, they were not a strong enough of concern to warrant any practical enforcement.
- jfk13 7y agoI haven't looked into what your macro definition would do to it, but just running grep -r '\b__f\b' /usr/include/ on my system shows a bunch of uses of this symbol. Looks like it's generally used as a parameter, though I also see it as a field name in a union, e.g. in /usr/include/math.h: __header_always_inline int __inline_signbitf(float __x) { union { float __f; unsigned int __u; } __u; __u.__f = __x; return (int)(__u.__u >> 31); } I wonder how the compiler likes it if you try to #include that header after you've defined a __f() macro?
- gpderetta 7y agoIf you look at a standard library implementation, they go to extreme pain to uglify their symbols not to conflict with the user namespace. If you encroach on the library namespace your code deserves to be broken.