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

11–20 of 181 posts

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

#11

Post by omginternets »

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.

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?

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

#12

Post by EliRivers »

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.

Oh, well, if you haven't seen something then it must not exist.

"I wasn't even told that there once were systems where this wasn't true until fairly recently."

Wait, so someone filled in a piece of your ignorance and your response is still "Bytes and octets are the same"?

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

#13

Post by XorNot »

avian wrote: post #5

> 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…

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.

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

#14

Post by ue_ »

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.

>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 the standard does not define this assumption, screams of unportable code. You might as well use GCC extensions - after all, for a long time, what would it matter? Everyone used GCC, right?

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

#15

Post by stupidcar »

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?

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

#16

Post by XorNot »

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.

Yeah at least since the 80s bytes has been taught as "8 bits" for as long as I've ever heard it.

That said, uint8_t is more explicit (and less to write).

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

#17

Post by sipior »

EliRivers wrote: post #12
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.

Oh, well, if you haven't seen something then it must not exist. "I wasn't even told that there once were systems where this wasn't true until fairly recently." Wait, so someone filled in a piece of your ignorance and your response is still "Bytes and octets are the same"?

To be fair, what they actually said was, "Bytes and octets are the same today". It's a little disingenuous, I think, to quote everything but the last word, especially since the qualifier "today" was kind of their entire point.

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

#18

Post by JoachimSchipper »

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.

char is apparently still not always 8-bit on current DSP chips, where everything is 32-bit. Historically, PDP-8's used 12-bit bytes and Crays also used 32-bit bytes.

(EDIT: fixed PDP-11 -> PDP-8, thanks kabdib!)

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

#19

Post by methyl »

ue_ wrote: post #14
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.

>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…

> People may wish to run code on "historical" systems, and someone may wish to create a 9-bit byte system for fun.

I bet there will be then bigger problems with porting the code than assuming byte is 8 bit long if someone is creating a 9-bit system "for fun".

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

#20

Post by JoachimSchipper »

XorNot wrote: post #13
avian wrote: post #5

> 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…

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

Post reply on HN