31–40 of 387 posts
C has never been "how the computer works", its abstract model is way too… well, abstract. But there is an interesting catch to it: because C is so important, and programmers at large know so little "real C", vendors do their damndest to make it work for them. A well-known microcontroller forum in Germany is constantly pushing that you need to make your code safe in the case of concurrent access to a variable by a mai…
This may be a little off topic but it is something that until now I’ve never questioned in my entire career: Is the c in C supposed to stand for “computer“? If not, what is it?
This may be a little off topic but it is something that until now I’ve never questioned in my entire career: Is the c in C supposed to stand for “computer“? If not, what is it?
Actually I look forward for enough momentum to be created in the community, to allow new C standards to change the way undefined behaviors are conceived, and make them as specified as possible, and even when they cannot in reasonable unique ways, to provide reference possible behaviors to select in order to have the least unexpected outcome for the programmer. Especially now that low level programming is abstracting…
[1] well, you can today by swapping malloc for a GC-enabled implementation, but the fact is that almost nobody does.
Actually I look forward for enough momentum to be created in the community, to allow new C standards to change the way undefined behaviors are conceived, and make them as specified as possible, and even when they cannot in reasonable unique ways, to provide reference possible behaviors to select in order to have the least unexpected outcome for the programmer. Especially now that low level programming is abstracting…
Of all the potential issues that might be attributed to C, undefined behavior (UB) is the one that creates few to no problems at all.
To me, complaining about UB is like complaining about the quality of a highway once they intentionally break through the guard rails and start racing through the middle of the woods.
The reason why some behavior is intentionally left undefined is to enable implementations to do whatever they find best in a given platform. This is not a problem, it's a solution to whole classes of problems.
This may be a little off topic but it is something that until now I’ve never questioned in my entire career: Is the c in C supposed to stand for “computer“? If not, what is it?
Wait until they learn that machine code is not exactly how the computer works either. The hardware is doing things to your code you might not expect.
We tend of think of everything as an ideal model in a vacuum, forgetting that in real life that the implementation details are often gory with caches and microcode and fault tolerance and all sorts of hidden details put in there to make things easier to work with or faster.
Actually I look forward for enough momentum to be created in the community, to allow new C standards to change the way undefined behaviors are conceived, and make them as specified as possible, and even when they cannot in reasonable unique ways, to provide reference possible behaviors to select in order to have the least unexpected outcome for the programmer. Especially now that low level programming is abstracting…
C has never been "how the computer works", its abstract model is way too… well, abstract. But there is an interesting catch to it: because C is so important, and programmers at large know so little "real C", vendors do their damndest to make it work for them. A well-known microcontroller forum in Germany is constantly pushing that you need to make your code safe in the case of concurrent access to a variable by a mai…
main thread -> interrupt processing -> resume main thread.
If you're modifying a variable in the interrupt you should declare it volatile so as to avoid the compiler optimizing it and introducing unexpected behavior. Adding a mutex would just be worthless overhead.
C has never been "how the computer works", its abstract model is way too… well, abstract. But there is an interesting catch to it: because C is so important, and programmers at large know so little "real C", vendors do their damndest to make it work for them. A well-known microcontroller forum in Germany is constantly pushing that you need to make your code safe in the case of concurrent access to a variable by a mai…
Yes, except it's "less abstract" than any other language in mainstream use...
That other languages don't qualify, either, is beside the point. Ruby or Java aren't mistaken to be close-to-metal.
Point in case: you don't even see anything about Harvard vs. von Neumann architecture in portable C sources. Not to speak of micro code or anything like that.