41–50 of 181 posts
Ironic that he begins by taking issue with the idea that you should avoid writing C if you can, then proceeds to provide the best evidence possible for why it's true. Why on Earth would you voluntarily code in a language where people can debate something as simple as which type to use for integers, unless you absolutely had to?
> Zeroing memory often means that buggy code will have consistent behavior; by definition it will not have correct behavior. And consistently incorrect behavior can be more difficult to track down. I agree that using calloc should not be an excuse for writing sloppy initialization code. But in my experience, inconsistently incorrect behaviour (e.g. heisenbugs that tend to appear and disappear depending on the content…
Earlier quoted context omitted.
>Bytes and octets are the same today. I never came across a system where this wasn't true. The fact that all modern systems use eight bit bytes is no reason to assume that a byte is eight bits. The fact is that a byte is not eight bits large. People may wish to run code on "historical" systems, and someone may wish to create a 9-bit byte system for fun. To write C code with an assumption that things are one way, when…
By the same argument we shouldn't assume that bits have only two values - what, you mean I can't write C for my ternary logic computer? You need to make a decision about which simplifying assumptions you make - C has decided not to assume there are 8 bits to the byte. I think it's arguable that in 2016 this is not the best decision, and they could get rid of some cognitive overhead by making the simplifying assumptio…
C is one of the very, very few languages that you can reasonably expect to run on your weird embedded microprocessor, microcontroller, DSP, or whatever.
Bit, however, means "binary digit". That's the literal definition of the word. Historical usage of the word "byte" has varied.
Earlier quoted context omitted.
It's also more secure. We've just this week now had an SSH bug where random chunks of memory get dumped somewhere they shouldn't (not that I'm clear on if calloc would help in this case, but the issue remains). Zeroing memory is just good habit - it's means you don't wind up accidentally leaking things when you make a mistake. And you should assume you will.
calloc is not relevant to that issue - it's an out-of-bounds read. (Good ASLR does help, by turning such issues into crash bugs.)
Earlier quoted context omitted.
Because it's simple and low-overhead and compilers for it exist on every lump of hardware I've ever had to work with, from a clunky x64 to a PIC to a TigerSHARC to a bizarre DSP thingy from a tiny fab lab somewhere. A great many of the problems that people experience with C code can actually be nullified (zing!) by finding a competent C programmer who does the job properly. A tool being easy to misuse doesn't mean we…
Again, if people can't agree what type to use for integers, then it's not "simple". And yes, a tool being easy to misuse absolutely means we shouldn't use it unless we have to. A competent adult would never use a chainsaw or a scalpel except for tasks where nothing else would work.
I can't make it any simpler. There is no one true magical perfect solution for all circumstances in all places at all times. This is why I employ competent programmers; to make these choices.
A competent adult would never use a chainsaw or a scalpel except for tasks where nothing else would work.
Of course they would. I do, frequently; not chainsaws and scalpels, but there are dangerous tools that I am really good with that I can produce really good work with, quickly and efficiently, and there are safe tools that would mean I take longer and can't do exactly what I want to do and produce a less satisfactory result. I don't pick the safe tool; I pick the right tool for the job, given the circumstances and the requirements.
Are there people who deliberately pick the tool that will give a worse outcome? If one of the tools available is something that the person using it isn't competent to use, that doesn't mean the problem is with the tool.
I freely accept that a good C programmer needs knowledge and experience beyond that of many programmers. This is not somehow a bad thing.
Earlier quoted context omitted.
Just one counterexample: Texas instrument C28x core is 16-bit addressable. Each byte is 16 bits. >The TMS320C28x byte is 16 Bits. By ANSI/ISO C definition, the sizeof operator yields the number of bytes required to store an object. ANSI/ISO further stipulates that when sizeof is applied to char, the result is 1. Since the TMS320C28x char is 16 bits (to make it separately addressable), a byte is also 16 bits. http://p…
I fail to see how C is more portable than any other memory safe systems programming language, other than having the fortune that for 30 years OS and hardware vendors decided to only support C compilers.
You can hype your favorite systems language all you want, but if there is no compiler, it wont compile.
>OS and hardware vendors decided to only support C compilers.
If you want your favorite language X to work everywhere C does. Just make X-to-C compiler.
Earlier quoted context omitted.
Just one counterexample: Texas instrument C28x core is 16-bit addressable. Each byte is 16 bits. >The TMS320C28x byte is 16 Bits. By ANSI/ISO C definition, the sizeof operator yields the number of bytes required to store an object. ANSI/ISO further stipulates that when sizeof is applied to char, the result is 1. Since the TMS320C28x char is 16 bits (to make it separately addressable), a byte is also 16 bits. http://p…
I fail to see how C is more portable than any other memory safe systems programming language, other than having the fortune that for 30 years OS and hardware vendors decided to only support C compilers.
I disagree with many of the arguments. Many of them are ignoring the reality of today. One example: > If you want bytes, use unsigned char. If you want octets, use uint8_t Bytes and octets are the same today. I never came across a system where this wasn't true. I was never told about a system where this wasn't true. I wasn't even told that there once were systems where this wasn't true until fairly recently.
What was the original distinction between bytes and octets? Byte = word vs octet = 8-bits, i.e. a byte is not necessarily 8-bits long?
Earlier quoted context omitted.
I fail to see how C is more portable than any other memory safe systems programming language, other than having the fortune that for 30 years OS and hardware vendors decided to only support C compilers.
Compilers. Compilers for everything. You can hype your favorite systems language all you want, but if there is no compiler, it wont compile. >OS and hardware vendors decided to only support C compilers. If you want your favorite language X to work everywhere C does. Just make X-to-C compiler.
Not an ideal situation, for sure, but a real one.
I disagree with many of the arguments. Many of them are ignoring the reality of today. One example: > If you want bytes, use unsigned char. If you want octets, use uint8_t Bytes and octets are the same today. I never came across a system where this wasn't true. I was never told about a system where this wasn't true. I wasn't even told that there once were systems where this wasn't true until fairly recently.
What was the original distinction between bytes and octets? Byte = word vs octet = 8-bits, i.e. a byte is not necessarily 8-bits long?