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

21–30 of 181 posts

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

#21

Post by EliRivers »

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 shouldn't use it; it just means we should demand high standards of the programmers and not employ some chancer who learned how to program from the back of a cereal packet. I give young children plastic safety scissors. I give competent adults chainsaws and scalpels.

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

#22

Post by Mayzie »

> But zeroing a structure with memset, though it will set any integer members to zero, is not guaranteed to set floating-piont members to 0.0 or pointers to NULL (though it will on most systems).

Why is that? On those systems, is a sequence of 0 bits not considered 0.0f or NULL?

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

#23

Post by EliRivers »

sipior wrote: post #17
EliRivers wrote: post #12

Earlier quoted context omitted.

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.

In the words of SLJ, allow me to retort. Bytes and octets are the same today on the hardware the OP is used to working with; I'm guessing whatever the latest generation of commodity x86 derivatives is.

The real crime here isn't lack of knowledge; it's thinking that one's own narrow experience is all-encompassing and that what's true in one part of the programming world is true everywhere.

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

#24

Post by kabdib »

JoachimSchipper wrote: post #18
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!)

PDP-11s always used 8-bit bytes, you're probably thinking of the PDP-8.

I don't remember what the popular sizes for the PDP-10 were. A 36-bit machine, none of the choices were really great. (I know that CLU on the PDP-10 used 36 bits).

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

#25

Post by pjmlp »

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…

See, that is the problem right there.

Even if one does find such competent programmers, I doubt they the way C culture works it would help.

Most C devs I have met, if given a memory safe systems programming language like Modula-2 or Rust, would just use SYSTEM or unsafe {} everywhere without any proof of a profiler if it really matters to the customer.

As for being available everywhere, that is an historical accident of C's adoption. I remember when C was only available in UNIX and we had things like RatC.

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

#26

Post by masklinn »

Mayzie wrote: post #22

> But zeroing a structure with memset, though it will set any integer members to zero, is not guaranteed to set floating-piont members to 0.0 or pointers to NULL (though it will on most systems). Why is that? On those systems, is a sequence of 0 bits not considered 0.0f or NULL?

Not sure about fp, but the C standard very carefully and explicitly notes that NULL pointers doesn't mean a runtime value of 0. The comp.lang.c FAQ 5.17[0] further provides examples of nonzero NULL pointers e.g.

> The CDC Cyber 180 Series has 48-bit pointers consisting of a ring, segment, and offset. Most users (in ring 11) have null pointers of 0xB00000000000.

This is a bit confusing because the "null constant" is an integral 0 e.g. `(void ) 0` is a null pointer, but it's defined as an arbitrary compiler instruction. `(void ) foo` where foo is 0 at runtime may not be a null pointer at all.

[0] http://c-faq.com/null/machexamp.html

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

#27

Post by sipior »

EliRivers wrote: post #23
sipior wrote: post #17

Earlier quoted context omitted.

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.

In the words of SLJ, allow me to retort. Bytes and octets are the same today on the hardware the OP is used to working with; I'm guessing whatever the latest generation of commodity x86 derivatives is. The real crime here isn't lack of knowledge; it's thinking that one's own narrow experience is all-encompassing and that what's true in one part of the programming world is true everywhere.

I'm not disputing your last statement. I'm saying that, if you are going to quote someone, quote the whole sentence, at least, and don't leave out words that are substantial to the point they are making.

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

#28

Post by nabla9 »

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://processors.wiki.ti.com/index.php/Byte_Accesses_with_t...

C is the closest thing to universally portable assembler.

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

#29

Post by pcwalton »

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…

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

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

#30

Post by lultimouomo »

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…

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

Post reply on HN