Writing Bug-Free C Code (1995) | Hacker News Reader

Writing Bug-Free C Code (1995)

duckware.com

58 pointskabouseng26 comments

This is very old, so it isn't even aware of C99 which leads to lots of bogus suggestions and tips.

Unless you know that you're going to be targeting truly ancient architectures/platforms, C99 really is the absolute minimum thing to be using these days when developing in C. It's 15 years old, it's not "new" or "non-standard" or "non-portable".

Edit: Of course I'm aware that Visual Studio doesn't support C99, so I guess that sorts under "truly ancient architectures/platforms", then. For C development, Windows' flagship development environment is ancient. I know it's a great IDE, but it's not a great C compiler since it doesn't support the language any more.

People are still using Visual Studio as far as I know and Visual Studio isn't supporting C99, which makes C99 non-portable as long as Visual Studio is the default compiler for Windows and Windows beeing a big player.

Is windows a big player for C development? If you want to code for windows there are better options. If you want to write C there are better options than VS.

I like PellesC for playing around on my own projects, but have wondered if there's anyone using it for serious development.

http://en.wikipedia.org/wiki/Pelles_C

http://www.smorgasbordet.com/pellesc/

Sorry, I don't know what planet you're living on but here in the real world of professional software development much of the world's software has to compile in Visual Studio -- which did not support C99 for years and still only partially supports it.

Same as Nursie, I guess coding new software in C on Windows is an antipattern.

The official narive-code application language for Windows is C++. Microsoft recommends you use that.

Everybody who develops SIL 4 code has a really tough time using any modern compiler, because the compiler has to be approved for development of security critical code. This usually means that the shippable version of your code has to compile on some proprietary compiler that is at least twenty years old and can't be improved without losing its certification.

Microsoft's official position is that any greenfield project should be in C++ and for those developers that really want a C compiler there are other options.

Specially in a world where most APIS are either .NET or transitioning to COM/Windows Runtime.

At last year's "Connect(); Microsoft Visual Studio vNext & Azure", they confirmed the C++ focus for native code, besides the upcoming .NET Native.

https://channel9.msdn.com/Events/Visual-Studio/Connect-event...

The C99 support that has been added was what is required by C++ standard and some specific customers.

Even the new C runtime is actually implemented in C++ with the functions exposed as extern "C".

http://blogs.msdn.com/b/vcblog/archive/2014/06/10/the-great-...

I believe the upcoming .NET Native applies only to Windows Store apps, not to Windows Desktop apps, which I find it is a pity.

You always have NGEN, besides this is v1.0. They are pretty open that it might change in the future.

Personally I think it is bound to the adoption of the Windows Store and the Universal App model.

Since MS Visual Studio 2013, VS supports C99. It looks like MS wanted to "deprecate" the C language. They seem to acknowledge their mistake in an implicit way, in my opinion.

http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-librar... describes what they added in VS 2013 and what is still missing.

http://blogs.msdn.com/b/vcblog/archive/2014/06/18/crt-featur... from June of last year says in part:

    In the Visual Studio "14" CTP we have fully implemented the C99 Standard
    Library, with the exception of any library features that depend on compiler
    features not yet supported by the Visual C++ compiler (notably, <tgmath.h>
    is not implemented). There are undoubtedly some remaining conformance issues--
    we know of a few, including that _Exit is missing and wcstok has the wrong
    signature, and we are working to fix these.

"CTP" == "Community Tech Preview", i.e. a beta.

Well, in VS 2013 there was C99 language support, i.e. my C99 code compiled properly (while not in previous VS editions). I had to add minor modifications because the C library (e.g. %zu for printing size_t arguments -not sure if already covered by VS 2014-), as the article pointed by you tells.

A couple of years back I worked as a programmer maintaining and extending a Windows application whose development had started in 1993. Besides teaching me to hate the Win32 API with vigor, that job and the application taught me - and motivated me to learn - a lot about C. About halfway through my time at that company, I came across this book, and I really liked it. Those were interestings times. ;-) We used OpenWatcom, whose debugger sucks really hard - basically, the moment your program crashes, you cannot inspect any of its state with the debugger, which pretty defeats the purpose of a debugger. The profiler sucked even harder. It was a PC-sampling profiler, and once the number of samples exceeded some magical value, it crashed, taking the program down with it. The compiler itself never gave me any problems, though, and it came with good documentation. It was also one of the few C compilers left that could target DOS. (Don't laugh, more recently I had to write a small program for DOS to set the serial port on a machine attached to an industrial control system to specific parameters.)

Sorry for rambling, but this brought up some pleasant memories... :)

I think the title is a bit strongly worded, but other than that it is a really good book. When writing large-ish applications in C, one has to develop strategies for dealing with some of C's problems, and even if you disagree with some of the author's suggestions (or, as somebody else pointed out, find them obsolete because of C's ongoing evolution), it gets you thinking about those issues.

EDIT: Whether C is the right language for writing large-ish applications is a different issue, but in the early nineties, it was a relatively prudent choice, and if a program is popular/useful enough, someone has got to do the maintenance.

The title reminds me of a book I used to have years ago called 'Writing Bug Free C Code for Windows'. It was a great and not windows specific all all, covering object systems and all the nooks and crannies of the language. It was on par with some of the Lisp books I have regarding coverage of language features. Highly recommended for those interested in what you can do with C, but I'm sure it's impossible to find these days.

>The title reminds me of a book I used to have years ago called 'Writing Bug Free C Code for Windows'.

Actually this is a link to that book..

D'oh. Guess I should read the article sometimes before I comment :)

It might ease your mind knowing that your lisp mention made me mirror the webpages. Maybe if you read it beforehand you'd write a different comment, and I'd never read it myself.

Oh no! I've been going around telling my clients that you can only verify the existence of a bug, not their absolute absence, and that expected behaviour from years ago may not always match what you expect today. I hope none of them see this, and realize that I'm just too lazy to properly install the Windows debug kernel.

"Variables should be named using Hungarian notation."

Please note that this is from a different time and space, and that you should not apply such rules to every language.

"Error 403 - Forbidden" - anyone else getting that?

Archived: https://web.archive.org/web/20150327121925/http://www.duckwa...

Wrapping library functions is very helpful when I am doing my own project. I understand the interface and can fix any misunderstandings I had when I used the standard functions. It is great.

However, when I run across someone who helpfully wrapped the standard interfaces in the code I need to maintain. I want to burn him alive.

A classic but not well-known C resource.

Thanks a lot for the link. :)

Thanks to the OP.

Reply on news.ycombinator.com