

Writing Bug-Free C Code (1995) - kabouseng
https://www.duckware.com/bugfreec/index.html

======
unwind
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.

~~~
pjmlp
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...](https://channel9.msdn.com/Events/Visual-Studio/Connect-
event-2014/029)

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-...](http://blogs.msdn.com/b/vcblog/archive/2014/06/10/the-great-crt-
refactoring.aspx)

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

~~~
pjmlp
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.

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

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

~~~
copx
>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..

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

~~~
agumonkey
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.

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

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

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

Archived:
[https://web.archive.org/web/20150327121925/http://www.duckwa...](https://web.archive.org/web/20150327121925/http://www.duckware.com/bugfreec/index.html)

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

------
ExpiredLink
A classic but not well-known C resource.

~~~
McUsr
Thanks a lot for the link. :)

~~~
ExpiredLink
Thanks to the OP.

