[physfs] Replace malloc/strcpy by strdup

Christoph Nelles evilazrael at evilazrael.de
Thu Sep 30 05:20:57 EDT 2010

On Thu, 30 Sep 2010 09:04:36 +0200, Tolga Dalman
<tolga.dalman at googlemail.com> wrote:
> Hash: SHA1
> On 09/29/10 18:59, Christoph Nelles wrote:
>> Am 29.09.2010 17:58, schrieb Tolga Dalman:
>>> Perhaps, it might be an idea to get rid of dynamically allocated
>>> path strings, and use arrays instead ? This might vastly improve
>>> performance at cost of memory, I suspect.
>> That is a good idea, but to support old C standards resp. compilers you
>> have to declare them at the beginning of the blocks, probably wasting
>> memory if unneeded. A problem might be maximum length of paths. Systems
>> have a maximum path length MAX_PATH (or PATH_MAX?) and this might be
>> exceeded by virtual paths with utf-8 characters in it. So you would
>> to limit it or stick with dynamically allocated memory.
> You are talking about variable length arrays ? I.e:
>   struct S {
>     /* other variables */
>     char buf[];
>   };
> This is also possible of course, but also prone to programming
> errors to my experience. I was rather talking about stack arrays of
> fixed size.

Then you didn't understand me. 

> Most operating systems have a limit on the maximum path length anyway
> AFAIK. PATH_MAX is at least 255 according to POSIX and 1023 according
> to SUSv2. On modern Linux this limit is at 4096 bytes, but I don't know
> about other OSes.

Yes. But Physfs has no maximum file name length. And even if you take a
system limit you would have to multiply the string length as Physfs allows
UTF-8 encoded file names which can be much longer. 

> Using stack arrays instead of heap-allocated memory is often worth the
> memory waste due to better alignment, no indirect calls, less memory
> fragmentation etc.
> However, without a proper PhysFS benchmark, we can just speculate about
> any numbers.

Write your own one. Some nice portable benchmark will be appreciated. 
Do some things, use a profiler, look for the worst stuff, tell us/me about
your findings. 

I postulate that the cost for this memory allocation is neglectable in
comparison to the cost of the real I/O. So, i'm out of this discussion.
Nether the less, a good benchmark would be interesting.

Christoph Nelles

E-Mail    : evilazrael at evilazrael.de
Jabber    : eazrael at evilazrael.net      ICQ       : 78819723

PGP-Key   : ID 0x424FB55B on subkeys.pgp.net
            or http://evilazrael.net/pgp.txt

More information about the physfs mailing list