281–290 of 382 posts
Earlier quoted context omitted.
As much as I dislike C > There are only two kinds of languages: the ones people complain about and the ones nobody uses. This unfortunately seems to mostly hold true.
Porque no los dos? There are a few languages that nobody uses and also everybody seems to complain about.
"Porque" means Because. "Por que" means Why.
Earlier quoted context omitted.
My solution is different: Don't use dynamically-allocated variable-sized buffers unless you have to. C++ gives you more tools for avoiding them than C, BTW.
> C++ gives you more tools for avoiding them A direct link, for the curious: https://en.cppreference.com/w/cpp/container/array As an aside, the C’s Biggest Mistake article cropped up in HN discussion 8 days ago, https://news.ycombinator.com/item?id=24373728
Earlier quoted context omitted.
Going forward Android will require hardware metadata extensions on ARM devices, as of Android 11.
You bring this up often and I ask you to modify your wording about every time I see it. Android will not require these extensions, no hardware ships with it yet. Android says they will support it.
> Google is committed to supporting MTE throughout the Android software stack. We are working with select Arm System On Chip (SoC) partners to test MTE support and look forward to wider deployment of MTE in the Android software and hardware ecosystem. Based on the current data points, MTE provides tremendous benefits at acceptable performance costs. We are considering MTE as a possible foundational requirement for certain tiers of Android devices.
https://security.googleblog.com/2019/08/adopting-arm-memory-...
> Starting in Android 11, for 64-bit processes, all heap allocations have an implementation defined tag set in the top byte of the pointer on devices with kernel support for ARM Top-byte Ignore (TBI). Any application that modifies this tag is terminated when the tag is checked during deallocation. This is necessary for future hardware with ARM Memory Tagging Extension (MTE) support.
>....
> This will disable the Pointer Tagging feature for your application. Please note that this does not address the underlying code health problem. This escape hatch will disappear in future versions of Android, because issues of this nature will be incompatible with MTE
https://source.android.com/devices/tech/debug/tagged-pointer...
So unless you have other official feedback from Google management, I will keep repeating myself.
Earlier quoted context omitted.
I didn't say it should be the default, but yes it should be. It is for structs. We can have giant structs. I've seen some over a megabyte in size. The default is that the callee gets a copy. (depending on the ABI it could be in the "wrong" stack frame, but it is a distinct copy) Are we having huge problems with structs being passed by value? I don't think so. Normal people pass pointers, except when they actually wan…
The weird thing is that the compiler obviously knows how to copy an array, because you can pass a copy of a struct that contains an array. I have a vague impression that early versions of C couldn't pass either structs or arrays, only scalars and pointers.
> While [the first edition of K&R] foreshadowed the newer approach to structures, only after it was published did the language support assigning them, passing them to and from functions, [...]
In addition to unsafe/irregular buffer handling, I also constantly see poor data structure choice, presumably due to a lack of default choice of library. It is very common to see code scanning linked lists when they should be doing map look ups. (And often even the linked list operations are ad-hoc and repeated for every type of struct with an embedded next/prev pointer.) Everyone always defaults to linked listing it up because they never have to pay the up-front cost of finding a library or investing in re-inventing the wheel. I think this is also why you see so much sketchy buffer code - no one has bothered investing in safer buffer abstractions.
Perhaps some of this is caused by the difficulty of taking on dependencies in a portable way. (CMake/Autotools can make this better, but it is a far cry from NPM.)
Earlier quoted context omitted.
C will survive, if just for embedded/systems programming where you need a "portable assembly language" that can run on the simplest CPUs.
That's because of sunk-cost rather than design. Thanks to LLVM and GCC you can happily write embedded code in a higher level language, but the vendors don't bother supporting it because a lot of embedded coding isn't really what we would call software (no tests etc.)
Yes. As I've long said, C does not have arrays . It has pointers and notations for initializing memory, but it does not have arrays. There are actually two problems here. One is the absence of bounds checking. The other, which is related but technically orthogonal, is the hole in the type system: an array is not an object. It's been true since Unix v7 that you can pass or return a struct by value, but you can't pass…
About the singular vs array question: this is true but just a special case of the absence of bounds checking, is it not? C's approach of allowing e.g. "int i;" to be addressed as if it were an array of length 1, allowing construction not just of &i but also &i+1 as pointer values, is valid and sometimes useful, but you have to make sure you never access *(&i+1). That's the same problem as how given "int a[2];", accessing a[2] is not valid, as far as I can see.
1- Trying to find the proper style and methods to write few lines of code. The reason for this is because C is an old language that kept changing. Thus, you can read a book, yet find someone to tell you “you shouldn’t do it that way”.
2- compilers made C into different flavors. Microsoft C compiler provides scanf_s with the old scanf being deprecated. In the other hand, gcc has different approaches without the scanf_s that Microsoft has. This can be so annoying to use.
Earlier quoted context omitted.
It isn't. You can tell how much a language is used by the inverse of the number of blogposts about it. People who have jobs don't have the time to write about how they would solve problems using that language, because they already are and have better things to do in their free time.
It is. Since 2012 C has dropped from about 4% of Github code to 3%. Meanwhile Rust has climbed from 0 to about 1%. That on its own doesn't prove that people are moving from C to Rust but it's not a risky guess. I did see some data on language transitions a while ago but can't find it now unfortunately (why is browser history search still so shit?). https://madnight.github.io/githut/#/pull_requests/2020/2
Yes. As I've long said, C does not have arrays . It has pointers and notations for initializing memory, but it does not have arrays. There are actually two problems here. One is the absence of bounds checking. The other, which is related but technically orthogonal, is the hole in the type system: an array is not an object. It's been true since Unix v7 that you can pass or return a struct by value, but you can't pass…
It would help if you define what you mean by "object". This term has a definition in the C standard by which arrays are unquestionably objects. It is true that you cannot pass or return them by value, but that does not mean they are not objects, that means the ability to pass or return things by value is not a property of objects. About the singular vs array question: this is true but just a special case of the absen…