Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
What's really great about C strings: you can have a pointer to somewhere in the string and hand that over to any string parsing routine to parse the remainder of the string.
-
@electrineer nah, no fling for the g-string. Better no clothes at all. (somehow I was thinking about guitars first - probably my head wanted to avoid awkward pictures..)
-
Root797484yI prefer Pascal strings.
One bite of overhead; much faster and easier to work with.
Downside: limited to 255 bytes. 🤷🏻♀️ -
@Fast-Nop there might be nice hacks, but in general I don't like the length information only be retrievable in O(n), and most operations also being O(n).
-
Root797484y@phorkyas Pascal strings.
They’re C strings with one small change: string[0] contains the length of the string. This allows you to fetch the last character in two operations instead of O(n). It also helps with e.g. memcpy, comparisons, etc.
It’s the light version of what @halfflat suggested. -
@Root You speak right from my soul.
(German English but too late to find correct translation)
(I meant for bringing up pascal strings. Kept searching too long fort translation) -
@phorkyas That's mostly an issue if it suddenly turns into O(n^2), which it does when repeatedly appending strings to a given string.
In that case, the usual solution is a custom strcat that returns a pointer to the nullbyte (after appending). -
@halfflat I still have fond memories of Pascal. The compiler was so fast (TurboPascal). And just clicking together your dialogs in Delphi felt cool in 1998.
Now I'm mostly in C/C++, which is OKish only macOS manages to be a bigger PITA than the full distro hell of Linux together. -
@halfflat Usually, I love rant, especially if it pisses at so well established an painful like CMake. But then again: Aren't a lot of the pains self inflicted? This dumb tool was only meant to generate your build system/files, why should it write binary output itself? Maybe you can open a tin with a fork, but no wonder it'll be painful. (but yeah computing: just give me Nand operation to build a CPU, Turing complete language to do universal computing or a write/read primitive to own your device - so sure you can do _anything_ in Cmake)
-
I’m not a c expert, but is this more like a c make problem than a c problem? Isn’t c strings really fucking simple?
-
@jesustricks So they seem, but then someone messes up some edgecase and there is the next vulnerabity. Or Linux introduces a hack like abstract namespspace sockets (which I love) with a NUL termonation at the start!
CMake is adifferent story. Also extremely string based. Eg a list is just a string with elements delimited by ';'.
Another hours wasted on debugging, on what I hate most about programming: strings!
Don't get me started on C-strings, this abomination from hell. Inefficient, error prone. Memory corruption through off by one errors, BSOD by out of bound access, seen it all. No, it's strings in general. Just untyped junk of data, undocumented formats. Everything has to be parsed back and forth. And this is not limited to our stupid stupid code base, as I read about the security issues of using innerHTML or having to fight CMake again.
So back to the issue this rant is about. CMake like other scripting languages as bash have their peculiarities when dealing with the enemy (i.e. strings), e.g. all the escaping. The thing I fought against was getting CMake's fixup_bundle work on macOS. It was a bit pesky to debug. But in the end it turned out that my file path had one "//" instead of an "/" and the path comparison just did a string comparison without path normalization.
Stop giving us enough string to hang ourselves!
rant
debugging shit
scripts of death
fuck file paths
fuck macos
string to hang ourselves
fuck strings
cmake hell