Hi Guys, Suppose a programmer creates a function called "memset" and then compiles it with gcc. Eg:
% cat memset.c void * memset (void *s, int c, unsigned int n) { char *v = s; while (n--) *v++ = c; return s; } % gcc -O3 -S -fno-builtin memset.c % cat memset.s memset: .LFB0: .cfi_startproc testl %edx, %edx je .L6 subl $1, %edx subq $8, %rsp .cfi_def_cfa_offset 16 movsbl %sil, %esi addq $1, %rdx call memset addq $8, %rsp .cfi_def_cfa_offset 8 ret Note the infinite recursion. Memset calls memset which calls memset and so on. This is with an x86_64 compiler built from today's sources, but the problem exists for all targets. The "-fno-builtin" is just to avoid the warning about the conflicting types of the memset function, but the "-O3" is necessary in order to make gcc detect the loop and decide to expand it via a library function. Now presumably the programmer knows that there is a library function called memset, but also presumably they have their own reasons for creating a memset function. Perhaps they want to add some extra annotation or debugging. It does not seem illegal though. A program provided function should take precedence over a library provided one. Anyway it seems to me that gcc should not attempt to call a function called "memset" if it is compiling code inside a function called "memset". The problem is, I cannot see an easy way of enforcing this. The memset builtin expander is called from several different places and I am not at all sure how, or if, they should be modified. Any clues ? Cheers Nick