On Fri, 1 Mar 2013, Ludo Brands wrote:
On 03/01/2013 12:52 PM, Sven Barth wrote:
Currently FPC allocates only one pdirent in fpopendir
(rtl/linux/ossysc.inc). Maybe it should first stat the directory and
then decide based on st_blksize how much pdirent entries to allocate
(but it should also provide a sane default, as there is the possiblity
that st_blksize is 0 for a directory).
The dirent struct on linux contains a char d_name[256]; as the last
element. The kernel returns only a null terminated string instead of the
full 256 chars. Reason why you can get many files returned in one 280
byte block. Allocating n pdirent entries for n files would be an overkill.
The glibc getdents.c source uses some heuristics to determine how many
entries will fit in a buffer. They use an average of 14 chars for the
filename.
The same source code also says in comments that the kernel limits the
number of entries returned per call but doesn't say what the limit is.
It probably depends on the underlying files system. This could explain
why programs such as ls that use a 32k buffer never see the problem (at
least I haven't found any reports).
What about just using a 32k buffer?
No problem with that as far as I am concerned.
Since the code is shared between embedded and non-embedded targets,
it might be better to have the option to specify the size of the
buffer to use.
In recursive cases, it means that Depth*BufferSize buffers will be allocated.
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
