Girish Venkatachalam is a UNIX hacker with more than a decade of
networking and crypto programming experience.
His hobbies include yoga,cycling, cooking and he runs his own
business. Details here:
https://gayatri-hitech.com
https://spam-cheetah.com
Doing even the simplest programming tasks in C can be daunting due to its fondness for segfaulting. A C program can be found crashing on printf, command line parsing or nearly every attempt to print a string that is NULL. Or even access it.
Of course C can crash and behave nastily in many other ways too. That is why you need hand holding when you are learning C programming.
And one continues to learn C programming for many many years. I have dealt with this topic in my other articles in this very site. So please refer to those articles for the facets of C that trips newbies.
In any case I had to write this code sample as part of my work. I am presently reverse engineering the MAPI protocol that MS Outlook speaks to MS Exchange. My work does not so much involve reverse engineering since Microsoft has published the entire MAPI protocol in full detail.
So my work mostly involves implementing the specification. And there is a project called OpenChange that has done the bulk of the work by riding on top of Samba project. In spite of all this context and help, I still find the project pretty daunting and challenging.
As part of this work I had to read and write mail attachments. So I thought I will write a simple C program and validate it before integrating with the rest of the complex stuff.
In so doing I felt that this sample might help a beginner C programmer and even some experience hands since file I/O is such a common activity and C is filled with various slips and dangers.
I could have read the file size by reading the file header using the stat(2) system call. But I chose this approach of read(2) returning zero. Of course you could improve this program in many ways. But this program is good in many ways though purists may object to some of my practices.
Using syslog() is a great way to debug and inform the user what is going on. I want to switch over from using printf() to this as this can double up as printf once you open the log with the LOG_PERROR flag.
Once the development phase of the program is over you can remove this flag and all logs go to the logfile alone. It is quite cool.
Of course you can do pretty much everything this does using perl or any other scripting language also. Please look at Sys::Syslog in perl.
In case you are wondering, this program can read and write binary files as well as text files. Shows the power and simplicity of C programming and in an oblique way also the genius/simplicity of UNIX itself.
I will now leave the program to do the rest of the talking.
#include <stdio.h>Got something to add? Send me email.
More Articles by Girish Venkatachalam © 2011-03-26 Girish Venkatachalam
Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? (Brian Kernighan)
Mon Oct 19 13:28:37 2009: 7298 TonyLawrence
due to its fondness for segfaulting.
Well, C itself has no such fondness. Our sloppy programming certainly does, but that's not C's fault :-)
Mon Oct 19 21:07:51 2009: 7301 BruceGarlock
Just a little 'nitpick' -- on my screen (24" iMac) the yellow code highlighting is difficult to read (the if statements)
Mon Oct 19 21:43:32 2009: 7302 AndrewSmallshaw
Segfaults can actually be quite a useful thing - one of the more useful debugging tools for C is ElectricFence whose sole purpose is to cause segfaults and cause them quickly. That helps resolve all kinds of pointer errors in low-level data structures. In general I would prefer my program to crash and burn than come up with obviously incorrect results - it is generally a whole lot easier to debug.
Along the same lines I tend to make fairly extensive use of assert() in my code - assert(0s serve a documentary function regarding prerequisites and expected conditions, but they also help enormously when debugging. In a debugger I almost never use watchpoints and only rarely breakpoints - a debugging session typically involves running the program as normal inside the debugger and waiting for something to blow up. If the tests are smartly placed and liberal enough (without being distracting) you can usually find the problem early enough to see what the problem is straight away.
Mon Oct 19 22:32:19 2009: 7305 TonyLawrence
the yellow code highlighting is difficult to read
Just one more reason I don't like color highlighting.
------------------------
Printer Friendly Version
A simple file I/O program in C Copyright © October 2009 Girish Venkatachalam
Have you tried Searching this site?
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.
Contact us
Printer Friendly Version