3 ms·

The PP has made numerous valid justifications for why there either isn't a conflict or an easily mitigated conflict. Here's another one: use separate compilatio

The PP has made numerous valid justifications for why there either isn't a conflict or an easily mitigated conflict. Here's another one: use separate compilation units. Include select(2) in one and include libmill in another; then wrap their interfaces and link them the way you want. I don't know what's happened to HN these days. The sheer number of kids who have come out of the woodwork to flame this guy in different ways on different threads -- all with the same level of ignorance on a really simple topic -- is nothing short of deflating.

stingraycharles 7y ago
Undefining select, relying to the import order of files, are all things that are dubious at best, and create fragile code. To claim everyone who doesn't share your opinion are kids that just came out of the woodwork and are ignorant is not helping the discussion either. Grandparent made a controversial suggestion, and the discussion shows it.
- kazinator 7y ago
  Undefining the macro definition of a standard function is an approach described in the very ISO C standard itself. I have the 1999 version of the standard in PDF form handy. Let's see, 7.1.4 Use of library functions 1 [... snip ...] Any macro definition of a function can be suppressed locally by enclosing the name of the function in parentheses, because the name is then not followed by the left parenthesis that indicates expansion of a macro function name. For the same syntactic reason, it is permitted to take the address of a library function even if it is also defined as a macro. The use of #undef to remove any macro definition will also ensure that an actual function is referred to. Nothing dubious about using #undef to remove a macro definition of a library function. There probably isn't a select macro; the #undef is just in case there is one, so that when we #define our own, we don't get a diagnostic about a redefinition with a different token replacement sequence.
- jasonzemos 7y ago
  The entire premise of "complete breakage" and "nightmare" is unrealistic. No competently architected project universally includes select(2). There is no reason to have random invocations of the call all over the place. Are you prepared to setup the timing, signals, the fully elaborated errno switch handling every error, including finding a bad file descriptor on EBADF to toss for a reinvocation, or how to continue after EINTR all to make this expensive (and de facto deprecated) system call which generally forms a single blocking point deep in a program's core event loop willy nilly like it's some kind of strlcpy()? No, you're not. Frankly I've never seen select(2) properly invoked in more than one place in an entire project, and neither have you. That's why a C professional isn't really phased. Sure, there are about a million english words in the OED and some more creativity would be fantastic. This still isn't a problem, on the facts. It's not an opinion.
jancsika 7y ago
Give me a break. OP led with a trivial and trivially bike-sheddable opinion on a name(clash), egged on by OP's low-effort question, "so what?" If you don't want to dance with trolls, don't flirt with trolls onto the dancefloor. The point about the danger of mixing explicit brace opening with implicit macro brace closing is prudent, though.
- geezerjay 7y ago
  > OP led with a trivial and trivially bike-sheddable opinion on a name(clash), This discussion is on a library that advertises itself as offering "Go-style concurrency in C", and the OP presented a valid case about an aspect of the library that misses its whole design basis. Quite obviously that's not bikeshedding, but valid criticism regarding the very basis of the whole project.

stingraycharles 7y ago

Undefining select, relying to the import order of files, are all things that are dubious at best, and create fragile code. To claim everyone who doesn't share your opinion are kids that just came out of the woodwork and are ignorant is not helping the discussion either. Grandparent made a controversial suggestion, and the discussion shows it.

kazinator 7y ago
Undefining the macro definition of a standard function is an approach described in the very ISO C standard itself. I have the 1999 version of the standard in PDF form handy. Let's see, 7.1.4 Use of library functions 1 [... snip ...] Any macro definition of a function can be suppressed locally by enclosing the name of the function in parentheses, because the name is then not followed by the left parenthesis that indicates expansion of a macro function name. For the same syntactic reason, it is permitted to take the address of a library function even if it is also defined as a macro. The use of #undef to remove any macro definition will also ensure that an actual function is referred to. Nothing dubious about using #undef to remove a macro definition of a library function. There probably isn't a select macro; the #undef is just in case there is one, so that when we #define our own, we don't get a diagnostic about a redefinition with a different token replacement sequence.
jasonzemos 7y ago
The entire premise of "complete breakage" and "nightmare" is unrealistic. No competently architected project universally includes select(2). There is no reason to have random invocations of the call all over the place. Are you prepared to setup the timing, signals, the fully elaborated errno switch handling every error, including finding a bad file descriptor on EBADF to toss for a reinvocation, or how to continue after EINTR all to make this expensive (and de facto deprecated) system call which generally forms a single blocking point deep in a program's core event loop willy nilly like it's some kind of strlcpy()? No, you're not. Frankly I've never seen select(2) properly invoked in more than one place in an entire project, and neither have you. That's why a C professional isn't really phased. Sure, there are about a million english words in the OED and some more creativity would be fantastic. This still isn't a problem, on the facts. It's not an opinion.

jancsika 7y ago

Give me a break. OP led with a trivial and trivially bike-sheddable opinion on a name(clash), egged on by OP's low-effort question, "so what?" If you don't want to dance with trolls, don't flirt with trolls onto the dancefloor. The point about the danger of mixing explicit brace opening with implicit macro brace closing is prudent, though.

geezerjay 7y ago
> OP led with a trivial and trivially bike-sheddable opinion on a name(clash), This discussion is on a library that advertises itself as offering "Go-style concurrency in C", and the OP presented a valid case about an aspect of the library that misses its whole design basis. Quite obviously that's not bikeshedding, but valid criticism regarding the very basis of the whole project.