My proposal for `PATH_MAX' and friends (was: What is ``access (NULL, whatever)'' supposed to do?)

[Thomas Schwinge]

Hello!

We're still being again and again annoyed by programs that use `PATH_MAX'
unconditionally.


I propose the following: we define it in glibc.  But wait, we don't just
define it, we also try to help the programmer.  It works roughly as
follows:

To `[glibc]/include/libc-symbols.h' we add:

#v+
#define dont_use_warning(name) \
  __make_section_unallocated (".gnu.glibc-stub._dont_use_" #name) \
  link_warning (_dont_use_ ## name, \
                "warning: " #name \
                " should not be relied on in properly written code")
#v-

In `some_file.c' we have:

#v+
#include <libc-symbols.h>

int _dont_use_PATH_MAX;
dont_use_warning(PATH_MAX)
#v-

In `some_other_file.h' we have:

#v+
extern int _dont_use_PATH_MAX;
#define PATH_MAX (_dont_use_PATH_MAX = 1,
  WHATEVER_VALUE_WELL_COME_UP_WITH_DASHDASH_I_SUGGEST_35847)
#v-

It'll look somehow like this afterwards:

#v+
$ cat file.c
#include <some_other_file.h>
#include <stdio.h>

int main ()
{
  printf ("PATH_MAX = %d\n", PATH_MAX);

  return 0;
}
$ gcc -Wall bar.c
/tmp/ccQWfHe6.o: In function `main':
bar.c:(.text+0x13): warning: warning: PATH_MAX should not be relied on in 
properly written code
$ ./a.out
PATH_MAX = [ABOVE NUMBER]
#v-

What do you think about that idea?


What might be a problem is code that currently does a ``ifndef PATH_MAX''
to catch `PATH_MAX' not being defined and branches to some dynamic
allocation in that case.  But is that really a valid show-stopper?  If
dynamic allocation is possible (and already implemented!) why not use it
unconditionally then?


Regards,
 Thomas

signature.asc
Description: Digital signature