61–70 of 118 posts
Earlier quoted context omitted.
Cases can arise where ownership of objects are not clear (which is a separate issue) but when they do occur, you can have a custom destructor that frees a lot of other objects, and then these other objects may in fact be "owned" elsewhere. Somewhere down the line these other objects are freed again, causing double free.
This sounds much more like a case of awful design than destructors being problematic
Earlier quoted context omitted.
I would argue it's very easy to think one understands it. However I would wager most people who say they understand C don't really know many of the undefined behaviour cases and their implications.
Undefined behaviour being weird and having bizarre implications is not a feature of C. It is a feature introduced by compiler writers who prize esoteric optimisations more than simplicity. And it is not forbidden by the standard, though discouraged.
Use-after-free or double-free is undefined behavior.
Therefore a C implementation that provides malloc(3) should provide an implementation of free(3) that is a no-op and provide a garbage collector that actually frees the memory.
Earlier quoted context omitted.
Undefined behaviour being weird and having bizarre implications is not a feature of C. It is a feature introduced by compiler writers who prize esoteric optimisations more than simplicity. And it is not forbidden by the standard, though discouraged.
Following your argument: Use-after-free or double-free is undefined behavior. Therefore a C implementation that provides malloc(3) should provide an implementation of free(3) that is a no-op and provide a garbage collector that actually frees the memory.
It's not an argument, it's an observation and statement of fact.
> Use-after-free or double-free is undefined behavior.
Yes.
> Therefore
Why therefore?
> a C implementation that provides malloc(3) should provide an implementation of free(3) that is a no-op and provide a garbage collector that actually frees the memory.
If you think so. It certainly doesn't follow from what I wrote. My point is that if you use a pointer after you freed the memory, you get whatever is in memory that the pointer points at on the machine the code is running on.
That is not a "weird and bizarre" implication, it is a plain and straightforward implication given how C is implemented on real machines. It is (obviously, I hope!) outside of the scope of the C standard to say what will be at that memory location at that point, and therefore it is UB.
And it being UB, "what you get" may also, for example, be a segfault because the library/OS have decided to unmap that memory. And again, that is also not "weird and bizarre", but perfectly straightforward.
¯\_(ツ)_/¯
Earlier quoted context omitted.
> From the software's perspective, the ISA is the hardware Precisely! And because the weirdness happens below the ISA, all the mismatches Dave Chisnall describes apply to any other language just as much including actual machine language. So raw machine language is not a low-level language? .
It is rare to build general purpose computing hardware in lockstep with software. The two worlds are only bridged by the ISA interface. It'd be interesting to see what interface we'd choose today with multiple decades of hardware and software development.
I have a sneaking suspicion that a more dataflow-oriented interface might be useful. The CPUs do dataflow analysis, the compiler does dataflow analysis, and higher levels are also often dataflow, but all communicate using a non-dataflow instruction stream. On the other hand, the only commercial dataflow CPU I am aware of, the NEC 7281 (http://www.merlintec.com/download/nec7281.pdf) was less than successful.
This entire article seems to amount to "I am used to C, thus I don't see the problem with C." which is a fine position to have, but it's a perspective unique to the writer and others like him. It doesn't apply to people learning new languages that aren't C. Also several statements about how C must be used because somehow it's closer to the real world/hardware than other languages. Which is easily shown to be false gi…
We'd be in a damn sight better place if it was, though.
This entire article seems to amount to "I am used to C, thus I don't see the problem with C." which is a fine position to have, but it's a perspective unique to the writer and others like him. It doesn't apply to people learning new languages that aren't C. Also several statements about how C must be used because somehow it's closer to the real world/hardware than other languages. Which is easily shown to be false gi…
> C Is Not a Low-level Language: Your computer is not a fast PDP-11. We'd be in a damn sight better place if it was, though.
Earlier quoted context omitted.
I would be interested to see someone write a program in any language (other than ones specifically designed to combat this, rust…) using threading and guarantee it to be data/race safe. But, I’m not arguing with you. I honestly think that any corporate codebase after double digit years (and seven figure LoC) turns into a completely unmanageable mess. If it isn’t, it’s because of the team culture and pure rigor. Not t…
> I would be interested to see someone write a program in any language (other than ones specifically designed to combat this, rust…) using threading and guarantee it to be data/race safe. I don't limit my statement to just C. The topic was C however so I mentioned C.
Your comment reads like a red herring though. You're not actually trying to argue that C makes thing easier or hard. Your red herring only means that hard problems affecting all languages aren't magically turned into non-issues in C. You can still write a C program that uses threading and is as safe as any other language and end up being a far simpler project, but that means nothing because the subject is still hard. And what would that actually say about C, let alone refute?
Pointers and pointer math were a 10 billion dollar mistake.
Unchecked array access is a several billion dollar mistake.
Goto has its place: consolidated resource error unwind cleanup. That's basically its only valid use except for mechanically-generated finite state machines. Beyond that, don't bother. Other programming languages use reference counting and lifetimes to manage resources.
int
foo() {
void *b0 = malloc(1000);
if (!b0) goto err0;
/* do something */
void *b1 = malloc(1000);
if (!b1) goto err1;
/* do something else */
void *b2 = malloc(1000);
if (!b2) goto err1;
/* keep going */
/* ... */
free(b2);
free(b1);
free(b0);
return 0;
err3:
free(b2);
err2:
free(b1);
err1:
free(b0);
err0:
return 1;
}Unmanageable really has a context and depending on the use case sometimes C is the best option…
Only when there isn't a C++ compiler around, even if we restrict ourselves to the common subset, C++ has stronger type safety, while constexpr + templates are way better than macros.
The primary benefit to C is that it is simple. And that is IMO the reason why it has such sticking power. The entire language & toolchain is understandable at a fairly core level without too much effort. Please don’t start a C flame war either HN. I know I’m nerd sniping you all on this one
C has near universal portability. It's everywhere. That's the most important property.