I recently wrote a small piece of software using opendir/readdir/closedir to access all non-directory entries in a single directory.

I needed to parse the file names to separate a variable length prefix and the main file name.

In doing so, I later realised, I had changed the contents of d_name pointed to by the dirent returned by readdir(). I was surprised that this didn't cause a segmentation fault as, presumably, the dirent is in system space ... or is it? The Linux man page for readdir() only says that the dirent structure is statically allocated.

I was initially going to run this code under Fedora 15 but I found it easier to use Xcode under OS X where I ran it initially, but it runs OK under F15 too.

Does anyone know if the dirent is in system space, and if so why did this not cause a segmentation fault?

Many thanks.

Smiffy

PS Sorry, I realise this should have been posted in Programming. Not sure how to move it.

readdir is a C library call. It allocates a static structure in the process memory. It's not defined what happens if you change the name field but I doubt that it hurts anything as long as you stay in bounds. It will just get overwritten on the next call.

1 members found this post helpful.

smallpond,

Many thanks for that information. That the structure is allocated in process space explains why my code didn't cause a segmentation fault.

All the best

Smiffy

If you look in /usr/include/bits/dirent.h you will see it is an array within the structure itself (256 bytes long).

You aren't supposed to change it as the results can be undefined.

But all data accessed within a process is within the process - even addresses that don't exist (and cause a segfault if used).