101–110 of 111 posts
Earlier quoted context omitted.
AFAICT, getline() is not available on Windows, neither with MSVC nor MinGW. The actual solution is to use C++ instead of C :)
That shouldn't be a big deal for accessing the /proc filesystem as that's also not available on Windows, AFAIK.
int s_isdigit(const char* s) { Name does not fit implementation. Should be "contains_digit". Also I would say almost any "issomething" method involving a loop has an opportunity for an early return.
As written, it should be `s_hasdigit`, but it's actually wrong - it should be: int s_isnum(const char* s) { int result = (*s != '\0'); while (*s != '\0') { if ((*s otherwise, it will choke on directories like `/proc/etc64/` or `/proc/net6/` if any such directory is added. (Plus other bits like early return, but that's not a correctness bug.)
Earlier quoted context omitted.
CNLabelContactRelationBiaoMei would have been a lot better. People can look up what that means when they need to.
I haven't been a dev in a bit, but I'd say between having a longer variable name, and having to crack open the fucking dictionary.... I have a clear preference.
Earlier quoted context omitted.
I haven't been a dev in a bit, but I'd say between having a longer variable name, and having to crack open the fucking dictionary.... I have a clear preference.
You can apply this logic to anything. If you were working on database software, would you make a variable transactionId or idOfGroupOfStatementsThatMustBeExecutedAtomically ?
The 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].…
> I’m using a custom function for reading lines from a file. [Listing: fgetLine()] It’s probably easier to just use getline(), it does basically the same thing and is in POSIX.1-2008[1]. [1] https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...
A general review of the stdlib https://nullprogram.com/blog/2023/02/11/
A review of scanf https://sekrit.de/webdocs/c/beginners-guide-away-from-scanf....
Originally I implemented `getLine` (terrible name!) as a way to get multiple lines of input from stdin in a relatively safe way. The implementation borrows almost all of its ideas from the `sekret.de` post. Because I knew the implementation and it was close to hand on my machine, I used it for this version and just swapped out `stdin` for just any old file.
Edit: here's the implementation for reference, https://github.com/adammccartney/algorithms/blob/master/libs...
Tangent: 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.
Earlier quoted context omitted.
You can apply this logic to anything. If you were working on database software, would you make a variable transactionId or idOfGroupOfStatementsThatMustBeExecutedAtomically ?
I was thinking along these lines when I wrote my post... I think there's some domain knowledge that can be expected. A DB dev is probably expected to know what an "id" is. But probably 99.9999999% of devs even working with the address book APIs can't be expected what to know what "BiaoMei" is unless they are Chinese to begin with.
When 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.
It would be cool if they just said "Everything here will be TOML" or something.
But I like to stick with higher level tools anyway and avoid touching the low level stuff on Linux, so it's fine in practice.
Earlier quoted context omitted.
As written, it should be `s_hasdigit`, but it's actually wrong - it should be: int s_isnum(const char* s) { int result = (*s != '\0'); while (*s != '\0') { if ((*s otherwise, it will choke on directories like `/proc/etc64/` or `/proc/net6/` if any such directory is added. (Plus other bits like early return, but that's not a correctness bug.)
Thanks for this! Had not been aware of files such as `/proc/net6/` or `/proc/etc64/`. Will include this as an edit to the original post.