4 ms·

It is dangerous. If you (illegally) #define a reserved name in your own code and then include a standard header file that (legally) uses that name, the results

It is dangerous. If you (illegally) #define a reserved name in your own code and then include a standard header file that (legally) uses that name, the results can be almost impossible to diagnose. There is never any need to do it, so not doing it is not "pedantry", it is simple good practice. The rules about double-underscores exist for very good reasons.

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 ago
  I 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 ago
  If 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.

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 ago
I 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 ago
If 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.