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
_______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
