[rrd-developers] RFC: [PATCH 0/3] Portability by avoiding PATH_MAX

[Svante Signell]

Hello,

I'm working on porting packages to GNU/Hurd under Debian and stumbled on
this package. It seems that many interesting packages, like lm-sensors
and flowscan, build-depends on rrdtool/librrd-dev/librrd2-dev.

The current version of rrdtool, 1.4.8, has a lot of PATH_MAX usage. The
problem with PATH_MAX is that it is not defined for GNU/Hurd. This
causes build failures for this architecture. Attached in the following
three emails are patches using dynamic string length allocation instead
of fixed as PATH_MAX does.

For patches 1 and 2 a configure check is needed to make sure
POSIX.1-2008 is supported. I can provide modified code using #ifdef
constructs. For now I have chosen not to do that, since it clutters the
code a lot. This is of course depending on your choice, if systems not
conforming to POSIX.1-2008 (POSIX.1-2001) have to be supported or not.  

Patch 3 is more tricky, since the struct listen_socket_s member addr is
now dynamically allocated. In the patch there are a lot of //FIXME
entries that have to be resolved. As a (partial) verification the daemon
rrdcached is now valgrind clean. There are still open issues with that
patch to discuss, a swell as the other two.

[PATCH 1/3] rrd_client.c: modified getpath() to use realpath(path, NULL)
instead of realpath(path, resolved_path).

[PATCH 2/3] rrd_daemon.c: modified get_abs_path() to avoid PATH_MAX,
modified journal_new_file() likewise,
modified journal_init() likewise
modified read_options() cases 'b' and 'j' to use realpath(path, NULL)

[PATCH 3/3] rrd_daemon.c: modified struct listen_socket_s to use
variable length addr field