Re: MAXNAMLEN vs NAME_MAX

[christos%zoulas.com@localhost (Christos Zoulas)]

On Sep 25,  1:28am, jeanyves.migeon%free.fr@localhost (Jean-Yves Migeon) wrote:
-- Subject: Re: MAXNAMLEN vs NAME_MAX

| On 25.09.2011 00:57, Christos Zoulas wrote:
| > On Sep 25, 12:40am, jeanyves.migeon%free.fr@localhost (Jean-Yves Migeon) 
wrote:
| > -- Subject: Re: MAXNAMLEN vs NAME_MAX
| >
| > |>  My vote is to bump without versioning, what's yours?
| > |
| > | Hmm, what do you want to do there? Increase NAME_MAX or decrease 
MAXNAMLEN?
| > |
| > | I would do the latter; ffs, ext2 and lfs all seem to use 255 for
| > | MAXNAMLEN. So, I cast my vote for "bump without versioning".
| >
| > If you decrease MAXNAMLEN you *must* version! Anyway we came from there,
| > and there is no reason to move backwards. The change proposed is to make
| > NAME_MAX match MAXNAMLEN without bumping.
| 
| Yup, I forgot about getdents(2) compat.
| 
| BTW, why would it be necessary to version? d_name is the last element of 
| struct dirent; I can't see how d_name content could be bigger than 256 
| (including NULL) anyway, so only those that copy d_name string with 
| MAXNAMLEN size directly (instead of using _PC_NAME_MAX, NAME_MAX or 
| strlen(3)) are in trouble, no?

Because it will create a horrible mess for anything that tries to allocate
a struct dirent and use it. Imagine having an old library with new binaries
or vice-verse.

christos