A critique of "How to C in 2016"

https://github.com/Keith-S-Thompson/how-to-c-response

by _quhg • 11 years ago

157 178 11 years ago

unwind• 11 years ago

Aah, this felt like a much-needed piece. The original text was so long, it kind of made my eyes glaze over and I never found the time to do this level of detailed critique. Well done!

eloy• 11 years ago

Not to be confused with Ken Thompson.

rocks• 11 years ago

Almost fell for that....

avian• 11 years ago

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 of some random chunk of uninitialized memory that happens to be in an unfortunate state after malloc) are one of the hardest type of bugs to fix. It's the type of the bug that occasionally happens in production and typically can't be reproduced in a controlled manner in a development environment. I certainly prefer consistently incorrect behavior.

XorNot2• 11 years ago

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.

JoachimSchipper2• 11 years ago

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

dietrichepp10• 11 years ago

The tools for rooting out these problems have gotten a lot better, thankfully. I'm very fond of the address sanitizer. Using calloc() everywhere can prevent the address sanitizer from finding problems.

neopallium• 11 years ago

GCC (>=4.8) & Clang now have Address Sanitizer support for fast memory error detection. About a 2x slowdown [1].

0. https://github.com/google/sanitizers/wiki/AddressSanitizer 1. https://github.com/google/sanitizers/wiki/AddressSanitizerPe...

gsg• 11 years ago

You could try to split the difference by using a wrapper around malloc that zeroes in production and doesn't under testing.

Of course, running significantly different code in production and test has its own issues.

DrJokepu• 11 years ago

I mean, reading zeroed out memory is not really incorrect behaviour anyway. If you know that it was zeroed out, then you're really just reading memory that was initialised with a specific default value.

That being said, zeroing out everything you allocate will make it difficult for the kernel's paging system to defer allocating you a physical page until you actually need it, so you will need to be a lot more careful with your allocations if your application uses relatively large amounts of memory and you need to work with memory constraints.

rc4algorithm4• 11 years ago

Unless the zeroing is defined by the language, assuming it t is incorrect and shouldn't be done.

appleflaxen3• 11 years ago

Great point.

This is the part I disagree with most strongly:

And consistently incorrect behavior can be more difficult to track down.

rc4algorithm4• 11 years ago

All of that useless zeroing is very painful from a performance perspective. It just isn't a reasonable option in performance-relevant code like kernels and core infrastructure. The Moore's Law argument doesn't apply because memory bus latencies and case pressure are lasting problems.

efaref• 11 years ago

On high-performance code for an embedded PPC system I used to work on, we made all our control block a multiple of the L1 cache width. Our allocation routines then all had inline assembler to run the dcbz instruction (data cache block zero) on all the cache blocks for the control block as it was allocated. This meant the control block was always zeroed, and the memory bus wasn't touched in order to do so. Yes, things were evicted from the cache, but since we're about to start writing things into the control block, the lack of fetch was a net gain.

ori_b• 11 years ago

A better solution in this case is to fill the memory with junk -- 0xdeadbeef is a popular solution.

geocar• 11 years ago

I'm divided.

I think it is good to share our ideas and our theories with each other because the discourse can stretch our minds and help us better imagine the perspective of another. Dialogue can foster creativity and invention, and an honest argument can embiggen friendships like nothing else.

On the other hand, opinions are like assholes.

grabcocque• 11 years ago

This, ladies and gentlemen, is why C gives me the willies. And why this happens:

http://www.cvedetails.com/vulnerability-list/year-2016/month...

pjmlp11• 11 years ago

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.

benbenolson3• 11 years ago

Those are due to programmer error. The fact that C doesn't lie to you means that it takes a bit more experience to program properly; as with all things, with great power comes great responsibility. You don't blame the gun for killing people, you blame the person for shooting it.

legulere2• 11 years ago

Not even the very best C programmers will write memory safe code. When you write C you will write exploitable code, no matter who you are. Don't blame the programmer for stepping onto a mine in the minefield, blame the minefield.

whyever3• 11 years ago

Those are due to programmer error.

How does that help? Almost all security vulnerabilities are due to programmer error.

You don't blame the gun for killing people, you blame the person for shooting it.

It's more like choosing between a gun that makes it really easy to shoot yourself in the foot by accident and one that is safer.

legulere2• 11 years ago

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.

omginternets• 11 years ago

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?

TazeTSchnitzel3• 11 years ago

A byte is the smallest addressable unit. An octet is a unit of 8 bits, which is a common size for a byte.

caf• 11 years ago

A byte is the smallest individually-addressable unit.

EliRivers8• 11 years ago

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

sipior2• 11 years ago

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.

ue_2• 11 years ago

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?

methyl• 11 years ago

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

pcwalton2• 11 years ago

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

lultimouomo5• 11 years ago

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.

whyever3• 11 years ago

I would be very surprised if some non-trivial C code written for x86 compiles and runs unmodified on exotic platforms. Besides, I don't want to be hold back by people wishing to run code on historical or experimental systems.

XorNot2• 11 years ago

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

JoachimSchipper2• 11 years ago

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

kabdib• 11 years ago

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

nabla93• 11 years ago

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.

pjmlp11• 11 years ago

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.

hamiltonkibbe5• 11 years ago

Every TI DSP I've worked with uses 16-bit bytes

mfukar• 11 years ago

Bytes and octets are the same today.

Not in DSPs. Today.

notalaser2• 11 years ago

Hi, I'm working on one. It's a recent DSP with pretty massive processing power that's powering some really, really expensive machines (six figures a piece). A byte is 32 bits here. This is common on a lot of VLIW machines.

I guess uint8_t et co. appeared out of the plight of many systems programmer who needed to do things like "hand these precisely 8 bits to this peripheral". On this machine, getting only these specific 8 bits out of a char requires bit twiddling trickery (it doesn't support unaligned memory access), but if the peripheral you're talking to (e.g. a temperature sensor) calls 8 bits a byte, you're going to have to send it 8 bits, not teach it that a byte doesn't always mean 8 bits.

Prior to stdint.h (and on any platform without a C99-enable compiler, which are neither few nor unused), we used to work around this crap with a bunch of custom macros defined in hardware-specific header files. It was a mess and you needed to learn a lot more about every specific platform's compiler than you ever cared about. And it was particularly beautiful on bi-endian platforms, oh yes, those were so beautiful.

C99 came and said you know what, this is so platform-and-compiler-specific that the compiler should worry about it and that accounted for a massive relief of about 20% of my daily stress dose.

You should use it when you know that you need something to be exactly 8 bits long. Which may or may not be a byte (that's why it frickin' says int8_t and uint8_t, not byte and ubyte).

Edit: I'm going to piggyback on my comment and gently ask anyone to consider not blindly following the advice to inline the declaration of b in code like this:

    void test(uint8_t input) {
        uint32_t b;

        if (input > 3) {
            return;
        }

        b = input;
    }

In many (most?) cases, that's good advice, but declaring it (and any other local variables) in the beginning has the major advantage of allowing me to read the first line of the functions and tell how much space is being allocated on the stack when the function is called.

This is not only nice to know for performance reasons, it's also useful information for platforms that have limited stack size or -- my favourite! -- platforms that lack a MMU, so when your stack runs into useful data, your system doesn't crash, it just starts acting funny.

rkangel• 11 years ago

The XAP processor architecture use in CSR Bluetooth Chips (design orginally from Cambridge Consultants) is one such processor.

On it: A 'byte' is 16 bits. A word is 16 bits (so sizeof(int) == 1) A function ptr is 24 bits (so sizeof(Fx) == 2)

CSR have sold well over a billions chips. There is a strong argument that this is the 3rd most popular architecture family after ARM and X86/64.

Things that x86 programmers do that won't work because they make assumptions the C standard doesn't specify: Cast a uint16_t* to uint8_t* to extract the upper and lower octets of the uint16 (a uint8_t array is actually in memory a uint16_t array using only the lower 8 bits) Store a function pointer in a void* (throws away upper 8 bits of the 24 bit func pointer).

Roboprog4• 11 years ago

Would you port x86 code, like say the Apache web server, to this chip? Or is it basically a memory constrained little device that you are writing a driver for, from scratch?

Seems like you would learn the rules, even though they are a bit odd, easily enough while writing something from scratch, or maintaining an existing (somewhat) small driver program.

Agreed, though, be aware (or just beware?) that this chip is quite different, and new skills MUST be learned.

rplnt• 11 years ago

What's up with creating "empty" repositories for articles? Isn't there a better solution? I think using gist would be more suitable if you want the article to be attached to your github username...

stupidcar3• 11 years ago

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?

EliRivers8• 11 years ago

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.

pjmlp11• 11 years ago

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.

stupidcar3• 11 years ago

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.

lucian1900• 11 years ago

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

Avshalom2• 11 years ago

Those compilers exist because of path dependency from unix not from any unique qualities of C

ketzu• 11 years ago

I think what the discussion about this statement misses is the "unless you need to" part. There are cases where you should use C! It is not "never ever use C".

If the use-case is being able to run on everything from TigerSHARC to x64, you probably should use C. If you want a GUI based Windows App or a webapplication, that might not be a "you need to use C" case.

krylon2• 11 years ago

The key phrase here is "if you can avoid it".

When your target platform is an 8-bit microcontroller or an embedded system with hard real-time requirements, your options are very limited.

But there are plenty of situations where there are alternatives, and often these allow you to solve your problem in less time, with much lower risk of bugs than in C. As always in life, one has to evaluate one's options, consider their respective advantages and weaknesses and then make a choice.

If I had to write a document like that, I would use a different phrasing from "if you can avoid it". But the sentiment - to avoid using C where superior alternatives exist[1] - is something I agree with.

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.

That is kind of like saying the solution to traffic accidents is only letting people drive that don't cause accidents or demand of people that they drive sufficiently carefully. Sure, that is something worth wishing for - but it is not very realistic to expect this to actually happen.

Not that I disagree that C is a very demanding language. Even the best programmers make mistakes. But this is the reason the author of the original document the linked article refers to advised people to avoid C where possible. Most programmers will be better off for most of their projects with a language like Go, or Python or whatever.

[1] Of course, if by "alternatives" I mean languages like Perl, Python or Ruby, it is worth keeping in mind that their main implementations are written in C.

dietrichepp10• 11 years ago

This comment only fans the flames of language war, it doesn't contribute to the discussion.

logicallee3• 11 years ago

This is simply not true. The barrier to a NEW person starting to write C code in 2016 - imagine some 20 year old college student - is "Am I ready to pick a denomination and religion and read hundreds to thousands of pages of gospel?" There is no such barrier with any other language.

You literally cannot give any examples of correct C code as a solution to a problem: literally, experts will disagree with you.

I've had experts tell me that cplusplus.com/reference gives horrific examples you should never follow. The newest addition of The C++ Programming Language says that the examples are not meant to be production code you can actually use as-is. (I can dig this up later if you want.)

C and C++ are more debates in the form of a language than languages per se.

golergka• 11 years ago

What? This comment is directly related to whether advice "don't use C if you can avoid it" is good or not.

hamiltonkibbe5• 11 years ago

You voluntarily code in C for the same reason that your OS kernel's 'yield' is written in assembly. How do you push the addressing mode register to the stack when switching to another task in your high level language of choice?

Roboprog4• 11 years ago

I like how the old Borland Turbo Pascal had little extensions to let you move data between program variables and registers, as well as put in little bits of assembler.

Of course, that only worked on x86 on MS-DOS :-(

kbart3• 11 years ago

"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 we have no alternatives so far. I do C programming for a living, but I'd be more than happy if there were some type and memory safe language I could use to program any tiny, obscure MCU, that could stay at least in the same order of magnitude of speed and let access hardware easily. Rust might be a step in a right direction, but it still has a looong way to go to become a viable alternative to C in embedded world. Of course, for a modern, high level development (web, mobile etc.), I see no reason to use C (maybe except for tiny libraries or co-routines where speed is critical). C is simply a tool -- it's neither good, nor bad -- and as every tool, it has it's use. You can easily break your fingers with a hammer, but that doesn't mean that it's a bad tool for driving nails in.

oldmanjay2• 11 years ago

You're aware that "we have no choice" does not answer a question about why you would do something voluntarily, right?

briansmith• 11 years ago

What do you think Rust needs to do to become viable in the embedded world?

Mayzie• 11 years ago

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?

masklinn2• 11 years ago

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

Anilm33• 11 years ago

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.

xcgvgh6• 11 years ago

Using calloc instead of malloc, just for checking arithmetic overflow, is superfluous. You can always write a check or a wrapper for malloc that does that automatically. It is so easy I can write it here:

  _Bool Check( const size_t a , const size_t b )
  {
    if( a > SIZE_MAX / b )
    {
       return false;
    }
    return true;  
  }

(If proper warnings are enabled, it also provides extra integer type checking.)

Anilm33• 11 years ago

Agreed, but there's little point in reinventing the wheel in this particular case.

xcgvgh6• 11 years ago

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?

chrisseaton• 11 years ago

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.

viraptor• 11 years ago

But if sizeof returns size_t, then your can't have indexes larger than that. Otherwise you could point beyond the largest in-memory object possible. (Using smallest (byte) indexing)

But yes, he may be arguing the definition rather than meaning.

dietrichepp10• 11 years ago

The counterargument is actually relatively simple, because it's an argument over what the definition of size_t is, and you can simply go look to the C standard and find the definition there.

xcgvgh6• 11 years ago

I understand.

If I change the argument to: size_t is capable of holding the largest array index", then this must be correct, or is there still something I missed?

cesarb2• 11 years ago

Converting to uintprt_t will give you some result -- but that result won't be useful. Unless you're writing low-level system code, don't do any pointer comparison or arithmetic unless both pointers point into or just past the end of the same object.

I disagree. There are situations where you need an ordering between unrelated objects, but the precise order doesn't matter, only that it's consistent.

An example is when you have a complex data structure with one lock per node, and you need to lock more than one node at a time for some algorithm.

To prevent a deadlock, you must always take the locks in the same order. Comparing the address of the locks gives you a total order over all the locks, which is enough.

zodiac• 11 years ago

I think comparing (using <) pointers to unrelated objects is undefined behavior. So you do not get a consistent ordering.

cesarb2• 11 years ago

The part I quoted is talking about casting the pointers to uintptr_t (which is defined behavior) and comparing the resulting uintptr_t (since it's an integer, comparing it is defined behavior). It's not talking about comparing the pointers directly (which is undefined behavior). His argument is that, while defined behavior, "(uintptr_t)ptr_a < (uintptr_t)ptr_b" is useless; I disagree, since it's a well-known trick to prevent AB/BA type deadlocks.

coldtea• 11 years ago

I find myself to disagreement with almost ALL the points this "critique" makes.

They are either minor pedantic corrections, "it's how it's always been done" things, or "you might have your reasons for doing it in a bizarro way" affairs.

Sorry, but for 90% of use cases, the original article has better advice.

Manishearth• 11 years ago

Agreed. Most of the integer stuff is pedantry ("doesn't make it non-standard" -- who cares, the point being made was that these types are better). There are some valid and useful points being made, but most would serve better as caveats on the original article rather than straight out "don't listen to this".

lmm7• 11 years ago

int in particular is going to be the most "natural" integer type for the current platform. If you want signed integers that are reasonably fast and are at least 16 bits, there's nothing wrong with using int

The slight performance gain on a few systems that you get from using int rather than int16_t is very rarely worth the hugely increased risk of introducing platform-specific undefined behaviour, IMO.

float and double are very commonly IEEE 32-bit and 64-bit floating-point types, particularly on modern systems, but there's no guarantee of that in the language.

True. Is there an alternative? Something like float32_t?

But more often all you need is a particular range of values. For that, you can use either the [u]int_leastN_t or [u]int_leastN_t types, or one of the predefined types.

Sure - but again, how much performance do you gain from using a _leastN type, and how much reliability do you lose?

It's capable of holding the size of the largest object your implementation supports. (There's an argument that that's not necessarily guaranteed, but for practical purposes you can rely on it.) It can hold the largest memory offset if all offsets are within a single object.

But you just said in the previous section that it only makes sense to perform pointer arithmetic within a single object anyway.

There is a widespread convention, particularly in Unix-like systems, for functions to return 0 for success and some non-zero value (often -1) for failure. In many cases different non-zero results denote different kinds of failure. It's important to follow this convention when adding new functions to such an interface. (0 is used for success because typicallyi there's only one way for a function to succeed, and multiple ways for it to fail.)

The convention is not as widely accepted as this section implies. When adding to an existing system one should follow that system's conventions. When writing for Unix one should follow the Unix conventions. But there are other conventions (e.g. the VMS one) that also see use in C.

I don't often use automatic formatting tools myself. Perhaps I should.

Yes, you should.

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.

Disagree strongly. Consistently incorrect behaviour is much easier to track down than inconsistently incorrect behaviour.

if you're trying to program defensively, you might consider initializing allocated memory to some value that's known to be invalid rather than one that might be valid.

Agreed - but how? One of the biggest problems with C is that it is extremely hard to mark a state as invalid (hence the whole integers for error codes discussion earlier, where really an error code should have a different type from a valid integer result).

snakeanus4• 11 years ago

The slight performance gain on a few systems that you get from using int rather than int16_t

int16_t is also unportable as he mentions later

the hugely increased risk of introducing platform-specific undefined behaviour

What risk? Please explain how int introduces undefined behaviour.

how much performance

It's not about performance. intN_t is NOT guaranteed to exist.

But you just said in the previous section that it only makes sense to perform pointer arithmetic within a single object anyway.

Yes and that's right.

lmm7• 11 years ago

int16_t is also unportable as he mentions later

It's theoretically unportable. I have yet to see a real system to which it's unportable.

What risk? Please explain how int introduces undefined behaviour.

(Signed) integer overflow is undefined behaviour. It is very common to develop on platforms on which int is 32 or 64-bits. This carries a high risk of accidentally overflowing the limits of a 16-bit integer and not realizing. When you do this you don't notice anything (because it doesn't show up on your development machines), but you've introduced undefined behaviour that can easily manifest in practice on machines with 16-bit int.

cataphract2• 11 years ago

Isn't another problem of "ptrdiff_t diff = (uintptr_t)ptrOld - (uintptr_t)ptrNew;" that you're assigning an unsigned value to a signed variable?

If ptrNew is larger than ptrOld this can give a very large value via wrapping around, so large that it will probably be bigger than the max value of ptrdiff_t, making the assignment a form of signed overflow.

xcgvgh6• 11 years ago

The assignment is a conversion from unsigned to signed, if the value cannot be represented by the signed type, the result is implementation defined or an implementation defined signal is triggered.

cataphract2• 11 years ago

Right. Implementation defined, not undefined. Still not great for portable code, which is what the article is all about.

appleflaxen3• 11 years ago

The first rule of C is don't write C if you can avoid it.

My C skills are non-existent, but it occurs to me while reading the response that when two people who have so carefully considered the subject can arrive at such different places... then yes, you probably shouldn't write C if you can avoid it.

benbenolson3• 11 years ago

C is the only language that will run on certain strange systems, and that is the only reason that most of these quibbles even matter. It's more of an argument of "What is the most portable way to write C?"

C is a very small and elegant language that never lies to you. There aren't any useless functions that are specific to one use case, and things that you don't really, really need are simply left out of the language. This means that instead of spending hours learning the language and all of its quirks, you get to focus on the problem that you're trying to solve, and come up with the most efficient solution possible (there's a reason why almost all performance tests use C as 1). You don't have any language quirks like those that are discussed in this article, unless you are running an architecture that has similar quirks, in which case you're going to have quirks no matter what you do. Edge use cases, as with everything, may cause a bit of quirkiness.

That being said, don't be scared off from C just because of these pedantic arguments.

appleflaxen3• 11 years ago

That's a great point; thanks for the context.

pjmlp11• 11 years ago

C is a very small and elegant language that never lies to you.

I would call undefined behavior and compiler optimizations lies.

GregBuchholz2• 11 years ago

C is a very small and elegant language that never lies to you.

I've liked:

http://www.gowrikumar.com/c/index.php

..and...

https://www.google.com/search?q=expert+c+programming+deep+c+...

fithisux2• 11 years ago

The discussion usually boils down to

a. We need a better C

b. We need better programmers.

Personally I believe C tries to hard to be high level instead of what it really is. Newer revisions should try to make it lower level. For example I never could understand why we need enums. Enums are very useful for Java or Golang which are high-level. C never needs enums. Why should I ever put const in the argument of a function? It makes sense for D but for C no. Why should I ever use complex in C. Is there any HW that supports complex numbers? If it becomes standardized, then why not?

C should be good to write kernels and simple utilities and simple compilers. For the rest, use a high-level language.

pjmlp11• 11 years ago

The thing is, such higher level systems programming languages were already a thing in the 60's.

C designers just wanted to hack something for their toy OS and here we are.

woodman2• 11 years ago

For example I never could understand why we need enums.
Why should I ever put const in the argument of a function?

Reducing potential state and conveying programmer intent. Both lead to safer and more performant code (by way of compiler optimizations).

fithisux2• 11 years ago

What you say is incompatible with the "Cross-platform assemble", simple language ideals.

If that was the intent why not throw namespaces and other goodies in?

oldmanjay2• 11 years ago

Reading this as someone who neither loves not loathes C, I would not have written this as a series of rebuttals. It makes the essay seem defensive and nit picky. I get more of a sense of emotional attachment to a particular way than any sort of reasoning.

A critique of "How to C in 2016"

Related Stories