Re: [AD] filename encoding again |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: Coordination of admins/developers of the game programming library Allegro <alleg-developers@xxxxxxxxxx>
- Subject: Re: [AD] filename encoding again
- From: Elias Pschernig <elias@xxxxxxxxxx>
- Date: Thu, 06 Dec 2007 18:23:26 +0100
On Tue, 2007-12-04 at 15:19 +0100, Elias Pschernig wrote:
> On Dec 4, 2007 4:14 AM, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> > On Aug 5, 2007 5:21 AM, Elias Pschernig <elias@xxxxxxxxxx> wrote:
> > > I also renamed file_encoding to filename_encoding.
> > >
> > The recent patch compiles fine under MSVC 8. However, the old function
> > names made it in the 4.2.2 DLL, so they need to stay for binary
> > compatibility. They probably don't need to be marked as deprecated
> > since they never officially were public.
>
> Ah, of course. Guess I'll just undo the renaming, set_file_encoding
> was probably good enough.
Ok, I added them as deprecated functions after all, as the old name
really is wrong.
> > Also, they needed to be added to documentation. I suppose it should go
> > under the File section. And set_uformat description probably needs to
> > change, namely "This will affect all parts of Allegro, wherever you
> > see a function that returns a char *, or takes a char * as a
> > parameter" since that's not true regarding filename routines, correct?
> >
>
> Indeed, as those instead should use set_file[name]_encoding.
All strings we return or expect to the user are still in the set_uformat
format, if I understand the code correctly - so no update needed there.
And I didn't add documentation for the set/get_filename_encoding, as I
can't figure out an example where you would use them - so far I had:
"Allegro automatically detects the correct file encoding. This function
allows you to change it to something else."
Which sounds a bit stupid, why would I ever want to use an incorrect
encoding?
--
Elias Pschernig <elias@xxxxxxxxxx>