[linux-elitists] Stupid C tricks

Jason Spence jspence@lightconsulting.com
Fri Aug 27 18:46:46 PDT 2004


Something that's been bugging me for a while was the inability to have
an error reporting macro that automatically outputted the filename and
line number of the call to the macro, as well as take variable
arguments in printf(3) format so the programmer could provide some
information on the state of the program at the time the error occured.

I figured it out a way to get both last month; please let me know what
you think.

http://lightconsulting.com/~thalakan/drop/ngdebug.c

You have to use thread-local storage to store _file and _line in a
threaded program that uses this trick, of course.

To use, cut and paste.  Call debug() like you would printf, except
it'll output the filename and line number where the call occured.  You
can also modify format() to dump the buffer to some logging API like
unix syslog(), Win32's ReportEvent(), or VMS's SYS$SNDOPR.

Note that this is especially handy if the stack is likely to be
corrupted when the error occurs and a backtrace is therefore likely to
be invalid or misleading.

Speaking of stack problems:

http://lightconsulting.com/~thalakan/drop/test1.c

That program uses a bit of inline assembly to wrap memcpy.  The
wrapper checks to see if the target buffer is in the local stack
frame, and if so, aborts the program if it detects a buffer overflow.
I initially thought the behavior this program relies on was x86
specific, but I successfully modified it to work on VMS/alpha in both
C and HP FORTRAN.  If you have other weird machines lying around,
please help me add support for other processors and operating systems.

-- 
 - Jason                                                 Last known location: 

Disco is to music what Etch-A-Sketch is to art.



More information about the linux-elitists mailing list