Hyperfine is a really nice tool for this kind of benchmarking.
Not knowing the /proc file system
11–20 of 111 posts
Re: Not knowing the /proc file system
#12Tangent: Looking at those code samples, I wonder whether coming up with the shortest possible, most cryptic variable names is somewhat of a sport amongst C developers. Are you guys still coding in Notepad and need to conserve keystrokes, or where does that reluctance to use proper names come from?
What specifically are you referring to?
Do you mean like using `fp` for a file pointer or `fd` for a file descriptor? That is idiomatic, and I would consider calling them `filePointer` or `fileDescriptor` to be an obvious smell that the developer doesn't know what they're doing.
Re: Not knowing the /proc file system
#13Tangent: Looking at those code samples, I wonder whether coming up with the shortest possible, most cryptic variable names is somewhat of a sport amongst C developers. Are you guys still coding in Notepad and need to conserve keystrokes, or where does that reluctance to use proper names come from?
Maybe your tangent is pointing at a wrong direction, because I think there are also a sizable portion of such programmers in many other languages. It seems that anOverlyLongAndInformationFreeIdentifier is widely despised, but once names do have enough information contents, an exactly preferred name wildly varies even in a single code base. For example induction variables in Python generators tended to be shorter than…
This is particularly true in statically typed languages that require a type declaration. Here’s some go:
func copy(f *os.File) { … }
I think f is more than clear enough as a parameter name. The same can be said of variables where the type is easily inferred from the declaration or initialization.
Re: Not knowing the /proc file system
#14When parsing the proc files, many people forget that process names can have spaces in them and that causes some very funny outputs. The Python script in this posts handles those correctly, kudos.
Re: Not knowing the /proc file system
#15Probably off-topic: I may miss something but I have the feeling the shown C program should segfault a lot as the variable `fname` in `char* make_filename(const char*)` does not seem to be initialized.
Re: Not knowing the /proc file system
#16The Linux /proc "file system" is kernel to user space communication hammered into the wrong form because "everything is a file". /proc is a system call with a fake file system API, and this matters. The sample code won't work reliably, because it assumes that the "files" won't change while being read. If you read /proc, you must "read" each file with one unbuffered kernel read to be free of race conditions. See [1].…
Yup. Some parts of the API are a huge annoyance like that. Also there's no guarantee whatsoever that /proc/123 is going to refer to a specific process, or to remain existing while you get all the data you need. The whole API is full of race conditions.
>Also there's no guarantee whatsoever that /proc/123 is going to refer to a specific process
does using openat solve that or is there some kind of directory inode reuse occurring?
Re: Not knowing the /proc file system
#17The Linux /proc "file system" is kernel to user space communication hammered into the wrong form because "everything is a file". /proc is a system call with a fake file system API, and this matters. The sample code won't work reliably, because it assumes that the "files" won't change while being read. If you read /proc, you must "read" each file with one unbuffered kernel read to be free of race conditions. See [1].…
“The Linux kernel has no standard mechanism for delivering a variable-sized result from a system call.”
In NetBSD you can create XML serialized system calls for this. :-)
Re: Not knowing the /proc file system
#18Tangent: Looking at those code samples, I wonder whether coming up with the shortest possible, most cryptic variable names is somewhat of a sport amongst C developers. Are you guys still coding in Notepad and need to conserve keystrokes, or where does that reluctance to use proper names come from?
To some extent, I like when people do it in other languages. It exhibits strong exposure to older programming material (where overshort vars abound), evincing great passion for programming, computer science etc.
A lot of lisp material features single letter vars, for example. (Actually, var length in prod code bases seems related to scope. So toy examples with obvious context see single letters strewn about. But digging through the classic books will rub off on the budding programmer...
Re: Not knowing the /proc file system
#19Probably off-topic: I may miss something but I have the feeling the shown C program should segfault a lot as the variable `fname` in `char* make_filename(const char*)` does not seem to be initialized.
Yeah it should be something like
char fname[BUFSIZE];
Re: Not knowing the /proc file system
#20Tangent: Looking at those code samples, I wonder whether coming up with the shortest possible, most cryptic variable names is somewhat of a sport amongst C developers. Are you guys still coding in Notepad and need to conserve keystrokes, or where does that reluctance to use proper names come from?
Because for some reason many C programmers still insist on 80-character line length limit and 8-wide tab indentation, so something has to give to fit all on the screen