4 ms·

I have a hard time wrapping my head aroun dthe fact that you think the brace placement is a problem while entertaining the suggestion that calling a macro "sele

I have a hard time wrapping my head aroun dthe fact that you think the brace placement is a problem while entertaining the suggestion that calling a macro "select" with the obvious complete breakage under unix would be fine. One is a minor esthetic problem, the other would be a nightmare to support and work around.

kazinator 7y ago
> suggestion that calling a macro "select" with the obvious complete breakage under unix would be fine. There are lots of API's in the world; you can't ponder about all of them when naming a macro. How do you know the next system vendor doesn't have a choose function? Or if not the next system vendor, then some third party library or module you'd like to use or whatever. POSIX doesn't reserve the select identifier for use as a macro, unless the header file is included which defines it. It is not "complete breakage", and there are workarounds in that situation, one possibility being: #undef select #define whatever mill_choose_init___ The breakage only happens for code that uses either the select macro or the select function, if the headers are included in the proper order: the system headers first, then libmill.h. I.e. this by itself doesn't cause a problem (except in the improble case that <sys/select.h> defines a select macro): #include <sys/select.h> // #undef select at worst! #include "libmill.h" // with #define select macro This does cause a problem, 100%: #include "libmill.h" // with #define select macro #include <sys/select.h> But you should never do that: do not include local headers before system or third-party headers, unless you're sure they don't define any macros. There is also no problem if the rest of the file uses the select macro. The only issue arises if the rest of the file wants to use the select function, and then we put in a workaround. You're not going to call the select function in hundreds of places, where you also need the libmill header. TL;DR: it's not anywhere near a "nightmare". Moreover, libmill defines a few macro with short names. Conceivably #define end could be a problem, as well as #define in(..) and #define out(...). For instance if we have a "range.h" which has this: struct range { int beg; int end; }; and we do this: #include "libmill.h" #include "range.h" then libmill's end macro will screw up the struct range declaration, not to mention any place where we use end as an identifier. It's not an uncommon local variable name, like for pointers pointing to the end of a memory range.
- kevin_thibedeau 7y ago
  The stdlib namespace is golden. The POSIX namespace is silver. Only the foolhardy tread on either. One might even want to use libmill in conjunction with some socket code to build a non-blocking state machine using select().
  - kazinator 7y ago
    I would say that such work would be a candidate for rolling into libmill itself, so the application wouldn't deal with select at all. Note that the code already has some multiplexing gadgetry there, switchable between Linux's epoll, BSD's kqueue and the portable poll (see epoll.inc, kqueue.inc and poll.inc).
- CoolGuySteve 7y ago
  "Speaking as a professional", if you wrote something like this in my codebase with this justification, I'd fire you before any more carnage could be done. Holy shit. Standard practice in C is to prefix your functions with their 'namespace' to avoid collisions. In this case, I don't even like that they used "choose" instead of "mill_choose" or "mill_select". But redefining select() is a whole other level of inconsiderate.
  - kazinator 7y ago
    I'm working within the premise of this library, which is to provides un-hygienic syntactic extensions to C via preprocessor macros, which are presumably supposed to look reasonably good in comparison to Go. Did you notice the #define end, which is a common name for struct members and local variables. Redefining select is certainly not a whole other level of inconsiderate in that light. The caveat is that whoever uses this should include it last, after any other headers, and then deal with the macro clashes: don't use "choose" or "end" in their code and so on. One way to mitigate this is to have these macros in a separate header, say "libmill-macros.h", so that the rest of the API is available without them.
    - 7y ago

kazinator 7y ago

> suggestion that calling a macro "select" with the obvious complete breakage under unix would be fine. There are lots of API's in the world; you can't ponder about all of them when naming a macro. How do you know the next system vendor doesn't have a choose function? Or if not the next system vendor, then some third party library or module you'd like to use or whatever. POSIX doesn't reserve the select identifier for use as a macro, unless the header file is included which defines it. It is not "complete breakage", and there are workarounds in that situation, one possibility being: #undef select #define whatever mill_choose_init___ The breakage only happens for code that uses either the select macro or the select function, if the headers are included in the proper order: the system headers first, then libmill.h. I.e. this by itself doesn't cause a problem (except in the improble case that <sys/select.h> defines a select macro): #include <sys/select.h> // #undef select at worst! #include "libmill.h" // with #define select macro This does cause a problem, 100%: #include "libmill.h" // with #define select macro #include <sys/select.h> But you should never do that: do not include local headers before system or third-party headers, unless you're sure they don't define any macros. There is also no problem if the rest of the file uses the select macro. The only issue arises if the rest of the file wants to use the select function, and then we put in a workaround. You're not going to call the select function in hundreds of places, where you also need the libmill header. TL;DR: it's not anywhere near a "nightmare". Moreover, libmill defines a few macro with short names. Conceivably #define end could be a problem, as well as #define in(..) and #define out(...). For instance if we have a "range.h" which has this: struct range { int beg; int end; }; and we do this: #include "libmill.h" #include "range.h" then libmill's end macro will screw up the struct range declaration, not to mention any place where we use end as an identifier. It's not an uncommon local variable name, like for pointers pointing to the end of a memory range.

kevin_thibedeau 7y ago
The stdlib namespace is golden. The POSIX namespace is silver. Only the foolhardy tread on either. One might even want to use libmill in conjunction with some socket code to build a non-blocking state machine using select().
- kazinator 7y ago
  I would say that such work would be a candidate for rolling into libmill itself, so the application wouldn't deal with select at all. Note that the code already has some multiplexing gadgetry there, switchable between Linux's epoll, BSD's kqueue and the portable poll (see epoll.inc, kqueue.inc and poll.inc).
CoolGuySteve 7y ago
"Speaking as a professional", if you wrote something like this in my codebase with this justification, I'd fire you before any more carnage could be done. Holy shit. Standard practice in C is to prefix your functions with their 'namespace' to avoid collisions. In this case, I don't even like that they used "choose" instead of "mill_choose" or "mill_select". But redefining select() is a whole other level of inconsiderate.
- kazinator 7y ago
  I'm working within the premise of this library, which is to provides un-hygienic syntactic extensions to C via preprocessor macros, which are presumably supposed to look reasonably good in comparison to Go. Did you notice the #define end, which is a common name for struct members and local variables. Redefining select is certainly not a whole other level of inconsiderate in that light. The caveat is that whoever uses this should include it last, after any other headers, and then deal with the macro clashes: don't use "choose" or "end" in their code and so on. One way to mitigate this is to have these macros in a separate header, say "libmill-macros.h", so that the rest of the API is available without them.
  - 7y ago