[vlc-devel] Re: vlc: svn commit r17986 (md)

[Rémi Denis-Courmont]

Le vendredi 24 novembre 2006 10:54, Clément Stenac a écrit :
> > instead of dynamically sized arrays. And by the way, if you want
> > C89, you ought to remove all the static inlines. That's not
> > standard either (let alone C99 that is).
>
> Now, stop trying to look stupid (I'll let you choose whether you
> consider this as an insult). We don't "want C89", we don't really
> care about standard,

I know you don't - I'm only replying to Md.

> but about what the compilers of our target platforms support.

> The biggest problem that we have here is dynamically-sized stack
> arrays (and maybe also the restrict keyword).

The restrict keywords is already tested in configure. It's a non-issue.

> The other niceties of C99 are not "that" important (I mean, putting
> the variables at the top is not that hard, and if you really don't
> want, you can just enclose the snippet in a block).

It is easy for small function. It makes code painfully trickier to read 
for large functions. It's also sometime a reason for not detecting some 
bugs (particularly the for loop variant).

> For arrays, the fact is that we lived without them for a while... I
> know you'll reply that it's not an excuse and that we should try to
> do better. It would be nice to have a clear overview of where we
> perform heavy mallocing that could be done on the stack, and how we
> can solve that:

> - If there are just a few instances, it could be possible to ifdef
> code for gcc-2.95 and other non-C99 compilers

Even more intricate, hard to read and error-prone as using malloc() all 
the time.

> - For values that are always small (I guess we have some of these in
> the network code), we could just alloc on the stack the maximum size

Ugly. Overflow prone. Lots of extra checks needed.

And the "embedded" people might bother uselessly large buffers.

> - Memory pools...?

Memory pool are no solution. They still need to be freed (you merely 
bundle many free()s together), they still need locking (unless you want 
to not allow sharing it, which will be very cumbersome). Memory pools 
and alloca() cannot replace stack arrays within loops; their semantic 
is opposite there.

-- 
Rémi Denis-Courmont
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20061124/ff9e1278/attachment.sig>