5

C often seems to be taught in terms of contracted examples without much regard to code safety, such as buffer overflows etc. I have often wondered if there are proven, totally safe ways of writing C code, because I have seldom encountered C written to handle all eventualities correctly. And now, reading that even the best Gnome programmers make exactly these same errors in C, I think it is time to ask this question here.

In the porting work Mena noticed a number of actually usual errors in the C code such as overflows, which unfortunately are not always obvious. The code for some of these errors comes from the Mena's best C programmers, the Gnome Project ever had. This does not mean that the project has no good programmers. The reason for these mistakes is not people, but rather the language C itself, which is simply "hostile".

So, is it even possible to write safe C? Are there resources which explain how to avoid all these pitfalls?

Felix Dombek
  • 2,109
  • 1
  • 16
  • 24
  • To the downvoter - Care to explain how this is not on topic, being about "software development methods and practices"? – Felix Dombek Jul 31 '17 at 17:12
  • 2
    It's probably being down voted because it's "too broad" (it seems to be looking for a discussion on writing safe C, not asking a specific, answerable question) or a resource request on material to write safe C (where resource requests are off-topic here). – Thomas Owens Jul 31 '17 at 17:24
  • True, it is deliberately a bit broader than "How to avoid buffer overflows with `scanf`", maybe I should narrow it down to "What guidelines exist to avoid buffer overflows at all times". – Felix Dombek Jul 31 '17 at 17:31
  • 1
    Even that proposed edit is too broad. Questions shouldn't generate lists of things or discussions about a topic. They should generate a handful of answers, which can be judged (voted on by) the asker (you) and the community based on the contents of the question. – Thomas Owens Jul 31 '17 at 17:33
  • If even really good programmers still make beginners' errors in a language, it should be able to somehow objectively ask about why, but I am willing to accept that I have gotten it kind of unclear/broad here. – Felix Dombek Jul 31 '17 at 17:48
  • You have asked an important question and these guys should not criticize it's broadness. If there are techniques that can be applied, we all benefit from learning them. – Mike Jul 31 '17 at 17:57
  • 5
    @mike yes we would. We could learn them from reading whole books on the subject. We wouldn't benefit from the rats nest of partial list answers that would get up-voted for reasons haven't very little to do with their comparative merits. It's not you. It's us. – candied_orange Jul 31 '17 at 18:11
  • In general, the C language does nothing to protect the programmer from their self. There are programming languages that go a long way toward protecting the programmer. For instance ADA. However, for C, it is up to the programmer to learn the fine details of the language and to ask their selves lots of 'what if' questions. Careful reading of the 'man' pages will tell you of certain conditions that the programmer should be watching for. – user3629249 Jul 31 '17 at 18:53
  • You may wish to look for formally verified C languages, or language subsets. They do exist, and typically you can verify your program as well. – Frank Hileman Jul 31 '17 at 22:54
  • Key words to help with search would be things like ED109, DO178, SWAL, Avionics. Probably the most widely accepted guideline is "Don't, unless the only other option is C++" :) (Both languages have Undefined behavior, UB is still mostly undetectable, add the joys of the language standard allowing Time Travel, and they are completely unsuitable for writing 'safe' code (However, if by safe you mean 'safe' can be interpreted as 'less unsafe', you can write 'safe' C and C++ code) – mattnz Aug 01 '17 at 04:33
  • _Is it even possible to write safe C?_ Yes. Look for instance at DJB's software (qmail, djbdns, ...). _Are there widely-accepted guidelines to write safe C?_ That probably depends on your definition of widely-accepted. – ninjalj Aug 01 '17 at 10:02
  • For me, though I don't work in mission critical software: 1) unit/integration testing, 2) leak detection (integrated as part of the tests), and 3) avoid fixed-sized buffers or VLAs for variable-sized data (you can use a combo of fixed-sized buffers for common cases that fit and `malloc/free` for cases that don't). That said, I often find it easier to write correct code in C personally than some higher-level languages. The difference is that when my code is incorrect in C, I get hard crashes. In higher-level languages, the software might continue to run fine but glitch out in ways that are... –  Dec 10 '17 at 14:01
  • ... very difficult to trace down or start leaking memory (ex: forgot to free a resource in a language with GC -- nullify a object reference, i.e. -- for the garbage collection to destroy at the time it was logically removed by the user). So while I tend to make fewer mistakes in C personally, when I do, the software blows up... but I find that preferable to the software continuing to run and having hard-to-find bugs that easily fly under the radar and might never get fixed, like garbage-collection-related logical leaks. In C the alternative is usually a hard crash from accessing a dangling... –  Dec 10 '17 at 14:01
  • ... pointer, and I often find it's that kind of difference... hard crash, instantly reproducible, or more obscure, hard-to-find bugs. And for my type of software, the hard crash is actually preferable -- in my field "safety" is often not "crash-proof" but more in the lines of "consistent, easy-to-reproduce behavior". Oh and last but not least, initialize *all* the variables at the time they're defined, even if that's redundant, because uninitialized variables do create very hard-to-reproduce bugs in C, almost as hard to narrow down as a memory leak in a garbage-collected language. –  Dec 10 '17 at 14:05

1 Answers1

4

Developed by the Motor Industry Software Reliability Association (MISRA), the MISRA C guidelines specifically contemplate safe and reliable use of the C programming language in embedded systems.

Brad S.
  • 151
  • 6
  • The "criticism" section of that Wikipedia article is *not* very complimentary. – Robert Harvey Jul 31 '17 at 20:24
  • @RobertHarvey Automated testers to check MISRA compliance can be pretty poor, flagging up loads of false alarms. Trying to re-write *existing* software to meet MISRA rules will probably introduce more bugs than it removes. Neither really indicates a problem with MISRA-C itself. – Simon B Aug 01 '17 at 10:01