strncpy was originally used to write into fixed length buffers[1]. This becomes obvious when considering the padding behavior, as described in the C standard[2]: "If the array pointed to by s2 is a string that is shorter than n characters, null characters are appended to the copy in the array pointed to by s1, until n characters in all have been written."
strlcpy, often touted as a replacement, does not elicit the padding behavior but has another flaw: It is supposed to return the length of the string it tried to create, for example, so the user can call realloc without calling strlen again.[3] However, this final "strlen-tail" in strlcpy isn't bounded by the size parameter which describes dest, not src.
While strscpy is a marked improvement, there is still something to be careful about: It can read past the end of the src-buffer, when sizeof src < sizeof dest and src is not nul-terminated.[4] (Set the count argument to something like min(sizeof dest, sizeof src) to avoid that).
Game theoretic modelling commonly results in early escalation followed by a slower de-escalating as a winning strategy. Fits into the strong-arm approach to politics of exercising power to expand power which the current US administration seems to follow.
Thus, I wouldn't think that decoupling or falling of a cliff is the intended goal.
Problem here is that the excessive focus on secondary issues raises the perception of a problem solving deficit which reduces support/legitimacy for the political system.
It would be nice to focus on solving more existential problems of which there are enough.
Seems to me that everyone is focused on the technical merits, not weighing the effort of learning a new programming language/toolchain/ecosystem for the maintainers appropriately.
Mastering a new programming language to a degree that makes one a competent maintainer is nothing to sneeze at and some maintainers might be unwilling to based on personal interests/motivation, which I'd consider legitimate position.
I think its important to acknowledge that not everyone may feel comfortable talking about their lack of competence/disinterest.
One benefit they list is storing associated metadata in the database (specifically different types of hashes are mentioned) which is not so easy with a file system.
I think the bigger benefit though is the increased read performance on many small files (saving system call overhead). To which amount that applies to static files that a smart server might keep in cache, I don't know.
> As it is, most Issues are polluted by random support requests, suggestions and open-ended chat which obscures the focus so much that sometimes I just can't tell what they need help with, so I don't bother offering.
Totally agree. They should have some AI solution categorize the issues and separate actual issues/tickets from support requests and other noise.
One problem I always had with VSCode, is that it seems to fill up its autocomplete suggestions with "near-string-matches" from files all over the project. The jetbrains tools are quite strict in that regard and won't propose random string matches that don't fit semantically.
> That's why TCP (or maybe it's Ethernet?) frames include FEC bytes in their message format.
Neither TCP nor Ethernet provide for forward error correction. Ethernet frames include a 32-bit CRC while TCP segments use the so called "internet checksum".
Tip: Install the IDE inside WSL2. Should also run somewhat faster, especially any operation which has to do with many small files, at the expense of a tiny bit of latency in the GUI.
Sounds very similar to how e.g. docker/layers work - the later you put the more dynamic stuff, the higher the change that previous layers are reused.
Meaning the cache entries are likely chained, i.e., each one depends on the preceding entry.
strlcpy, often touted as a replacement, does not elicit the padding behavior but has another flaw: It is supposed to return the length of the string it tried to create, for example, so the user can call realloc without calling strlen again.[3] However, this final "strlen-tail" in strlcpy isn't bounded by the size parameter which describes dest, not src.
While strscpy is a marked improvement, there is still something to be careful about: It can read past the end of the src-buffer, when sizeof src < sizeof dest and src is not nul-terminated.[4] (Set the count argument to something like min(sizeof dest, sizeof src) to avoid that).
--
[1] - https://softwareengineering.stackexchange.com/a/438090
[2] - https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf, 7.26.2.5 p. 3
[3] - https://manpages.debian.org/jessie/libbsd-dev/strlcpy.3.en.h...
[4] - https://manpages.debian.org/testing/linux-manual-4.8/strscpy...