Speaking as a C programmer, this is a great tour of all the worst parts of C. No destructors, no generics, the preprocessor, conditional compilation, check, check, check. It just needs a section on autoconf to round things out.
It is often easier, and even more correct, to just create a macro which repeats the code for you.
A macro can be more correct?! This is new to me.
Perhaps the overhead of the abstract structure is also unacceptable..
Number of times this is likely to happen to you: exactly zero.
C function signatures are simple and easy to understand.
It once took me 3 months of noodling on a simple http server to realize that bind() saves the pointer you pass into it, so makes certain lifetime expectations on it. Not one single piece of documentation I’ve seen in the last 5 years mentions this fact.
Linux (that’s the manpage I linked to above). This was before I discovered OpenBSD.
Edit: I may be misremembering and maybe it was connect() that was the problem. It too seems fine on OpenBSD. Here’s my original eureka moment from 2011: https://github.com/akkartik/wart/commit/43366d75fbfe1. I know it’s not specific to that project because @smalina and I tried it again with a simple C program in 2016. Again on Linux.
Notice that I didn’t implicate the kernel in my original comment, I responded to a statement about C signatures. We’d need to dig into libc for this, I think.
Notice that I didn’t implicate the kernel in my original comment, I responded to a statement about C signatures. We’d need to dig into libc for this, I think.
bind and connect are syscalls, libc would only have a stub doing the syscall if anything at all since they are not part of the standard library.
Certainly. But is the author concerned with embedded programming? He seems to be speaking of “systems programming” in general.
Also, I interpreted that section as being about time overhead (since he’s talking about the optimizer eliminating it). Even in embedded situations, have you lately found the time overheads concerning?
I work with 8-bit AVR MCUs. I often found myself having to cut corners and avoid certain abstractions, because that would have resulted either in larger or slower binaries, or would have used significantly more RAM. On an Atmega32U4, resources are very limited.
Perhaps the overhead of the abstract structure is also unacceptable..
Number of times this is likely to happen to you: exactly zero.
Many times, actually. I see FSM_TIME. Hmm … seconds? Milliseconds? No indication of the unit. And what isFSM_TIME? Oh … it’s SYS_TIME. How cute. How is that defined? Oh, it depends upon operating system and the program being compiled. Lovely abstraction there. And I’m still trying to figure out the whole FSM abstraction (which stands for “Finite State Machine”). It’s bad enough to see a function written as:
static FSM_STATE(state_foobar)
{
...
}
and then wondering where the hell the variable context is defined! (a clue—it’s in the FSM_STATE() macro).
And that bind() issue is really puzzling, since that haven’t been my experience at all, and I work with Linux, Solaris, and Mac OS-X currently.
I agree that excessive abstractions can hinder understanding. I’ve said this before myself: https://news.ycombinator.com/item?id=13570092. But OP is talking about performance overhead.
I’m still trying to reproduce the bind() issue. Of course when I want it to fail it doesn’t.
The core of my job involves having exact control over object lifetimes, ease of manipulating data structures accessed by drivers/the hardware, ability to move things around with zero copying (and knowing that it won’t suddenly get copied if I change some code somewhere and suddenly “oops, no move constructor!”), zero garbage-collection delays, and the ability to easily reason about the number of context switches a given piece of code will have.
Speaking as a C programmer, this is a great tour of all the worst parts of C. No destructors, no generics, the preprocessor, conditional compilation, check, check, check. It just needs a section on
autoconfto round things out.A macro can be more correct?! This is new to me.
Number of times this is likely to happen to you: exactly zero.
It once took me 3 months of noodling on a simple http server to realize that
bind()saves the pointer you pass into it, so makes certain lifetime expectations on it. Not one single piece of documentation I’ve seen in the last 5 years mentions this fact.Which system? I’m pretty sure OpenBSD doesn’t.
https://github.com/openbsd/src/blob/4a4dc3ea4c4158dccd297c17b5ac5a6ff2af5515/sys/kern/uipc_syscalls.c#L200
https://github.com/openbsd/src/blob/4a4dc3ea4c4158dccd297c17b5ac5a6ff2af5515/sys/kern/uipc_syscalls.c#L1156
Linux (that’s the manpage I linked to above). This was before I discovered OpenBSD.
Edit: I may be misremembering and maybe it was
connect()that was the problem. It too seems fine on OpenBSD. Here’s my original eureka moment from 2011: https://github.com/akkartik/wart/commit/43366d75fbfe1. I know it’s not specific to that project because @smalina and I tried it again with a simple C program in 2016. Again on Linux.I find it really hard to believe the kernel would keep that userspace pointer around so …
https://github.com/torvalds/linux/blob/e978de7a6d382ec378830ca2cf38e902df0b6d84/net/socket.c#L1665
https://github.com/torvalds/linux/blob/e978de7a6d382ec378830ca2cf38e902df0b6d84/net/socket.c#L188
Bind is there too: https://github.com/torvalds/linux/blob/e978de7a6d382ec378830ca2cf38e902df0b6d84/net/socket.c#L1487
Notice that I didn’t implicate the kernel in my original comment, I responded to a statement about C signatures. We’d need to dig into libc for this, I think.
I’ll dig up a simple test program later today.
bind and connect are syscalls, libc would only have a stub doing the syscall if anything at all since they are not part of the standard library.
I have to worry about my embedded C code being too big for the stack as it is.
Certainly. But is the author concerned with embedded programming? He seems to be speaking of “systems programming” in general.
Also, I interpreted that section as being about time overhead (since he’s talking about the optimizer eliminating it). Even in embedded situations, have you lately found the time overheads concerning?
I work with 8-bit AVR MCUs. I often found myself having to cut corners and avoid certain abstractions, because that would have resulted either in larger or slower binaries, or would have used significantly more RAM. On an Atmega32U4, resources are very limited.
Many times, actually. I see
FSM_TIME. Hmm … seconds? Milliseconds? No indication of the unit. And what isFSM_TIME? Oh … it’sSYS_TIME. How cute. How is that defined? Oh, it depends upon operating system and the program being compiled. Lovely abstraction there. And I’m still trying to figure out the wholeFSMabstraction (which stands for “Finite State Machine”). It’s bad enough to see a function written as:and then wondering where the hell the variable
contextis defined! (a clue—it’s in theFSM_STATE()macro).And that
bind()issue is really puzzling, since that haven’t been my experience at all, and I work with Linux, Solaris, and Mac OS-X currently.I agree that excessive abstractions can hinder understanding. I’ve said this before myself: https://news.ycombinator.com/item?id=13570092. But OP is talking about performance overhead.
I’m still trying to reproduce the
bind()issue. Of course when I want it to fail it doesn’t.The core of my job involves having exact control over object lifetimes, ease of manipulating data structures accessed by drivers/the hardware, ability to move things around with zero copying (and knowing that it won’t suddenly get copied if I change some code somewhere and suddenly “oops, no move constructor!”), zero garbage-collection delays, and the ability to easily reason about the number of context switches a given piece of code will have.
There isn’t a better language for that than C.