4 ms·

"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

"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.
- stingraycharles 7y ago
  You’re suggesting creating incredibly fragile code that will cause a lot of cognitive overload which is completely unnecessary in the first place. Don’t do this, ever. Just because it’s technically possible doesn’t mean it’s a good idea.
  - kazinator 7y ago
    I have no idea what you're talking about; we're discussing small, incremental changes in something whose design I have nothing to do with otherwise.
  - jacoblambda 7y ago
    they are suggesting improvements. The code as a whole is problematic due to a number of reasons and they are offering improvements. If they had prefaced everything with add the namespace to the definitions, I doubt most people would have had as much of a problem with it. From what it seems, they didn't though because the developers don't seem to be worried about library namespace collisions.
  - geezerjay 7y ago
    > You’re suggesting creating incredibly fragile code You're making ill-informed accusations. Please check libmill and pay attention to how it has been implemented, particularly the design choices covered in this thread, and afterwards re-read OPs comments.
- fao_ 7y ago
  > 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. Local shadowing is completely different to global shadowing.
jasonzemos 7y ago
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.

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.

stingraycharles 7y ago
You’re suggesting creating incredibly fragile code that will cause a lot of cognitive overload which is completely unnecessary in the first place. Don’t do this, ever. Just because it’s technically possible doesn’t mean it’s a good idea.
- kazinator 7y ago
  I have no idea what you're talking about; we're discussing small, incremental changes in something whose design I have nothing to do with otherwise.
- jacoblambda 7y ago
  they are suggesting improvements. The code as a whole is problematic due to a number of reasons and they are offering improvements. If they had prefaced everything with add the namespace to the definitions, I doubt most people would have had as much of a problem with it. From what it seems, they didn't though because the developers don't seem to be worried about library namespace collisions.
- geezerjay 7y ago
  > You’re suggesting creating incredibly fragile code You're making ill-informed accusations. Please check libmill and pay attention to how it has been implemented, particularly the design choices covered in this thread, and afterwards re-read OPs comments.
fao_ 7y ago
> 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. Local shadowing is completely different to global shadowing.

jasonzemos 7y ago

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.