How does one create a stacked file interface without having to know about the internals of the ALLEGRO_FILE format?

It seems like there needs to be a function like:

ALLEGRO_FILE *f = al_fopen("blah.txt", "r");
al_set_new_file_interface(foo);
al_fopen_f(f); // calls foo.fi_fopen_f(f)

Now the foo file interface gets passed a reference to the ALLEGRO_FILE. So basically it acts as a filter or wrapper over top of an existing file interface.

The function could return NULL if there is no reasonable implementation.

Some applications:

• file slices - overrides seeking, then passes reads/writes through

• compression - compress data on the fly

• encryption - encrypt data on the fly

Edit: removed second question.

All ALLEGRO_FILEs store the interface they were created with. If you change the current interface, opened files won't just stop working.

Which is why you can have memory files and disk files open at the same time.

The memfile addon currently uses that feature to provide its own open api call, which creates its own ALLEGRO_FILE setup with its special hooks.

I know. That's not what I'm talking about...

Look at the memfile implementation. It has a NULL fopen entry because it makes no sense. memfile doesn't open a char* filename, it opens a file handle. So it must include the internal Allegro file header to set the vtable by hand. If there was an al_fopen_f function and related hook in the interface, it wouldn't have to do that.

Edit: Although this would also require something like al_set/get_file_data() function that would return a void* pointer to attach custom user data or something similar to accomplish that.

So it would look like:

struct ALLEGRO_FILE {
  ... vtable;
  void *data;
}

static size_t memfile_fwrite(ALLEGRO_FILE *fp, const void *ptr, size_t size)
{
   ALLEGRO_FILE_MEMFILE *mf = al_get_file_data(fp);
...
}

No but it does provide what you need.

Sure a helper to play with the vtable may help. But I don't think anything more than that is required. It sounded to me like you were asking for a bunch of new api calls just to support something you can do now.

I don't think thats necessary or useful at all.

append:

It actually needs to provide a memory buffer and a length, so it can't just use an al_fopen_f method.

The al_open_memfile function would call al_fopen_f internally.

This is the principle concept: Hide the Allegro internals.

Eh I suppose. I don't really see a huge point in doing so though.