> > Hmm - I'd like it better, if it would read only P?M and use ppmtools to
> > convert any other format as required.

> I want to have reading some different file-formats and not only one.
> That's why I hack the file-target.

This is a misconception IMHO.

The idea of the ppmtools is to finally put an end to reinventing the picture
loading and saving wheel for every program/lib/whatever.

As long as you can load/save ppms (which is trivial) you can load/save any
format by just piping the output through the appropriate ppmtools.

LibGGI is intended to be lightweight, and I'd like to keep it this way.

So what you should do is to use ppmtools to convert other filetypes to/from
ppm on the fly.

This saves lots of source (ever looked at the tiff spec ? about 300 pages
...) and legal problems as well (GIF ...).

> > Why don't you just use a file-stream and leave buffering to the libc ?
> You mean, I should use FILE * from the libc?

Yes. We use it anyway, so no additional space (runtime-link-wise) required 
for that one, and it usually has a well optimized buffering implementation
that is seekable and whatever.

> > > +void _ggi_file_read_word(ggi_visual *vis, int *val)
> > > +{
> > > +#ifdef GGI_LITTLE_ENDIAN
> > > + _ggi_file_read_byte(vis, (int*)(val)   );
> > > + _ggi_file_read_byte(vis, (int*)(val+1) );
> > > +#else
> > > + _ggi_file_read_byte(vis, (int*)(val+1) );
> > > + _ggi_file_read_byte(vis, (int*)(val)   );
> > > +#endif
> > > +}
> > Uh - please don't do this. There is sick stuff like PDP byte ordering and
> Maybe, when I use the FILE * from the libc, that then bug is fixed.

The main bug is here:

> > > +void _ggi_file_read_word(ggi_visual *vis, int *val)
> > > +{
> > > + _ggi_file_read_byte(vis, (int*)(val)   );
> > > + _ggi_file_read_byte(vis, (int*)(val+1) );
> > > +}

val is a pointer to an integer. That means that val+1 will be the pointer to
the next integer (i.e. 4 bytes higher on x86). What you are probably trying 
to achieve is to:

+       _ggi_file_read_byte(vis, (int*)((char *)val)   );
+       _ggi_file_read_byte(vis, (int*)((char *)val+1) );

Which would place the second byte one byte above the first one to form a
little endian word.

> > > +/* FIXME: compiler fails on using this with: "sizeof applied to an incomplete 
>type" */
> > > +#define NUM_FILE_TYPES   (sizeof(file_type) / sizeof(struct file_type_op_t))
> > You need to have a complete prototype for file_type_op_t included before you
> > can use sizeof.

> I see. But maybe is file_type, not file_type_op_t, no?

That may be. Though the statement only makes sense to me, if file_type is
an array of type file_type_op_t - right ?

In that case if file_type_op_t is not completely defined, file_type can't be
completely either. There is one more possibility:

If file_type is an array, it must be declared _with_size_ before the define
(or rather its use). Stuff like export bla[] won't work.

CU, Andy

-- 
= Andreas Beck                    |  Email :  <[EMAIL PROTECTED]> =

Reply via email to