On Sunday 12 August 2007, Samuel Thibault wrote: > Mike Frysinger, le Sat 11 Aug 2007 22:48:43 -0400, a écrit : > > i think everything should use termios functions. these are a POSIX > > standard and the underlying hacks and what not are the libc's problem, > > not util-linux. > > Well, I do agree with that, but doing the switch blindly might bring > breakage: we don't necessarily know which hacks already done in libc > then needs to be dropped. The duplication that would remain can be a > problem. That's why I preferred to keep a conservative approach for this > patch. But we can indeed move forward of course. i didnt do a line by line review of the termios code, but it's not my call as to which way to go (transition period or just do it and be done) ... i of course prefer the latter :) > > > util-linux-2.13~rc3/fdisk/fdiskbsdlabel.c > > > util-linux-2.13~rc3/misc-utils/namei.c > > > util-linux-2.13~rc3/sys-utils/rdev.c > > > +#ifndef MAXPATHLEN > > > +#define MAXPATHLEN 4096 > > > +#endif > > > > everything should use the POSIX PATH_MAX define from limits.h and if that > > doesnt exist, your system sucks and needs to be fixed, not util-linux > > Not, my system doesn't suck, it just doesn't have such fixed hard limit, > and thsu, as POSIX allows, doesn't have the macro that would express it. > > The above patch is just to avoid the risky exercice which is rewriting > of code into length-unlimited loop. But MAXPATHLEN & such should really > used as "oops, the system is limited to this", not as "how much memory > should I allocate for my path?". Some system may very well define > MAXPATHLEN to MAXINT... ah, i missed the statement in POSIX where these defines may be omitted ... may be worthwhile i think to go through the code and just get rid of usage of all of these _MAX defines by querying the actual limits at runtime ... -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
