Re: [AD] pack_ungetc

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


> Should we add it to the API ? It of course has got the limitation
> described in the comment, but pack_fseek() also has got its own
> limitations with regard to fseek().

I think that's mandatory if we change pack_feof() to conform with ANSI C
feof().

Currently pack_feof() returns TRUE if read or write operation finish exactly
at the end of the file (without encountering an EOF), contrary to feof().
This behaviour has a big advantage (see tools/plugins/datfont.c): when
reading a file with a strong format specification, you generally know how
many bytes to read before performing the operation, so you read the file
chunk by chunk of a certain size and the size of the file is a multiple of
that of the chunks. Now at the end of the core file format may lie an
additional optional chunk.

With the current implementation, a mere pack_feof() at this point tells you
whether the additional optional chunk is present. If so, you can directly
read it sub-chunk by sub-chunk.

If we choose ANSI C conformity, this won't work anymore. You will have to
use pack_getc() and test its return value against EOF. But then a
pack_ungetc() is much needed if you want to be able to read sub-chunk by
sub-chunk.

But first and foremost: do we fix pack_feof() ? The main drawback is the one
described above. The main advantage (besides conformity) is to simplify the
code in src/file.c

--
Eric Botcazou
ebotcazou@xxxxxxxxxx



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/