d_name member of struct dirent

[Sam Zoghaib]

Hello,

There is someting strange I've noticed when debugging code that use struct
dirent.
If you consider the follwing piece of code, which prints the name of all files
in the directory /home/foo

#include <dirent.h>
#include <stdio.h>

int main()
{
struct dirent *dp;
DIR *dfd;
dfd = opendir("/home/foo);
while ((dp = readdir(dfd)) != NULL)
printf("%s\n", dp->d_name);
return 0;
}

It works well (I haven't provided any error checking because it is not
relevant to my question) but if I set a breakpoint after dp has been
initialized, for instance, right before the call to printf and check the
value of dp->d_name, I get garbage.
Am I missing something?

Thank you,
Sam
--
"So if you meet me, have some courtesy, have some sympathy, and some taste
Use all your well-learned politesse, or I'll lay your soul to waste"

- The Rolling Stones, "Sympathy for the Devil"

[Jens.Toerring@physik.fu-berlin.de]

Sam Zoghaib <--sam@zep.homedns.org--> wrote:

> There is someting strange I've noticed when debugging code that use struct
> dirent.
> If you consider the follwing piece of code, which prints the name of all files
> in the directory /home/foo

> #include <dirent.h>
> #include <stdio.h>

> int main()
> {
> struct dirent *dp;
> DIR *dfd;
> dfd = opendir("/home/foo);
> while ((dp = readdir(dfd)) != NULL)
> printf("%s\n", dp->d_name);
> return 0;
> }

> It works well (I haven't provided any error checking because it is not
> relevant to my question) but if I set a breakpoint after dp has been
> initialized, for instance, right before the call to printf and check the
> value of dp->d_name, I get garbage.
> Am I missing something?

Did you compile with optimization switched on? In this case it would
be possible (or even likely) that dp is kept in a register and the
"real" variable in memory you're looking at in the debugger never
gets changed, only the register.
Regards, Jens
--
_ _____ _____
| ||_ _||_ _| [email]Jens.Toerring@physik.fu-berlin.de[/email]
_ | | | | | |
| |_| | | | | | [url]http://www.physik.fu-berlin.de/~toerring[/url]
\___/ens|_|homs|_|oerring

[Sam Zoghaib]

[email]Jens.Toerring@physik.fu-berlin.de[/email] wrote in article
<behp52$5bf9p$2@fu-berlin.de> on Wednesday 09 July 2003 21:07 in
comp.unix.programmer:

> Did you compile with optimization switched on?

No, I didn't.

Sam
--
"Fear is the path to the dark side.
Fear leads to anger, anger leads to hatred, hatred leads to suffering.
I sense much fear in you."

[dbtid]

Sam Zoghaib wrote:

> Hello,
>
> There is someting strange I've noticed when debugging code that use struct
> dirent.
> If you consider the follwing piece of code, which prints the name of all files
> in the directory /home/foo
>
> #include <dirent.h>
> #include <stdio.h>
>
> int main()
> {
> struct dirent *dp;
> DIR *dfd;
> dfd = opendir("/home/foo);
> while ((dp = readdir(dfd)) != NULL)
> printf("%s\n", dp->d_name);
> return 0;
> }
>
> It works well (I haven't provided any error checking because it is not
> relevant to my question) but if I set a breakpoint after dp has been
> initialized, for instance, right before the call to printf and check the
> value of dp->d_name, I get garbage.
> Am I missing something?
>
> Thank you,
> Sam

It might be something as simple as you forgot to turn on the debugging
flag for your compilation. That might cause odd results in what you're
seeing, based on where the debugger thinks the instructions are for the
line you're trying to break on.

What compiler/debugger suite are you using?

[Sam Zoghaib]

dbtid wrote in article <2bfe7ca0a6e068b9129a9f58f7df0857@free.teranews.co m> on
Wednesday 09 July 2003 21:29 in comp.unix.programmer:

> It might be something as simple as you forgot to turn on the debugging
> flag for your compilation. That might cause odd results in what you're
> seeing, based on where the debugger thinks the instructions are for the
> line you're trying to break on.

No, I did not forget to turn debugging info on. In fact, that's the only
variable for which I get garbage.

> What compiler/debugger suite are you using?

gcc (I tried 2.95, 3.0, 3.2 and 3.3) and the debugger is gdb.

Sam
--
"Giving the Linus Torvalds Award to the Free Software Foundation is a bit like
giving the Han Solo Award to the Rebel Alliance"

- Richard Stallman, August 1999

[Jens.Toerring@physik.fu-berlin.de]

Sam Zoghaib <--sam@zep.homedns.org--> wrote:

> dbtid wrote in article <2bfe7ca0a6e068b9129a9f58f7df0857@free.teranews.co m> on
> Wednesday 09 July 2003 21:29 in comp.unix.programmer:

>> It might be something as simple as you forgot to turn on the debugging
>> flag for your compilation. That might cause odd results in what you're
>> seeing, based on where the debugger thinks the instructions are for the
>> line you're trying to break on.

> No, I did not forget to turn debugging info on. In fact, that's the only
> variable for which I get garbage.

>> What compiler/debugger suite are you using?

> gcc (I tried 2.95, 3.0, 3.2 and 3.3) and the debugger is gdb.

What make you think that you get garbage? If I run your program under
gdb I get e.g. after the first call of readdir()

(gdb) n
10 printf("%s\n", dp->d_name);
(gdb) p dp
$1 = (struct dirent *) 0x80496c8
(gdb) p dp->d_name
$2 =
".\000\000\000\000\002\000\000\000\030\000\000\000 \020\000\000..\000\000\000\220\t\000\000,\000\000\ 000\030\000\000.Xauthority\000\000\213\b\000\000@\ 000\000\000\030\000\000.Xresources\000\000\001À\00 1\000P\000\000\000\020\000\000lab\000\000\005\b\00 0\000h\000\000\000
\000\000.bash_history\000\000\000\000\000\000\000\ 000\023\t\000\000x\000\000\000\030\000\000.bashrc\ 000\000\000\000\000\000\a\b\000\000\220\000\000\00 0
\000\000cperl-mode.el\000\000\000\000\000\000\000\000\202\t\000\ 000*\000\000\000\030\000\000.fvwm2rc\000\000\000\0 00\000\t\b\000"...

What you see here isn't garbage. When you have a look at the header file
/usr/include/bits/dirent.h where "struct dirent" is defined you will
find that the d_name member is defined as

char d_name[256]; /* We must not include limits.h! */

So gdb isn't showing you the string only up to the first '\0' character
(as it would do for a char *) but all 256 chars that belong to d_name.
Perhaps that's why you think you're getting garbage?

Regards, Jens
--
_ _____ _____
| ||_ _||_ _| [email]Jens.Toerring@physik.fu-berlin.de[/email]
_ | | | | | |
| |_| | | | | | [url]http://www.physik.fu-berlin.de/~toerring[/url]
\___/ens|_|homs|_|oerring

[Sam Zoghaib]

[email]Jens.Toerring@physik.fu-berlin.de[/email] wrote in article
<bei6ea$5hdgr$1@fu-berlin.de> on Thursday 10 July 2003 00:54 in
comp.unix.programmer:

> So gdb isn't showing you the string only up to the first '\0' character
> (as it would do for a char *) but all 256 chars that belong to d_name.
> Perhaps that's why you think you're getting garbage?
>

Ok, I see.
But why isn't dp->d_name

<name_of_entry_read>\000\000....

here, it seems it is more like:

<name_of_1st_entry>\000\000...<name_of_2nd_entry<\ 000....

I know it doesn't really matter, since we'll only read up to the first \000,
but the fact that the other entries' names appear mean that we can somehow
know the name of several files in directory (I guess up to 256 - n
characters, n being the number of files) with only one call to readdir(3). I
wonder how.

I realize I should not have called it garbage, since it probably led you to
think I got random character. I had noticed there were filenames in the
output of gdb, but did not notice that the chars up to the first \000 were
always the filename I was looking for. Sorry for the inaccuracy.

Thank you,
Sam
--
"Don't be afraid, I'm gonna give you the choice I never had..."

- Lestat in "Interview with the Vampire" (Ann Rice, 1976)

[David Schwartz]

"Sam Zoghaib >" <<sam@zep.homedns.org> wrote in message
news:bejfbj$m6v$1@news-reader6.wanadoo.fr...

> I know it doesn't really matter, since we'll only read up to the first

\000,

> but the fact that the other entries' names appear mean that we can somehow
> know the name of several files in directory (I guess up to 256 - n
> characters, n being the number of files) with only one call to readdir(3).

I

> wonder how.

Until the system read the file name, it had no idea how big it was. So
it read more bytes than needed. This way, the next call to 'readdir' won't
require a real read (since the system already ready it).

It also might just read the whole directory in one shot. Then it points
you at pieces of it as you call 'readdir'. If you think about it, what would
make the least sense is trying to actually read/parse the directory file by
file.

DS