List like processing

While restructuring the ants program it seemed wise to start with the minimal implementation and determine that every phase was clean in all aspects. By starting with just main and a signal handler for faults it became clear that something was amiss when run with valgrind. It seems that the structures created for signal handling had an uninitialized field that was actually used by the library.

int setup_sigsegv() {
sigset_t a;
sigemptyset(&a);       /* Initialize empty set */
struct sigaction action;
memset(&action, 0, sizeof(action));
action.sa_sigaction = signal_segv;
action.sa_flags = SA_SIGINFO;
action.sa_mask=a;

The above code solves the problem. sigset_t is an array of bits and so has to be handled using different methods than any other type and cannot be type cast to int or long(AFAIK). By using all the facilities of gcc, and the Linux utilities it is possible to have safe code. There has never been a case where the SIGSEGV failed to act on a fault, however this was an accident waiting to happen on top of another accident. The use of valgrind and -Wall helps to identify and correct many common problems that arise due to the sheer complexity of the systems.

The process is being documented in a book done with LaTeX, and I like those latex equations. It gives an opportunity to document the code, create figures that demonstrate the functions and have a ready resource to refresh the understanding of the more complex aspects of mixing scheme, C, and Python within a list-like framework.

It is my hope to extend the structure interface so that when a structure is created, required fields are analyzed and any use without initialization is flagged.

BTW, there are some new open courses up at Harvard, Stanford, Yale and MIT. Lots of fun, probability, programming, tries, hash , physics, matrices, multi-variable math, astronomy, genetics, AI, and a vast array of useful information.

While proof reading the blog post I noticed "memset" and thus that value was in fact cleared to 0 anyway, oh well, tempest in a teapot.

Strange code from the AI

I can't believe that this works, but then it does and as such I learn something about how the pre-processor works.

#include <stdio.h>
#define monkey int main(){printf("monkey\n"); return 0;}
monkey

gcc monkey.c -o monkey
./monkey

Program output at console.

monkey

I wonder how long it would take somebody to find a fault that was included in the header of some sub header deep into the structure of includes. Obviously it functions as literal GSR ( Global Search and Replace ). In this case it is more like GSW ( Gun Shot Wound ) So I did this:

#define monkey int main(){return 0;}
monkey

How to get the intermediate code.

gcc -E monkey.c -o monkey.pre
cat monkey.pre

Contents of the file monkey.pre

# 1 "monkey.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "monkey.c"

int main(){return 0;}

Turning assertions off , which is something I have seen applied and simply space off, but here it is. By default, ANSI C compilers generate code to check assertions at run-time. Assertion-checking can be turned off by defining the NDEBUG flag by using gcc with the -DNDEBUG flag. To use assertions you would include "assert.h" with code like the following:

#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
int main (){
void *memory;
memory =malloc(100);
assert(memory != NULL);
printf("This prints if allocate succeeds.\n");
free(memory);
}

And finally generates this little piece of work.

int main (){
void *memory;
memory =malloc(100);
((memory != ((void *)0)) ? (void) (0) : __assert_fail 

("memory != ((void *)0)", "monkey.c", 7, __PRETTY_FUNCTION__));
printf("This prints if allocate succeeds.\n");
free(memory);
}

I would show the generated assembly code, but that is pretty obvious so I will leave you with this.