Re: [AD] path and fshooks

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


On Sat March 21 2009, Elias Pschernig wrote:
> I'm wondering if
>
> bool al_getcwd(size_t len, char *buf)
> int32_t al_readdir(ALLEGRO_FS_ENTRY *dir, size_t size, char *name)
> bool al_get_entry_name(ALLEGRO_FS_ENTRY *fp, size_t size, char *buf)
>
> should be
>
> ALLEGRO_PATH *al_getcwd(void)
> ALLEGRO_FS_ENTRY *al_readdir(ALLEGRO_FS_ENTRY *dir)
> ALLEGRO_PATH *al_get_entry_name(ALLEGRO_FS_ENTRY *fp)
>
> ?
>
> For al_getcwd, the reason would be that you don't have to mess with
> buffer size limitations yourself. I know we said we don't want to use
> ALLEGRO_USTR in the API of functions which are not related to strings -
> but ALLEGRO_PATH seems to be ideal for al_getcwd, it does return a path
> after all.
>
> In the case of al_readdir, we already discussed the problem once that on
> some Unix systems, filenames can have an unknown encoding. By giving
> users an ALLEGRO_FS_ENTRY instead of a filename, things would always
> keep working as the filename itself isn't needed to do something with
> the file.
>
> For al_get_entry_name, again ALLEGRO_PATH seems ideal. In addition to
> the advantages like with al_getcwd, it removes any ambiguity as to
> whether only the filename portion or the whole path is returned (the
> user can choose themselves what they prefer). And since ALLEGRO_PATH is
> always encoded in UTF-8 a string returned from it can safely be passed
> to al_textprintf or any other Allegro functions.


This is the kind of thing I really wanted to do, but I thought people would frown on the OO Qt like interface I was starting to build, so I left some of the nicer things out.


I vote a resounding yes for all of those changes.


> --
> Elias Pschernig <elias@xxxxxxxxxx>
>




--
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx



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