Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A critique of "How to C in 2016"

github.com

Post reply on HN
Print view View original

31–40 of 181 posts

Re: A critique of "How to C in 2016"

#31

Post by stupidcar »

EliRivers wrote: post #21
stupidcar wrote: post #15

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?

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.

Re: A critique of "How to C in 2016"

#32

Post by Anilm3 »

One of the most important reasons to use calloc, other than the zeroing of the allocated memory, is the fact that it checks for integer overflows (at least on most implementations).

For example, when allocating an array of n elements, in malloc you would do something like the following:

ptr = malloc(sizeof(int) * n);

Which could potentially lead to an overflow of the size passed to malloc, hence allocating a significantly smaller buffer and end up accessing adjacent memory which hasn't been allocated to the buffer (buffer overflow)

Calloc requires two arguments, one for size and one for number of elements, which allows it to check for an overflow before performing an allocation (e.g. by using SIZE_MAX):

ptr = calloc(n, sizeof(int));

This is not to say that zeroing memory is not useful. There are many situations in which a zero in a memory block represents the end of the usable data, as for example in a string, so zeroing memory in those situations is definitely recommended.

Re: A critique of "How to C in 2016"

#33

Post by pjmlp »

grabcocque wrote: post #8

This, ladies and gentlemen, is why C gives me the willies. And why this happens: http://www.cvedetails.com/vulnerability-list/year-2016/month...

Not that it would eliminate security exploits caused by logical bugs, but most those exploits were already taken care of with Burroughs Algol variant (1961), Modula-2 (1978), Cedar (1981), Ada (1983), .... but oh well.

Re: A critique of "How to C in 2016"

#34

Post by lucian1900 »

EliRivers wrote: post #21
stupidcar wrote: post #15

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?

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…

As a society, we still avoid tools that are easy to misuse whenever we can. Modern chainsaws have several safety features that were missing from earlier ones and that doesn't make them less useful.

Just because the most popular systems language is dangerously unsafe doesn't mean a safe alternative couldn't replace it (like, say, Rust).

Re: A critique of "How to C in 2016"

#35

Post by xcgvgh »

>size_t is defined as "an integer capable of holding the >largest array index"

>>No, it isn't.

Could anyone elaborate?

I don't see how could someone allocate more than SIZE_MAX bytes with (m/c/re)alloc since they all take size_t as an argument, and size_t is the type used for defining array sizes. Thus size_t can hold the largest array index (in fact it can hold the largest_index+1 since arrays are zero based). Any counterarguments?

Re: A critique of "How to C in 2016"

#36

Post by anon1385 »

JoachimSchipper wrote: post #20
XorNot wrote: post #13

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.)

https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-077...

>- "out_start == out_last" (lines 205-206): no data was ever written to out_buf (and both out_start and out_last are still equal to 0) because no data was ever sent to the server after roaming_reply() was called, but the client sends (leaks) the entire uninitialized out_buf to the server (line 214), as if out_buf_size bytes of data were available.

Re: A critique of "How to C in 2016"

#37

Post by pjmlp »

nabla9 wrote: post #28
legulere wrote: post #9

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.

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.

Re: A critique of "How to C in 2016"

#38

Post by ue_ »

pcwalton wrote: post #29
ue_ wrote: post #14

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…

As a matter of fact, GCC extensions are de facto standards at this point. Clang had to copy most of them. Same with bytes not being 8 bits. Nobody will ever make a system where that's not the case anymore. You'd break de facto compatibility with almost all C code for no reason. Market realities trump making systems "for fun".

>You'd break de facto compatibility with almost all C code for no reason.

The authors of that code should have written portable code if they didn't want it to break.

Re: A critique of "How to C in 2016"

#39

Post by chrisseaton »

xcgvgh wrote: post #35

>size_t is defined as "an integer capable of holding the >largest array index" >>No, it isn't. Could anyone elaborate? I don't see how could someone allocate more than SIZE_MAX bytes with (m/c/re)alloc since they all take size_t as an argument, and size_t is the type used for defining array sizes. Thus size_t can hold the largest array index (in fact it can hold the largest_index+1 since arrays are zero based). Any c…

Maybe he's taking it very literally, as I think size_t is literally defined as 'the integer type of the result of the sizeof operator'. So it literally isn't defined as 'an integer capable of holding the >largest array index' as that's not the definition and words they use.

Re: A critique of "How to C in 2016"

#40

Post by Avshalom »

EliRivers wrote: post #21
stupidcar wrote: post #15

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?

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…

Those compilers exist because of path dependency from unix not from any unique qualities of C
Post reply on HN