What does everyone think is a realistic path size limit.
So for a fully qualified name or full volume/file/path I have set to 8192 bytes, which I can't see being a problem but has anybody else come across any problems?
On a related note, has anybody got a good file path parser I could peek at!!
Daryl.
Path size limit
-
Schol-R-LEA
Re:Path size limit
In keeping with the 'Zero-One-Infinity'[sup]1[/sup] rule, the best path size limit is no limit at all. This is probably not practical, but dynamic sizing probably is, and would have much the same effect.
That having been said, an 8K path buffer probably will suffice, and it fits the 'Power-of-two' correllary[sup]2[/sup] of the rule.
1. The 'Zero, One or Infinity Rule' is a programming guideline that states that the only reasonable limitations on the sizes of objects in a programmed system are zero (they aren't allowed), one (you can have one of them - consider the Singleton design pattern for more enlightenment), or an unlimited number of them (where 'unlimited' means 'up to the maximum capacity of the system').
2. There are two correllaries to the 'Zero-One-Infinity' rule. The 'Size Follows Function' correllary states that if a fixed limit must be placed, it should be one that is derived from the structure of the object(s) in question. The 'Powers of Two' correllary states that if you absolutely must impose an arbitrary fixed limit that isn't mandated by the structure of the object, you should use one that is either a power of two (4, 8, 16, 32, etc.) or one less than such a power (7, 15, 31, etc.), if for no better reason than that it will seem less arbitrary later on to those maintaining the code; it further states that even powers of two are preferred, and powers of two where the exponent is itself a power of two are best of all.
That having been said, an 8K path buffer probably will suffice, and it fits the 'Power-of-two' correllary[sup]2[/sup] of the rule.
1. The 'Zero, One or Infinity Rule' is a programming guideline that states that the only reasonable limitations on the sizes of objects in a programmed system are zero (they aren't allowed), one (you can have one of them - consider the Singleton design pattern for more enlightenment), or an unlimited number of them (where 'unlimited' means 'up to the maximum capacity of the system').
2. There are two correllaries to the 'Zero-One-Infinity' rule. The 'Size Follows Function' correllary states that if a fixed limit must be placed, it should be one that is derived from the structure of the object(s) in question. The 'Powers of Two' correllary states that if you absolutely must impose an arbitrary fixed limit that isn't mandated by the structure of the object, you should use one that is either a power of two (4, 8, 16, 32, etc.) or one less than such a power (7, 15, 31, etc.), if for no better reason than that it will seem less arbitrary later on to those maintaining the code; it further states that even powers of two are preferred, and powers of two where the exponent is itself a power of two are best of all.
-
DarylD
Re:Path size limit
To be honest, the way it works is that the parsing code allocates a lump of malloc memory for internal use so I could see it as high as I want but that seems silly.
A bigger worry is the stack on processes to hold it during a call, but I guess that is a process problem not a kernel one!
Funky rules them Schol-R-Lea, I will remember them and divulge whenever necessary!!
Actually, thinking about it, a parser should be a doddle, shouldn't it??
A bigger worry is the stack on processes to hold it during a call, but I guess that is a process problem not a kernel one!
Funky rules them Schol-R-Lea, I will remember them and divulge whenever necessary!!
Actually, thinking about it, a parser should be a doddle, shouldn't it??