12 ms·

Proposal for a Friendly Dialect of C

218 points by 0x09 12y ago

allegory 12y ago
It is friendly, if you're not an idiot. Not becoming an idiot is the best solution (practice, lots). Edit: perhaps I made my point badly but don't assume that you'll ever be good enough to not be an idiot. Try to converge on it if possible through. I'm still an idiot with C and I've been doing it since 1997.
- automatthew 12y ago
  There's a reason that the safety razor became more popular than the straight razor.
- mikeash 12y ago
  How long does it take? I'm at about 20 years and still haven't made it.
  - allegory 12y ago
    Well I see it more like it takes e^-x years i.e. it never converges on total non-idiocy but you can get pretty close. (been doing it for 17 years)
    - pascal_cuoq 12y ago
      For nearly all of the last 10 years, I have been working on the specific topic of how to better predict what a C program can do (and in particular, correctly predict that a C program will behave well). This is a shorter time than 17 years, but it is more focused than using C as a tool for actually achieving something else, where you aren't thinking about the specifics of C most of the time, hopefully. Despite this, a fortnight ago I was caught off-guard by GCC 4.9's choice of compiling the program in http://pastebin.com/raw.php?i=fRbGfQ6p http://pastebin.com/raw.php?i=fRbGfQ6p to an executable that displays “p is non-null” followed by “p:(nil)”. There has to be a way out of this. Seriously. Most C programmers neither asked for nor deserve this.
      - DSMan195276 12y ago
        If you don't mind me taking a guess, is it because calling memcpy with NULL is undefined-behavior, thus GCC assumes p must be non-null and thus the if (p) is redundant and x must equal 1?
        pascal_cuoq 12y ago
        Exactly. Propagating the information that p was passed as argument to memcpy and thus must be non-null is a new GCC 4.9 optimization (some discussion here: http://stackoverflow.com/questions/5243012/is-it-guaranteed-to-be-safe-to-perform-memcpy0-0-0 http://stackoverflow.com/questions/5243012/is-it-guaranteed-... ).
- kyllo 12y ago
  The problem is, by that metric, everyone is an "idiot." There isn't a C programmer alive who hasn't been bitten by most, if not all, of these types of memory bugs.
- GFK_of_xmaspast 12y ago
  Some of those suggestions are pretty good, actually. I particularly like 7, 12, and 14.
- rcthompson 12y ago
  If I knew someone who didn't become friendly to me for the first 25 years of our relationship, I wouldn't call them friendly.
- Strilanc 12y ago
  > Not becoming an idiot is the best solution [...] [...] but don't assume that you'll ever be good enough to not be an idiot. Try to converge on it if possible through. I'm still an idiot with C and I've been doing it since 1997 We have wildly differing definitions of "best solution". I like solutions to be actually achievable, for example.
- lisper 12y ago
  > Not becoming an idiot is the best solution "Best" by what quality metric? "Not becoming an idiot" is difficult and time-consuming. Furthermore, there's no reliable way to determine if you have in fact succeeded in ceasing to be an idiot because part of the license that compilers have when encountering undefined behavior is to mask it. So even if your code compiles without warnings and passes all tests that is no guarantee that you have ceased to be an idiot. So requiring a compiler to do something more reasonable in the face of undefined behavior than reformat your hard drive (or at least to make it an option) is not an unreasonable position.
otikik 12y ago
I haven't done C in at least a decade, so bare with me. > 1. The value of a pointer to an object whose lifetime has ended remains the same as it was when the object was alive > 8. A read from uninitialized storage returns an unspecified value. Isn't that already the case in C? > 3. Shift by negative or shift-past-bitwidth produces an unspecified result. What is the meaning of "an unspecified result" there? > 4. Reading from an invalid pointer either traps or produces an unspecified value. What is the meaning of "traps" here? Is it the same as later on ("math- and memory-related traps")?
- peff 12y ago
  No, those are things that _usually_ happen in most C implementations. But reading from uninitialized memory provokes "undefined behavior" according to the standard. Which might mean returning an unspecified value, might mean whole chunks of code being skipped, or might mean demons flying out of your nose. The first one seems like an obvious choice of behavior, and one that some C programs doubtless depend on. But when you throw advanced optimizations into the mix, compilers may do unexpected things (e.g., assuming that a certain thing can't happen because it's not allowed by the standard, and then manipulating the code under that assumption). If you read other articles from Regehr, he describes some examples.
  - angersock 12y ago
    The linked flamewar on the GCC issue tracker ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475#c36 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475#c36 ) is an excellent example of this: citing "undefined behavior", compiler writers will gleefully do all kinds of goofy shit and, if confronted by developers who actually program for a living, stick their fingers in their ears and go "nyah nyah nyah undefined behavior we can do whatever we want go learn c nyah nyah nyah". "Undefined behavior" is a really great trick for promoting pet optimization projects and stonewalling practical feature requests by use of language lawyering.
    - DSMan195276 12y ago
      How was it goofy? Personally what the compiler did made perfect sense to me. If you assume integers can't overflow, then 'b' must be larger then 'a'. Thus why would the compiler bother performing the statement 'c=(b>a)' when it's 'obvious' that it's just going to be 'c=1'? That said, looking at that page the guy who made this bug was being more then extremely annoying, the person responding to the bug was fairly civil all things considered. You're complaining about UD but it's a necessary evil in C. Integer overflow was perhaps a bad choice by the standards makers, but the fact still stands that even if GCC did the 'right' thing, there's no guarantee that clang or any other compiler will do the same thing. The code would still be broken, it just might be harder to figure that out. If you want integer overflow and wrapping then use the compiler flag for it and write non-standard code. IMO, the bigger problem is that people write their code, compile it with gcc, and then assume it's standards compliant because it 'works' with gcc.
DSMan195276 12y ago
The kernel uses -fno-strict-aliasing because they can't do everything they need to do by adhering strictly to the standard, it has nothing to do with it being to hard (The biggest probably being treating pointers as integers and masking them, which is basically illegal to do with C). IMO, this idea would make sense if it was targeted at regular software development in C (And making it easier to not shoot yourself in the foot). It's not as useful to the OS/hardware people though because they're already not writing standards-compliant code nor using the standard library. There's only so much it can really do in that case without making writing OS or hardware code more annoying to do then it already is.
cousin_it 12y ago
Sometime ago I came up with a simpler proposal: emit a warning if UB exploitation makes a line of code unreachable. That refers to actual lines in the source, not lines after macroexpansion and inlining. Most "gotcha" examples with UB that I've seen so far contain unreachable lines in the source, while most legitimate examples of UB-based optimization contain unreachable lines only after macroexpansion and inlining. Such a warning would be useful in any case, because in legitimate cases it would tell the programmer that some lines can be safely deleted, which is always good to know.
- regehr 12y ago
  The linked articles by Chris Lattner explain why this is very difficult. http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
  - cousin_it 12y ago
    Is it true that undesirable UB exploitation often happens after macroexpansion and inlining, and doesn't make any actual source lines unreachable? Are there any simple examples of that?
    - regehr 12y ago
      Does this example help? http://markshroyer.com/2012/06/c-both-true-and-false/ http://markshroyer.com/2012/06/c-both-true-and-false/
      - cousin_it 12y ago
        Yeah. Thanks!
twoodfin 12y ago
Can someone give a rationalization of why a "friendly" dialect of C should return unspecified values from reading uninitialized storage? Is the idea that all implementations will choose "0" for that unspecified value and allow programmers to be lazy? I'd much rather my "friendly" implementation immediately trap. Code built in Visual C++'s debug mode is pretty reliable (and useful) in this regard. EDIT: It occurs to me that this is probably a performance issue. Without pretty amazing (non-computable in the general case?) static analysis, it would be impossible to tell whether code initializes storage in all possible executions, and using VM tricks to detect all uninitialized access at runtime is likely prohibitively expensive for non-debug code.
- Scaevolus 12y ago
  The change affects compiler optimization. The proposal changes many results from "undefined behavior" (compiler can do anything, including throwing away code before the statement executes) to "unspecified value", which means the statement might result in unknown values, but it can't remove the code. Read the linked articles in the post for a better treatment of what undefined behavior means and how compilers deal with it.
- zellyn 12y ago
  The scope of an unspecified value's effect is limited to that particular value, whereas undefined behavior's effects are unlimited: http://en.wikipedia.org/wiki/Nasal_demons http://en.wikipedia.org/wiki/Nasal_demons
  - kazinator 12y ago
    However, in practice, continuing with an unspecified value can have catastrophic consequences. And, also, undefined behavior can have nice consequences, like terminating with a diagnostic message, which is not a conforming way to implement unspecified behavior.
- PeterisP 12y ago
  Because the current behavior of some compiler optimizations is that instead of returning unspecified values, it can assume that the code is unreachable (undefined behavior) and simply eliminate a bunch of normal, correct code that precedes reading unitialized storage. Guaranteed immediate trapping might be difficult on some platforms, but a specification that allows to return an unspecified value or trap immediately - that can be done anywhere.
revelation 12y ago
Plenty of architectures do not trap at null-pointer dereferencing (they don't have traps). Some (like AVR) are not arcane, they are one of the best excuses for still writing C nowadays.
- zokier 12y ago
  Just because a improvement is not applicable to all situations does not mean that is should not be pursued.
- wglb 12y ago
  Arcane in the context of the blog post might mean non-86* and non-ARM. AVR developed by Atmel in 1996, you might agree, is less-well known than the above.
simias 12y ago
I can fit the proposed changes in two categories: * Changes that replace undefined behaviours with undefined values. This makes it easier to catch certain types of coding errors at the cost of certain kinds of optimizations. * Changes that remove undefined behaviours (wrapping arithmetic, memcpy/memmove, aliasing rules). I'm comfortable with the first kind, although you can already achieve something very similar to that with most compiler (as far as I know) by building with optimizations disabled. Also stuff like missing return values generates a warning in any compiler worth using, if you ignore that kind of warnings you can only blame yourself. The 2nd kind bothers me more, because it makes otherwise invalid C code valid in this dialect. I'm worried this makes things even more difficult to explain to beginners (and not so beginners, I still have to check the aliasing rules from time to time to make sure the code I'm writing is valid). Even if you're very optimistic this friendly C is not going to replace daddy anytime soon. There'll be plenty of C code out there, plenty of C toolchains, plenty of C environment where the definition of friendliness is having a dump of the registers and stack on the UART in case of an error. Plenty of environments where memcpy is actually memcpy, not memmove. For that reason I'd be much more in favour of advocating the use of more modern alternatives to C (and there are a bunch of those) rather than risking blurring the lines some more about what is and isn't undefined behaviour in C.
- pascal_cuoq 12y ago
  > There'll be plenty of C code out there Precisely. The idea here is that any C program that does not specifically require one's complement or sign-magnitude representation will work just as well compiled as friendly C as it does compiled as C. Also, just because testing has found no exploitable bugs in a C program compiled with GCC 4.8 does not mean that GCC 4.9 will not introduce a new optimization that wreaks havoc with undefined behavior that was there all along. No such surprises with friendly C. It's the trusty C compiler that you had in 1995, and it always will be. Security-critical programs would never rely on undefined behavior!, you might say. Let us take the example of ntpd, one of the building blocks of the Internet, considered critical enough to be part of two Google bounty programs. Here is a list of currently harmless undefined behaviors in it that a compiler could use as an excuse to produce vulnerable binary code tomorrow: http://bugs.ntp.org/buglist.cgi?emailreporter1=1&emailtype1=substring&email1=trust-in-soft http://bugs.ntp.org/buglist.cgi?emailreporter1=1&emailtype1=... Friendly C is not a new language. It is C as most developers understand it, and with bad surprises prohibited as much as possible. Disclaimer: Julien, who reported these ntpd undefined behaviors, is my colleague, and I am a co-author of the “friendly C” proposal.
rwmj 12y ago
I would think also something like "if I write a piece of code, the compiler should compile it", perhaps "or else tell me with a warning that it isn't going to compile it".
userbinator 12y ago
I really like these suggestions since they can be summed up in one sentence: they are what C programmers who write code with UB would already expect any reasonably sane platform would do. I think it's definitely a very positive change in attitude from the "undefined behaviour, therefore anything can happen" that resulted in compilers' optimisations becoming very surprising and unpredictable. Rather, we are trying rescue the predictable little language that we all know is hiding within the C standard. Well said. I think the practice of UB-exploiting optimisation was completely against the spirit of the language, and that the majority of optimisation benefits happen in the compiler backend (instruction selection, register allocation, etc.) At least as an Asm programmer, I can attest that IS/RA can make a huge difference in speed/size. The other nice point about this friendly C dialect is that it still allows for much optimisation, but with a significant difference: instead of basing it on assumptions of UB defined by the standard, it can still be done based on proof; e.g. code that can be proved to be unneeded can be eliminated, instead of code that may invoke UB. I think this sort of optimisation is what most C programmers intuitively agree with.
- _delirium 12y ago
  instead of basing it on assumptions of UB defined by the standard, it can still be done based on proof; e.g. code that can be proved to be unneeded can be eliminated, instead of code that may invoke UB. I think this sort of optimisation is what most C programmers intuitively agree with. The main motivation for relying on some of the UB assumptions is that compilers weren't able to prove things in a lot of cases where programmers expected them to, because C (especially in the face of arbitrary pointers, and esp. with incremental compilation) is quite hard to prove things about. So compilers started inferring things about variables from what programmers do with them. For example, if a pointer is used in a memcpy(), then the programmer is signalling to us that they know this is a non-null pointer, since you can't pass NULL as an address to memcpy(). So when compiled with non-debugging, high-optimization flags, the compiler trusts the programmer, and assumes this is a known-to-be-non-null pointer. It would be interesting to see some benchmarks digging into whether turning off that kind of inference has significant performance impact on real-world code. Without adding more source-level annotations to C (like being able to flag pointers as non-NULL), it will reduce some optimization opportunities, since the compiler won't be able to infer as many things, even things that are definitely true. But it might not be enough cases to matter.
Someone 12y ago
"Reading from an invalid pointer either traps or produces an unspecified value." That still leaves room for obscure behavior: if( p[i] == 0) { foo();} if( p[i] != 0) { bar();} Calling foo might change the memory p points at (p might point into the stack or it might point to memory in which foo() temporarily allocates stuff, or the runtime might choose to run parts of free() asynchronously in a separate thread), so one might see cases where both foo and bar get called. And yes, optimization passes in the compiler might or might not remove this problem. Apart from truly performance-killing runtime checks i do not see a way to fix this issue. That probably is the reason it isn't in the list. (Feel free to replace p[i] by a pointer dereference. I did not do that above because I fear HN might set stuff in italics instead of showing asterisks)
- mseebach 12y ago
  Short of languages like clojure and haskell that are heavily opinionated on immutability and side effects, I can't think of any languages that meaningfully protects against that kind of obscure behaviour. Indeed, it seems "else" was meant for exactly this kind of code.
Ono-Sendai 12y ago
Not sure this is a good idea. Since a lot of behaviour becomes implementation-defined, code written in this dialect will not be portable.
- andrewchambers 12y ago
  It already is implementation defined by accident.
sjolsen 12y ago
I don't really see what's to be accomplished by most of the points of this. A program that invokes undefined behaviour isn't just invalid; it's almost certainly _wrong_. Shifting common mistakes from undefined behaviour to unspecified behaviour just makes such programs less likely to blow up spectacularly. That doesn't make them correct; it makes it harder to notice that they're incorrect. Granted, not everything listed stops at unspecified behaviour. I'm not convinced that that's a good thing, though. Even something like giving signed integer overflow unsigned semantics is pretty effectively useless. Sure, you can reasonably rely on twos-complement representation, but that doesn't change the fact that you can't represent the number six billion in a thirty-two bit integer, and it doesn't make 32-bit code that happens to depend on the arithmetic properties of the number six billion correct just because the result of multiplying two billion by three is well-defined. Then there's portability. Strict aliasing is a good example of this. Sure, you can access an "int" aligned however you like on x86. It'll be slow, but it'll work. On MIPS, though? Well, the compiler could generate code to automate the scatter-gather process of accessing unaligned memory locations. This is C, though. It's supposed to be close to the metal; it's supposed to force-- I mean, let you do everything yourself, without hiding complexity from the programmer. How far should the language semantics be stretched to compensate for programmers' implicit, flawed mental model of the machine, and at what point do we realize that we already have much better tools for that level of abstraction?
- scott_s 12y ago
  I have a feeling you haven't read through all of the linked posts and papers. The problem they're trying to address is that C compliers take advantage of undefined behavior for optimizations. Such optimizations can cause very strange, unintuitive behavior that is very difficult to discover. The linked posts, papers, and even this thread provide many great examples. You're right that the programs are wrong. The goal of this proposal is to make them wrong in reasonable ways.
  - sjolsen 12y ago
    >The problem they're trying to address is that C compliers take advantage of undefined behavior for optimizations That's not a problem. That's a good thing. >Such optimizations can cause very strange, unintuitive behavior that is very difficult to discover That's a problem -- or at least the "difficult to discover" part is. "Strange" and "unintuitive" is helpful; it's a nice, big red flag. How does migrating from undefined behaviour to producing unspecified values make bugs easier to discover? I can see how they would make results more consistent, and the bugs easier to hunt down, but that's only useful once you know the bugs are there (inconsistency is another useful red flag here), and there are already good tools like valgrind and ubsan for tracking down the source of the bug. >The goal of this proposal is to make them wrong in reasonable ways That isn't the purview of C, though. It's a noble goal, don't get me wrong, but stepping on the optimizer's toes and reinforcing plainly bad programming practices -- I know that's not an intended effect, but it will happen -- isn't the way to do it. A better way, just as an example, would be to give the programmer a proper mechanism for encoding preconditions and other interprocedure-analysable constraints. This doesn't reinforce bad practices, it could actually help the optimizer if done right, and would perhaps encourage programmers to reason a little more rigorously about their code -- an ounce of prevention and all that.
jhallenworld 12y ago
I have strong feelings that the C standard (and, by extension, C compilers) should directly support non-portable code. It means many behaviors are not "undefined"- instead they are "machine dependent". Thus overflow is not undefined- it is _defined_ to depend on the underlying architecture in a specific way. C is a more useful language if you can make machine specific code this way. I'm surprised that some of the pointer math issues come up. Why would the compiler assume that a pointer's value is invalid just because the referenced object is out of scope? That's crazy.. Weird results from uninitialized variables can sometimes be OK. I would kind of accept strange things to happen when an uninitialized bool (which is really an int) is not exactly 1 or 0. Perhaps a better way to deal with the memcpy issue is this: make memcpy() safe (handles 0 size, allows overlapping regions), but create a fast_memcpy() for speed.
- dllthomas 12y ago
  The standard differentiates between "undefined" and "implementation defined".
  - to3m 12y ago
    ...with one option for undefined behaviour being for it to behave "in some documented manner characteristic of the platform" (C11 para 3.4.3.2). Which is not the same thing as being implementation defined, of course, but is at least a step above simply deciding your program is invalid and generating bogus code because of it. So compilers could do this stuff already. I have no idea why they don't. C isn't really the language for people who want platform independence.
    - dllthomas 12y ago
      Well sure. They don't because you can get better performance if you are able to eliminate branches that you can prove aren't taken.
kazinator 12y ago
> 1. The value of a pointer to an object whose lifetime has ended remains the same as it was when the object was alive. This does not help anyone; making this behavior defined is stupid, because it prevents debugging tools from identifying uses of these pointers as early as possible. In practice, existing C compilers do behave like this anyway: though any use of the pointer (not merely dereferencing use) is undefined behavior, in practice, copying the value around does work. > 2. Signed integer overflow results in two’s complement wrapping behavior at the bitwidth of the promoted type. This seems like a reasonable request since only museum machines do not use two's complement. However, by making this programming error defined, you interfere with the abilty to diagnose it. C becomes friendly in the sense that assembly language is friendly: things that are not necessarily correct have a defined behavior. The problem is that then people write code which depends on this. Then when they do want overflow trapping, they will have to deal with reams of false positives. The solution is to have a declarative mechanism in the language whereby you can say "in this block of code, please trap overflows at run time (or even compile time if possible); in this other block, give me two's comp wraparound semantics". > 3. Shift by negative or shift-past-bitwidth produces an unspecified result. This is just word semantics. Undefined behavior, unspecified: it spells nonportable. Unspecified behavior may seem better because it must not fail. But, by the same token, it won't be diagnosed either. A friendly C should remove all gratuitous undefined behaviors, like ambiguous evaluation orders. And diagnose as many of the remaining ones which are possible: especially those which are errors. Not all undefined behaviors are errors. Undefined behavior is required so that implementations can extend the language locally (in a conforming way). One interpretation of ISO C is that calling a nonstandard function is undefined behavior. The standard doesn't describe what happens, no diagnostic is required, and the range of possibilities is very broad. If you put "extern int foo()" into a program and call it, you may get a diagnostic like "unresolved symbol foo". Or a run-time crash (because there is an external foo in the platform, but it's actually a character string!) Or you may get the expected behavior. > 4. Reading from an invalid pointer either traps or produces an unspecified value. In particular, all but the most arcane hardware platforms can produce a trap when dereferencing a null pointer, and the compiler should preserve this behavior. The claim here is false. Firstly, even common platforms like Linux do not actually trap null pointers. They trap accesses to an unmapped page at address zero. That page is often as small as 4096 bytes. So a null dereference like ptr[i] or ptr->memb where the displacement goes beyond the page may not actually be trapped. Reading from invalid pointers already has the de facto behavior of reading an unspecified value or else trapping. The standard makes it formally undefined, though, and this only helps: it allows advanced debugging tools to diagnose invalid pointers. We can run our program under Valgrind, for instance, while the execution model of that program remains conforming to C. We cannot valgrind the program if invalid pointers dereference to an unspecified value, and programs depend on that; we then have reams of false positives and have to deal with generating tedious suppressions. > 5. Division-related overflows either produce an unspecified result or else a machine-specific trap occurs. Same problem again, and this is already the actual behavior: possibilities like "demons fly out of your nose" does not happen in practice. The friendly thing is to diagnose this, always. Carrying on with a garbage result is anything but friendly. > It is permissible to compute out-of-bounds pointer values including performing pointer arithmetic on the null pointer. Arithmetic on null works on numerous compilers already, which use it to implement the offsetof macro. > memcpy() is implemented by memmove(). This is reasonable. The danger in memcpy not supporting overlapped copies is not worth the microoptimization. Any program whose performance is tied to that of memcpy is badly designed anyway. For instance if a TCP stack were to double in performance due to using a faster memcpy, we would strongly suspect that it does too much copying. > The compiler is granted no additional optimization power when it is able to infer that a pointer is invalid. That's not really how it works. The compiler assumes that your pointers are valid and proceeds accordingly. For instance, aliasing rules tell it that an "int *" pointer cannot be aimed at an object of type "double", so when that pointer is used to write a value, objects of type double can be assumed to be unaffected. C compilers do not look for rule violations as an excuse to optimize more deeply, they generally look for opportunities based on the rules having been followed. > When a non-void function returns without returning a value, an unspecified result is returned to the caller. This just brings us back to K&R C before there was an ANSI standard. If functions can fall off the end without returning a value, and this is not undefined, then again, the language implementation is robbed of the power to diagnose it (while remaining conforming). Come on, C++ has fixed this problem, just look at how it's done! For this kind of undefined behavior which is erroneous, it is better to require diagnosis, rather than to sweep it under the carpet by turning it into unspecified behavior. Again, silently carrying on with an unspecified value is not friendly. Even if the behavior is not classified as "undefined", the value is nonportable garbage. It would be better to specify it a zero than leave it unspecified: falling out of a function that returns a pointer causes it to return null, out of a function that returns a number causes it to return 0 or 0.0 in that type, out of a function that returns a struct, a zero-initialized struct, and so on. Predictable and portable results are more friendly than nonportable, unspecified, garbage results.
Verdex 12y ago
I think it's interesting that the famous tech companies are all developing programming languages that are less managed than java/c#, but more predictable (read: less undefined behavior) than c/c++. Facebook seems interested in D, Apple has Swift, Microsoft has some sort of secret project they are working on, Google has Go, and Mozilla has Rust. Even c++ seems to be attempting to modernize with the new additions to it's spec. And now we see a desire for c itself to change. I wonder if our industry is at a turning point where managed languages aren't quite cutting it, but no one is comfortable going back to the 'good old days'. On a personal note, I like the idea of friendly C so much that I finally made an HN account. One of my favorite things to do is to take things apart and understand them. I was mortified when I learned the real meaning of undefined behavior in c/c++. It seems like the only way to be sure you understand a C program is to check the generated machine code. Even worse is that when I try to talk to other developers about undefined behavior, I tend to get the impression that they don't actually understand what undefined behavior means. I can't think of a way to verify what they think it means without insulting their intelligence, but hopefully the existence of something like friendly C will make it an easier discussion to have.
- _pmf_ 12y ago
  > Microsoft has some sort of secret project they are working on Microsoft has a multitude of secret programming language projects, and the nice thing about them is that when they migrate into C#, people actually will use them.
- 72deluxe 12y ago
  I wonder if the managed languages "aren't cutting it" because they're not fashionable and seen as stinky old dinosaurs to the generation of developers growing up now? I mean, some people openly scoff at languages that aren't Python or ECMAScript, and it appears to be very/extremely fashionable/obligatory on HN to aggressively bash C++, even when it appears that many haven't written or maintained anything in it, and casually dismiss it as "complicated" and daft as it has no compulsory garbage collection. "Huh! It allows to you address memory! HOW STUPID. Why would a language even exist anymore that lets you do that?!" When reading some of the concepts behind C++ and the reasons for decisions, some of them make excellent sense. The 'newer' languages are simpler, primarily because they haven't had decades of existence for people to demand the features that people have demanded in C++. Where I work we use C and C++ for most things, but that's just the industry we're in. It appeared to become the norm to teach Java at universities now (from the people I have bumped into), so C++ and C are no longer the starting points for development for most graduates, perhaps?
dschiptsov 12y ago
Show us, please, how the dialect of C which is used for development of the Plan9 is unfriendly and not good-enough.
- astrange 12y ago
  It's been empirically demonstrated that C wasn't good enough for Rob Pike.
  - dschiptsov 12y ago
    Are you in love with Golang too?)
Roboprog 12y ago
Back in 1990, it didn't take long to figure out that (Borland) Turbo Pascal was much less insane than C. Unfortunately, it only ran on MS-DOS & Windows, whereas C was everywhere. Employers demanded C programmers, so I became a C programmer. (now I'm a Java programmer, for the same reason, and think it's also a compromised language in many ways) For anybody who is willing to run a few percent slower so that array bounds get checked, there is now an open source FreePascal environment available, so as not to be dependent on the scraps of Borland that Embarcadero is providing at some cost. Of course, nobody is going to hire you to use Pascal. (or any other freaky language that gets the job at hand done better than the current mainstream Java and C# languages)
- zamalek 12y ago
  Pascal, in general, was an amazing language. Simple to understand, compiled to native code - honestly the only complaint you could now (with FreePascal) make about the language is that it is a little "wordy." Much the same as D - which was my initial thought when I read "friendly C." We already have a friendly C.
  - peapicker 12y ago
    When I first learned C, after having used Turbo Pascal for years (back in the 80s) it was frustrating. When I finally understood it well a little later, I felt like I had taken off the shackles of Pascal...
    - Roboprog 12y ago
      Granted, original, 1970, flavor Pascal on the CDC Cyber was very limited. I'm curious, though, what is it that Turbo Pascal 5.0 and above would prevent you from doing? It's been a while, but if I really have to, I could cast a pointer to a long, increment it by sizeof in a loop, and cast it back to a pointer in Pascal to do pointer arithmetic in a tight loop. I can use procedural types anywhere a function pointer in C would be used. I can make complex constants (tables) just like a pre-initialized array of structs in C. There is an extension to return in the middle of a function/procedure rather than toggling flags to pinball-style drop to the end of the routine. I can set compiler pragmas to allow/force me to check for error codes after every memory and I/O call (at the risk of accidentally stumbling on to cause secondary damage), rather than just failing with a line number. I can nest functions inside of other functions, and reference the enclosing variables, just like in GNU C (oh, wait, that's a non-standard GNU extension), even if I can't return such a function as a "use it later", honest to God closure. What are the shackles? (I'm probably in for a face palm, oh, that, moment when I get the answer, but I'm drawing a blank at the moment)

218 points by 0x09 12y ago

It is friendly, if you're not an idiot. Not becoming an idiot is the best solution (practice, lots). Edit: perhaps I made my point badly but don't assume that you'll ever be good enough to not be an idiot. Try to converge on it if possible through. I'm still an idiot with C and I've been doing it since 1997.

automatthew 12y ago
There's a reason that the safety razor became more popular than the straight razor.
mikeash 12y ago
How long does it take? I'm at about 20 years and still haven't made it.
- allegory 12y ago
  Well I see it more like it takes e^-x years i.e. it never converges on total non-idiocy but you can get pretty close. (been doing it for 17 years)
  - pascal_cuoq 12y ago
    For nearly all of the last 10 years, I have been working on the specific topic of how to better predict what a C program can do (and in particular, correctly predict that a C program will behave well). This is a shorter time than 17 years, but it is more focused than using C as a tool for actually achieving something else, where you aren't thinking about the specifics of C most of the time, hopefully. Despite this, a fortnight ago I was caught off-guard by GCC 4.9's choice of compiling the program in http://pastebin.com/raw.php?i=fRbGfQ6p http://pastebin.com/raw.php?i=fRbGfQ6p to an executable that displays “p is non-null” followed by “p:(nil)”. There has to be a way out of this. Seriously. Most C programmers neither asked for nor deserve this.
    - DSMan195276 12y ago
      If you don't mind me taking a guess, is it because calling memcpy with NULL is undefined-behavior, thus GCC assumes p must be non-null and thus the if (p) is redundant and x must equal 1?
      - pascal_cuoq 12y ago
        Exactly. Propagating the information that p was passed as argument to memcpy and thus must be non-null is a new GCC 4.9 optimization (some discussion here: http://stackoverflow.com/questions/5243012/is-it-guaranteed-to-be-safe-to-perform-memcpy0-0-0 http://stackoverflow.com/questions/5243012/is-it-guaranteed-... ).
kyllo 12y ago
The problem is, by that metric, everyone is an "idiot." There isn't a C programmer alive who hasn't been bitten by most, if not all, of these types of memory bugs.
GFK_of_xmaspast 12y ago
Some of those suggestions are pretty good, actually. I particularly like 7, 12, and 14.
rcthompson 12y ago
If I knew someone who didn't become friendly to me for the first 25 years of our relationship, I wouldn't call them friendly.
Strilanc 12y ago
> Not becoming an idiot is the best solution [...] [...] but don't assume that you'll ever be good enough to not be an idiot. Try to converge on it if possible through. I'm still an idiot with C and I've been doing it since 1997 We have wildly differing definitions of "best solution". I like solutions to be actually achievable, for example.
lisper 12y ago
> Not becoming an idiot is the best solution "Best" by what quality metric? "Not becoming an idiot" is difficult and time-consuming. Furthermore, there's no reliable way to determine if you have in fact succeeded in ceasing to be an idiot because part of the license that compilers have when encountering undefined behavior is to mask it. So even if your code compiles without warnings and passes all tests that is no guarantee that you have ceased to be an idiot. So requiring a compiler to do something more reasonable in the face of undefined behavior than reformat your hard drive (or at least to make it an option) is not an unreasonable position.

otikik 12y ago

I haven't done C in at least a decade, so bare with me. > 1. The value of a pointer to an object whose lifetime has ended remains the same as it was when the object was alive > 8. A read from uninitialized storage returns an unspecified value. Isn't that already the case in C? > 3. Shift by negative or shift-past-bitwidth produces an unspecified result. What is the meaning of "an unspecified result" there? > 4. Reading from an invalid pointer either traps or produces an unspecified value. What is the meaning of "traps" here? Is it the same as later on ("math- and memory-related traps")?

peff 12y ago
No, those are things that _usually_ happen in most C implementations. But reading from uninitialized memory provokes "undefined behavior" according to the standard. Which might mean returning an unspecified value, might mean whole chunks of code being skipped, or might mean demons flying out of your nose. The first one seems like an obvious choice of behavior, and one that some C programs doubtless depend on. But when you throw advanced optimizations into the mix, compilers may do unexpected things (e.g., assuming that a certain thing can't happen because it's not allowed by the standard, and then manipulating the code under that assumption). If you read other articles from Regehr, he describes some examples.
- angersock 12y ago
  The linked flamewar on the GCC issue tracker ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475#c36 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475#c36 ) is an excellent example of this: citing "undefined behavior", compiler writers will gleefully do all kinds of goofy shit and, if confronted by developers who actually program for a living, stick their fingers in their ears and go "nyah nyah nyah undefined behavior we can do whatever we want go learn c nyah nyah nyah". "Undefined behavior" is a really great trick for promoting pet optimization projects and stonewalling practical feature requests by use of language lawyering.
  - DSMan195276 12y ago
    How was it goofy? Personally what the compiler did made perfect sense to me. If you assume integers can't overflow, then 'b' must be larger then 'a'. Thus why would the compiler bother performing the statement 'c=(b>a)' when it's 'obvious' that it's just going to be 'c=1'? That said, looking at that page the guy who made this bug was being more then extremely annoying, the person responding to the bug was fairly civil all things considered. You're complaining about UD but it's a necessary evil in C. Integer overflow was perhaps a bad choice by the standards makers, but the fact still stands that even if GCC did the 'right' thing, there's no guarantee that clang or any other compiler will do the same thing. The code would still be broken, it just might be harder to figure that out. If you want integer overflow and wrapping then use the compiler flag for it and write non-standard code. IMO, the bigger problem is that people write their code, compile it with gcc, and then assume it's standards compliant because it 'works' with gcc.

DSMan195276 12y ago

The kernel uses -fno-strict-aliasing because they can't do everything they need to do by adhering strictly to the standard, it has nothing to do with it being to hard (The biggest probably being treating pointers as integers and masking them, which is basically illegal to do with C). IMO, this idea would make sense if it was targeted at regular software development in C (And making it easier to not shoot yourself in the foot). It's not as useful to the OS/hardware people though because they're already not writing standards-compliant code nor using the standard library. There's only so much it can really do in that case without making writing OS or hardware code more annoying to do then it already is.

cousin_it 12y ago

Sometime ago I came up with a simpler proposal: emit a warning if UB exploitation makes a line of code unreachable. That refers to actual lines in the source, not lines after macroexpansion and inlining. Most "gotcha" examples with UB that I've seen so far contain unreachable lines in the source, while most legitimate examples of UB-based optimization contain unreachable lines only after macroexpansion and inlining. Such a warning would be useful in any case, because in legitimate cases it would tell the programmer that some lines can be safely deleted, which is always good to know.

regehr 12y ago
The linked articles by Chris Lattner explain why this is very difficult. http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
- cousin_it 12y ago
  Is it true that undesirable UB exploitation often happens after macroexpansion and inlining, and doesn't make any actual source lines unreachable? Are there any simple examples of that?
  - regehr 12y ago
    Does this example help? http://markshroyer.com/2012/06/c-both-true-and-false/ http://markshroyer.com/2012/06/c-both-true-and-false/
    - cousin_it 12y ago
      Yeah. Thanks!

twoodfin 12y ago

Can someone give a rationalization of why a "friendly" dialect of C should return unspecified values from reading uninitialized storage? Is the idea that all implementations will choose "0" for that unspecified value and allow programmers to be lazy? I'd much rather my "friendly" implementation immediately trap. Code built in Visual C++'s debug mode is pretty reliable (and useful) in this regard. EDIT: It occurs to me that this is probably a performance issue. Without pretty amazing (non-computable in the general case?) static analysis, it would be impossible to tell whether code initializes storage in all possible executions, and using VM tricks to detect all uninitialized access at runtime is likely prohibitively expensive for non-debug code.

Scaevolus 12y ago
The change affects compiler optimization. The proposal changes many results from "undefined behavior" (compiler can do anything, including throwing away code before the statement executes) to "unspecified value", which means the statement might result in unknown values, but it can't remove the code. Read the linked articles in the post for a better treatment of what undefined behavior means and how compilers deal with it.
zellyn 12y ago
The scope of an unspecified value's effect is limited to that particular value, whereas undefined behavior's effects are unlimited: http://en.wikipedia.org/wiki/Nasal_demons http://en.wikipedia.org/wiki/Nasal_demons
- kazinator 12y ago
  However, in practice, continuing with an unspecified value can have catastrophic consequences. And, also, undefined behavior can have nice consequences, like terminating with a diagnostic message, which is not a conforming way to implement unspecified behavior.
PeterisP 12y ago
Because the current behavior of some compiler optimizations is that instead of returning unspecified values, it can assume that the code is unreachable (undefined behavior) and simply eliminate a bunch of normal, correct code that precedes reading unitialized storage. Guaranteed immediate trapping might be difficult on some platforms, but a specification that allows to return an unspecified value or trap immediately - that can be done anywhere.

revelation 12y ago

Plenty of architectures do not trap at null-pointer dereferencing (they don't have traps). Some (like AVR) are not arcane, they are one of the best excuses for still writing C nowadays.

zokier 12y ago
Just because a improvement is not applicable to all situations does not mean that is should not be pursued.
wglb 12y ago
Arcane in the context of the blog post might mean non-86* and non-ARM. AVR developed by Atmel in 1996, you might agree, is less-well known than the above.

simias 12y ago

I can fit the proposed changes in two categories: * Changes that replace undefined behaviours with undefined values. This makes it easier to catch certain types of coding errors at the cost of certain kinds of optimizations. * Changes that remove undefined behaviours (wrapping arithmetic, memcpy/memmove, aliasing rules). I'm comfortable with the first kind, although you can already achieve something very similar to that with most compiler (as far as I know) by building with optimizations disabled. Also stuff like missing return values generates a warning in any compiler worth using, if you ignore that kind of warnings you can only blame yourself. The 2nd kind bothers me more, because it makes otherwise invalid C code valid in this dialect. I'm worried this makes things even more difficult to explain to beginners (and not so beginners, I still have to check the aliasing rules from time to time to make sure the code I'm writing is valid). Even if you're very optimistic this friendly C is not going to replace daddy anytime soon. There'll be plenty of C code out there, plenty of C toolchains, plenty of C environment where the definition of friendliness is having a dump of the registers and stack on the UART in case of an error. Plenty of environments where memcpy is actually memcpy, not memmove. For that reason I'd be much more in favour of advocating the use of more modern alternatives to C (and there are a bunch of those) rather than risking blurring the lines some more about what is and isn't undefined behaviour in C.

pascal_cuoq 12y ago
> There'll be plenty of C code out there Precisely. The idea here is that any C program that does not specifically require one's complement or sign-magnitude representation will work just as well compiled as friendly C as it does compiled as C. Also, just because testing has found no exploitable bugs in a C program compiled with GCC 4.8 does not mean that GCC 4.9 will not introduce a new optimization that wreaks havoc with undefined behavior that was there all along. No such surprises with friendly C. It's the trusty C compiler that you had in 1995, and it always will be. Security-critical programs would never rely on undefined behavior!, you might say. Let us take the example of ntpd, one of the building blocks of the Internet, considered critical enough to be part of two Google bounty programs. Here is a list of currently harmless undefined behaviors in it that a compiler could use as an excuse to produce vulnerable binary code tomorrow: http://bugs.ntp.org/buglist.cgi?emailreporter1=1&emailtype1=substring&email1=trust-in-soft http://bugs.ntp.org/buglist.cgi?emailreporter1=1&emailtype1=... Friendly C is not a new language. It is C as most developers understand it, and with bad surprises prohibited as much as possible. Disclaimer: Julien, who reported these ntpd undefined behaviors, is my colleague, and I am a co-author of the “friendly C” proposal.

rwmj 12y ago

I would think also something like "if I write a piece of code, the compiler should compile it", perhaps "or else tell me with a warning that it isn't going to compile it".

userbinator 12y ago

I really like these suggestions since they can be summed up in one sentence: they are what C programmers who write code with UB would already expect any reasonably sane platform would do. I think it's definitely a very positive change in attitude from the "undefined behaviour, therefore anything can happen" that resulted in compilers' optimisations becoming very surprising and unpredictable. Rather, we are trying rescue the predictable little language that we all know is hiding within the C standard. Well said. I think the practice of UB-exploiting optimisation was completely against the spirit of the language, and that the majority of optimisation benefits happen in the compiler backend (instruction selection, register allocation, etc.) At least as an Asm programmer, I can attest that IS/RA can make a huge difference in speed/size. The other nice point about this friendly C dialect is that it still allows for much optimisation, but with a significant difference: instead of basing it on assumptions of UB defined by the standard, it can still be done based on proof; e.g. code that can be proved to be unneeded can be eliminated, instead of code that may invoke UB. I think this sort of optimisation is what most C programmers intuitively agree with.

_delirium 12y ago
instead of basing it on assumptions of UB defined by the standard, it can still be done based on proof; e.g. code that can be proved to be unneeded can be eliminated, instead of code that may invoke UB. I think this sort of optimisation is what most C programmers intuitively agree with. The main motivation for relying on some of the UB assumptions is that compilers weren't able to prove things in a lot of cases where programmers expected them to, because C (especially in the face of arbitrary pointers, and esp. with incremental compilation) is quite hard to prove things about. So compilers started inferring things about variables from what programmers do with them. For example, if a pointer is used in a memcpy(), then the programmer is signalling to us that they know this is a non-null pointer, since you can't pass NULL as an address to memcpy(). So when compiled with non-debugging, high-optimization flags, the compiler trusts the programmer, and assumes this is a known-to-be-non-null pointer. It would be interesting to see some benchmarks digging into whether turning off that kind of inference has significant performance impact on real-world code. Without adding more source-level annotations to C (like being able to flag pointers as non-NULL), it will reduce some optimization opportunities, since the compiler won't be able to infer as many things, even things that are definitely true. But it might not be enough cases to matter.

Someone 12y ago

"Reading from an invalid pointer either traps or produces an unspecified value." That still leaves room for obscure behavior: if( p[i] == 0) { foo();} if( p[i] != 0) { bar();} Calling foo might change the memory p points at (p might point into the stack or it might point to memory in which foo() temporarily allocates stuff, or the runtime might choose to run parts of free() asynchronously in a separate thread), so one might see cases where both foo and bar get called. And yes, optimization passes in the compiler might or might not remove this problem. Apart from truly performance-killing runtime checks i do not see a way to fix this issue. That probably is the reason it isn't in the list. (Feel free to replace p[i] by a pointer dereference. I did not do that above because I fear HN might set stuff in italics instead of showing asterisks)

mseebach 12y ago
Short of languages like clojure and haskell that are heavily opinionated on immutability and side effects, I can't think of any languages that meaningfully protects against that kind of obscure behaviour. Indeed, it seems "else" was meant for exactly this kind of code.

Ono-Sendai 12y ago

Not sure this is a good idea. Since a lot of behaviour becomes implementation-defined, code written in this dialect will not be portable.

andrewchambers 12y ago
It already is implementation defined by accident.

sjolsen 12y ago

I don't really see what's to be accomplished by most of the points of this. A program that invokes undefined behaviour isn't just invalid; it's almost certainly _wrong_. Shifting common mistakes from undefined behaviour to unspecified behaviour just makes such programs less likely to blow up spectacularly. That doesn't make them correct; it makes it harder to notice that they're incorrect. Granted, not everything listed stops at unspecified behaviour. I'm not convinced that that's a good thing, though. Even something like giving signed integer overflow unsigned semantics is pretty effectively useless. Sure, you can reasonably rely on twos-complement representation, but that doesn't change the fact that you can't represent the number six billion in a thirty-two bit integer, and it doesn't make 32-bit code that happens to depend on the arithmetic properties of the number six billion correct just because the result of multiplying two billion by three is well-defined. Then there's portability. Strict aliasing is a good example of this. Sure, you can access an "int" aligned however you like on x86. It'll be slow, but it'll work. On MIPS, though? Well, the compiler could generate code to automate the scatter-gather process of accessing unaligned memory locations. This is C, though. It's supposed to be close to the metal; it's supposed to force-- I mean, let you do everything yourself, without hiding complexity from the programmer. How far should the language semantics be stretched to compensate for programmers' implicit, flawed mental model of the machine, and at what point do we realize that we already have much better tools for that level of abstraction?

scott_s 12y ago
I have a feeling you haven't read through all of the linked posts and papers. The problem they're trying to address is that C compliers take advantage of undefined behavior for optimizations. Such optimizations can cause very strange, unintuitive behavior that is very difficult to discover. The linked posts, papers, and even this thread provide many great examples. You're right that the programs are wrong. The goal of this proposal is to make them wrong in reasonable ways.
- sjolsen 12y ago
  >The problem they're trying to address is that C compliers take advantage of undefined behavior for optimizations That's not a problem. That's a good thing. >Such optimizations can cause very strange, unintuitive behavior that is very difficult to discover That's a problem -- or at least the "difficult to discover" part is. "Strange" and "unintuitive" is helpful; it's a nice, big red flag. How does migrating from undefined behaviour to producing unspecified values make bugs easier to discover? I can see how they would make results more consistent, and the bugs easier to hunt down, but that's only useful once you know the bugs are there (inconsistency is another useful red flag here), and there are already good tools like valgrind and ubsan for tracking down the source of the bug. >The goal of this proposal is to make them wrong in reasonable ways That isn't the purview of C, though. It's a noble goal, don't get me wrong, but stepping on the optimizer's toes and reinforcing plainly bad programming practices -- I know that's not an intended effect, but it will happen -- isn't the way to do it. A better way, just as an example, would be to give the programmer a proper mechanism for encoding preconditions and other interprocedure-analysable constraints. This doesn't reinforce bad practices, it could actually help the optimizer if done right, and would perhaps encourage programmers to reason a little more rigorously about their code -- an ounce of prevention and all that.

jhallenworld 12y ago

I have strong feelings that the C standard (and, by extension, C compilers) should directly support non-portable code. It means many behaviors are not "undefined"- instead they are "machine dependent". Thus overflow is not undefined- it is _defined_ to depend on the underlying architecture in a specific way. C is a more useful language if you can make machine specific code this way. I'm surprised that some of the pointer math issues come up. Why would the compiler assume that a pointer's value is invalid just because the referenced object is out of scope? That's crazy.. Weird results from uninitialized variables can sometimes be OK. I would kind of accept strange things to happen when an uninitialized bool (which is really an int) is not exactly 1 or 0. Perhaps a better way to deal with the memcpy issue is this: make memcpy() safe (handles 0 size, allows overlapping regions), but create a fast_memcpy() for speed.

dllthomas 12y ago
The standard differentiates between "undefined" and "implementation defined".
- to3m 12y ago
  ...with one option for undefined behaviour being for it to behave "in some documented manner characteristic of the platform" (C11 para 3.4.3.2). Which is not the same thing as being implementation defined, of course, but is at least a step above simply deciding your program is invalid and generating bogus code because of it. So compilers could do this stuff already. I have no idea why they don't. C isn't really the language for people who want platform independence.
  - dllthomas 12y ago
    Well sure. They don't because you can get better performance if you are able to eliminate branches that you can prove aren't taken.

kazinator 12y ago

> 1. The value of a pointer to an object whose lifetime has ended remains the same as it was when the object was alive. This does not help anyone; making this behavior defined is stupid, because it prevents debugging tools from identifying uses of these pointers as early as possible. In practice, existing C compilers do behave like this anyway: though any use of the pointer (not merely dereferencing use) is undefined behavior, in practice, copying the value around does work. > 2. Signed integer overflow results in two’s complement wrapping behavior at the bitwidth of the promoted type. This seems like a reasonable request since only museum machines do not use two's complement. However, by making this programming error defined, you interfere with the abilty to diagnose it. C becomes friendly in the sense that assembly language is friendly: things that are not necessarily correct have a defined behavior. The problem is that then people write code which depends on this. Then when they do want overflow trapping, they will have to deal with reams of false positives. The solution is to have a declarative mechanism in the language whereby you can say "in this block of code, please trap overflows at run time (or even compile time if possible); in this other block, give me two's comp wraparound semantics". > 3. Shift by negative or shift-past-bitwidth produces an unspecified result. This is just word semantics. Undefined behavior, unspecified: it spells nonportable. Unspecified behavior may seem better because it must not fail. But, by the same token, it won't be diagnosed either. A friendly C should remove all gratuitous undefined behaviors, like ambiguous evaluation orders. And diagnose as many of the remaining ones which are possible: especially those which are errors. Not all undefined behaviors are errors. Undefined behavior is required so that implementations can extend the language locally (in a conforming way). One interpretation of ISO C is that calling a nonstandard function is undefined behavior. The standard doesn't describe what happens, no diagnostic is required, and the range of possibilities is very broad. If you put "extern int foo()" into a program and call it, you may get a diagnostic like "unresolved symbol foo". Or a run-time crash (because there is an external foo in the platform, but it's actually a character string!) Or you may get the expected behavior. > 4. Reading from an invalid pointer either traps or produces an unspecified value. In particular, all but the most arcane hardware platforms can produce a trap when dereferencing a null pointer, and the compiler should preserve this behavior. The claim here is false. Firstly, even common platforms like Linux do not actually trap null pointers. They trap accesses to an unmapped page at address zero. That page is often as small as 4096 bytes. So a null dereference like ptr[i] or ptr->memb where the displacement goes beyond the page may not actually be trapped. Reading from invalid pointers already has the de facto behavior of reading an unspecified value or else trapping. The standard makes it formally undefined, though, and this only helps: it allows advanced debugging tools to diagnose invalid pointers. We can run our program under Valgrind, for instance, while the execution model of that program remains conforming to C. We cannot valgrind the program if invalid pointers dereference to an unspecified value, and programs depend on that; we then have reams of false positives and have to deal with generating tedious suppressions. > 5. Division-related overflows either produce an unspecified result or else a machine-specific trap occurs. Same problem again, and this is already the actual behavior: possibilities like "demons fly out of your nose" does not happen in practice. The friendly thing is to diagnose this, always. Carrying on with a garbage result is anything but friendly. > It is permissible to compute out-of-bounds pointer values including performing pointer arithmetic on the null pointer. Arithmetic on null works on numerous compilers already, which use it to implement the offsetof macro. > memcpy() is implemented by memmove(). This is reasonable. The danger in memcpy not supporting overlapped copies is not worth the microoptimization. Any program whose performance is tied to that of memcpy is badly designed anyway. For instance if a TCP stack were to double in performance due to using a faster memcpy, we would strongly suspect that it does too much copying. > The compiler is granted no additional optimization power when it is able to infer that a pointer is invalid. That's not really how it works. The compiler assumes that your pointers are valid and proceeds accordingly. For instance, aliasing rules tell it that an "int *" pointer cannot be aimed at an object of type "double", so when that pointer is used to write a value, objects of type double can be assumed to be unaffected. C compilers do not look for rule violations as an excuse to optimize more deeply, they generally look for opportunities based on the rules having been followed. > When a non-void function returns without returning a value, an unspecified result is returned to the caller. This just brings us back to K&R C before there was an ANSI standard. If functions can fall off the end without returning a value, and this is not undefined, then again, the language implementation is robbed of the power to diagnose it (while remaining conforming). Come on, C++ has fixed this problem, just look at how it's done! For this kind of undefined behavior which is erroneous, it is better to require diagnosis, rather than to sweep it under the carpet by turning it into unspecified behavior. Again, silently carrying on with an unspecified value is not friendly. Even if the behavior is not classified as "undefined", the value is nonportable garbage. It would be better to specify it a zero than leave it unspecified: falling out of a function that returns a pointer causes it to return null, out of a function that returns a number causes it to return 0 or 0.0 in that type, out of a function that returns a struct, a zero-initialized struct, and so on. Predictable and portable results are more friendly than nonportable, unspecified, garbage results.

Verdex 12y ago

I think it's interesting that the famous tech companies are all developing programming languages that are less managed than java/c#, but more predictable (read: less undefined behavior) than c/c++. Facebook seems interested in D, Apple has Swift, Microsoft has some sort of secret project they are working on, Google has Go, and Mozilla has Rust. Even c++ seems to be attempting to modernize with the new additions to it's spec. And now we see a desire for c itself to change. I wonder if our industry is at a turning point where managed languages aren't quite cutting it, but no one is comfortable going back to the 'good old days'. On a personal note, I like the idea of friendly C so much that I finally made an HN account. One of my favorite things to do is to take things apart and understand them. I was mortified when I learned the real meaning of undefined behavior in c/c++. It seems like the only way to be sure you understand a C program is to check the generated machine code. Even worse is that when I try to talk to other developers about undefined behavior, I tend to get the impression that they don't actually understand what undefined behavior means. I can't think of a way to verify what they think it means without insulting their intelligence, but hopefully the existence of something like friendly C will make it an easier discussion to have.

_pmf_ 12y ago
> Microsoft has some sort of secret project they are working on Microsoft has a multitude of secret programming language projects, and the nice thing about them is that when they migrate into C#, people actually will use them.
72deluxe 12y ago
I wonder if the managed languages "aren't cutting it" because they're not fashionable and seen as stinky old dinosaurs to the generation of developers growing up now? I mean, some people openly scoff at languages that aren't Python or ECMAScript, and it appears to be very/extremely fashionable/obligatory on HN to aggressively bash C++, even when it appears that many haven't written or maintained anything in it, and casually dismiss it as "complicated" and daft as it has no compulsory garbage collection. "Huh! It allows to you address memory! HOW STUPID. Why would a language even exist anymore that lets you do that?!" When reading some of the concepts behind C++ and the reasons for decisions, some of them make excellent sense. The 'newer' languages are simpler, primarily because they haven't had decades of existence for people to demand the features that people have demanded in C++. Where I work we use C and C++ for most things, but that's just the industry we're in. It appeared to become the norm to teach Java at universities now (from the people I have bumped into), so C++ and C are no longer the starting points for development for most graduates, perhaps?

dschiptsov 12y ago

Show us, please, how the dialect of C which is used for development of the Plan9 is unfriendly and not good-enough.

astrange 12y ago
It's been empirically demonstrated that C wasn't good enough for Rob Pike.
- dschiptsov 12y ago
  Are you in love with Golang too?)

Roboprog 12y ago

Back in 1990, it didn't take long to figure out that (Borland) Turbo Pascal was much less insane than C. Unfortunately, it only ran on MS-DOS & Windows, whereas C was everywhere. Employers demanded C programmers, so I became a C programmer. (now I'm a Java programmer, for the same reason, and think it's also a compromised language in many ways) For anybody who is willing to run a few percent slower so that array bounds get checked, there is now an open source FreePascal environment available, so as not to be dependent on the scraps of Borland that Embarcadero is providing at some cost. Of course, nobody is going to hire you to use Pascal. (or any other freaky language that gets the job at hand done better than the current mainstream Java and C# languages)

zamalek 12y ago
Pascal, in general, was an amazing language. Simple to understand, compiled to native code - honestly the only complaint you could now (with FreePascal) make about the language is that it is a little "wordy." Much the same as D - which was my initial thought when I read "friendly C." We already have a friendly C.
- peapicker 12y ago
  When I first learned C, after having used Turbo Pascal for years (back in the 80s) it was frustrating. When I finally understood it well a little later, I felt like I had taken off the shackles of Pascal...
  - Roboprog 12y ago
    Granted, original, 1970, flavor Pascal on the CDC Cyber was very limited. I'm curious, though, what is it that Turbo Pascal 5.0 and above would prevent you from doing? It's been a while, but if I really have to, I could cast a pointer to a long, increment it by sizeof in a loop, and cast it back to a pointer in Pascal to do pointer arithmetic in a tight loop. I can use procedural types anywhere a function pointer in C would be used. I can make complex constants (tables) just like a pre-initialized array of structs in C. There is an extension to return in the middle of a function/procedure rather than toggling flags to pinball-style drop to the end of the routine. I can set compiler pragmas to allow/force me to check for error codes after every memory and I/O call (at the risk of accidentally stumbling on to cause secondary damage), rather than just failing with a line number. I can nest functions inside of other functions, and reference the enclosing variables, just like in GNU C (oh, wait, that's a non-standard GNU extension), even if I can't return such a function as a "use it later", honest to God closure. What are the shackles? (I'm probably in for a face palm, oh, that, moment when I get the answer, but I'm drawing a blank at the moment)