This means that neither NAME_MAX or fpathconf/dirfd/_PC_NAME_MAX are 
available, can you poke around the solaris man pages and see if they are in 
some header we just aren't including, or if there's no way to get these. Also, 
maybe check the readdir_r man page and see how they suggest choosing the size 
of the output parameter passed to it.

According to http://docs.sun.com/app/docs/doc/816-5168/6mbb3hrpf?a=view

"The caller must allocate storage pointed to by entry to be large enough for a 
dirent structure with an array of char d_name member containing at least 
NAME_MAX (that is, pathconf(directory, _PC_NAME_MAX)) plus one elements. 
(_PC_NAME_MAX is defined in <unistd.h>.)"

Is this for a newer version of solaris than you have maybe? Or maybe the 
configure checks did not succeed or fpathconf/dirfd are missing?

Can you try adding -D_POSIX_C_SOURCE=199506L to your cflags?
(or -D_POSIX_PTHREAD_SEMANTICS=1 -D_REENTRANT=1)

I have fpathconf but no dirfd. This is pretty much the latest version of Solaris 10.

Here are separate compiles with the different flags you suggested:

build@sr1-sjc-01:~/Xfce-beta-src/dbus-0.93/dbus% /opt/SUNWspro/bin/cc
-DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -D_POSIX_PTHREAD_SEMANTICS=1
-D_REENTRANT=1 -DDBUS_COMPILATION -DDBUS_API_SUBJECT_TO_CHANGE=1
-I/opt/Xfce-beta/include -I/usr/local/include -I/usr/X11/include
-I/usr/openwin/include -I/usr/sfw/include -I/usr/include
-I/opt/Xfce-beta/include -I/usr/local/include -I/usr/X11/include
-I/usr/openwin/include -I/usr/sfw/include -I/usr/include -c
dbus-sysdeps-util-unix.c  -KPIC -DPIC -o .libs/dbus-sysdeps-util-unix.o
"dbus-sysdeps-util-unix.c", line 520: #error: "buffer size for readdir_r cannot
be determined"
cc: acomp failed for dbus-sysdeps-util-unix.c


build@sr1-sjc-01:~/Xfce-beta-src/dbus-0.93/dbus% /opt/SUNWspro/bin/cc
-DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -D_POSIX_C_SOURCE=199506L
-DDBUS_COMPILATION -DDBUS_API_SUBJECT_TO_CHANGE=1 -I/opt/Xfce-beta/include
-I/usr/local/include -I/usr/X11/include -I/usr/openwin/include
-I/usr/sfw/include -I/usr/include -I/opt/Xfce-beta/include -I/usr/local/include
-I/usr/X11/include -I/usr/openwin/include -I/usr/sfw/include -I/usr/include -c
dbus-sysdeps-util-unix.c  -KPIC -DPIC -o .libs/dbus-sysdeps-util-unix.o
"/usr/include/sys/resource.h", line 146: incomplete struct/union/enum timeval:
ru_utime
"dbus-sysdeps-util-unix.c", line 261: warning: implicit function declaration:
setgroups
"dbus-sysdeps-util-unix.c", line 520: #error: "buffer size for readdir_r cannot
be determined"
cc: acomp failed for dbus-sysdeps-util-unix.c

http://archives.neohapsis.com/archives/fulldisclosure/2005-10/0666.html
mentions that on solaris we might have to do open() and then fdopendir().
an "updated version" of that mail at 
http://womble.decadentplace.org.uk/readdir_r-advisory.html
has a little more detail.

I'm not sure honestly this is all worth it, since readdir() is only *allowed* 
by the spec to have thread problems, and on both Solaris and Linux I'm pretty 
sure it does not. So we don't know what systems it would have problems on - 
maybe only some crap old unix nobody cares about. Also, I don't think we 
(currently) use readdir in libdbus, only in the bus daemon, which is not 
threaded.

but anyway... I guess we don't have to give up yet, as we could instead of 
having the buf_size function, we could have an open_dir_with_size() function 
that does the open/fdopendir trick if we don't have dirfd

I've seen this compile fine under Solaris at teh Boston Summit last weekend.  Is
this still an issue with CVS D-Bus?

Bugzilla Upgrade Mass Bug Change

NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO.

  - benjsc
    fd.o Wrangler

(In reply to comment #5)
> Also, I don't think we 
> (currently) use readdir in libdbus, only in the bus daemon, which is not 
> threaded.

Well spotted: it's only in dbus-sysdeps-util-*, dbus-auth-util and dbus-message-util.

It wasn't at all obvious to me that the -util suffix means "not part of libdbus"; we could probably do with some restructuring there.

Anyway, changing _dbus_directory_get_next_file to use plain readdir(), and flagging it as explicitly not threadsafe, would make it much much easier to fix Bug #15922 as well as this one.

Here's a patch to just use readdir().

Created attachment 42126 [details] [review]
Make _dbus_directory_get_next_file use readdir, not readdir_r

This isn't thread-safe or reentrant, but it turns out we don't need
either of those properties, and readdir_r is a real pain to use correctly,
particularly in the presence of FUSE filesystems that might implement
statfs() wrong.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=8284
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=15922

I think this is worth fixing for 1.4 because of Bug #15922.

Review of attachment 42126 [details] [review]:

This looks fine!

Thanks, fixed in git for 1.4.4, 1.5.0.