[Qemu-devel] Use of PATH_MAX

[Ian Jackson]

There are a couple of places where we use PATH_MAX.  I don't think
this is right.  PATH_MAX is a #define specified by POSIX, SuSv3 etc.
But it isn't guaranteed to be defined or necessarily very useful.

In particular, it may be defined to a very large value (larger than a
practical static buffer).  Or on systems where the maximum pathname
length varies (for example, it depends on the underlying filesystem)
it may be not defined at all and applications which really need to
know are supposed to use pathconf.

I think it would be better to invent a new name for the maximum path
length supported by qemu's statically-sized buffers.  This would
replace both the uses of PATH_MAX (in block.c, linux-user/path.c, and
block-vvfat.c) but also direct use of (eg) 1024 in many places.

Before I submit a patch, which will necessarily be very large (and
before I store up future conflicts by pushing similar patches to the
various Xen branches) I thought I would ask here:
  * Do we agree that this is a good idea ?
  * What should the new name be ?  I propose  QEMU_PATH_MAX
    as a nice simple change.

The rune
  egrep -R 'char.*\[[0-9]' .
gives a list of possible numerically-defined static buffers.  Many of
these aren't filenames but some of them are.  Nearly all of the hits
from
  egrep -R 'char.*1024' .
are ripe for changing, so I would start with submitting a patch to
change those (and existing uses of PATH_MAX).

I'd appreciate a go-ahead from a qemu cvs committer before I prepare
(and locally commit) this blanket change.

Thanks,
Ian.