Re: [AD] Untranslated string: ALLEGRO_WINDOW_CLOSE_MESSAGE

[Sven Sandberg <svsa1977@xxxxxxxxxx>]

> >  - #define XWIN_DEFAULT_WINDOW_TITLE in src/x/xwin.c is never
> > translated.
>
> Right. However Xlib doesn't support anything else than ASCII so the
> translated strings would be screwed up.

OK, in that case I guess it makes more sense not to translate it.

> >  - Most drivers seem to have a field called `ascii_name'. This gets
> > translated, but is not found by misc/findtext.sh, so chances are that
> > nobody ever translates them. I collected a (pretty big) list of such
> > strings, in case some translator is interested.
>
> Where does this field get translated ?

In allegro.c, graphics.c, joystick.c, keyboard.c, mouse.c, sound.c and
timer.c (according to 'grep -rl "get_config_text.*ascii_name" src').

> In the process of filling the 'name' field ?

Yes.

> Could you upload the list anywhere ?

Sure, it's now at http://home.student.uu.se/svsa1977/tmp/drivers.txt

> > > PD: Looks like hard tabs dissappeard from a few source files...
> >
> > I also noticed that lkeybd.c is screwed up.
>
> IIRC ahack._tx doesn't require TABs, does it ?

No, but this file doesn't even seem to have a consistent width neither
of tabs nor of indentation :-) I don't mind enough to fix it, since it's
nevertheless readable with 8-space tabs.

> > With some effort, I can misinterpret 'Proceed anyway' as
> > 'Proceed running the program' rather than 'Proceed the action of
> > closing the program'. Maybe it's totally unambigous for native
> > speakers, but I think it can't hurt to say something like
> > 'Really proceed closing the program?'. OK?
>
> This message string spawned a lengthy debate some time ago, and was agreed
> upon only after a formal voting. So I don't think we can change it without
> another formal voting...

Hmm, yes, I seem to remember this. Laurence suggested 'Close anyway?'
privately, which I think is better, but it would be a pity to violate
the possibly most democratically taken design decision ever in Allegro,
so I don't mind keeping things the way they are :-)

> and remember Florida ;-)

Didn't someone refuse to let people count the votes in Florida? :-)

> > One more issue: Isn't it a security problem to feed translated
> > strings as the format parameter to sprintf()? An evil cracker
> > might add some extra "%s" in order to corrupt memory.
>
> Obviously yes, with sprintf() or usprintf(). Both should be changed into
> uszprintf() which does proper bound-checking.

I meant that with an additional "%s" in a translated string, an extra
and undefined argument will be read from the stack, which can refer
to any random place in memory. It's not related to using bound-checking
sprintfs. However:

Laurence Withers wrote (in a private message):
>>One more issue: Isn't it a security problem to feed translated
>>strings as the format parameter to sprintf()? An evil cracker
>>might add some extra "%s" in order to corrupt memory.
>
> If somebody has enough access to a system to change strings passed to
> sprintf(), surely they could be more directly malicious anyway? (eg.
> changing the executable). At least on the assumption that if you have
> permissions to change a program's internal data then you have
> permissions to change the program itself.

Where are translated strings read from under Unix? I assumed they
were open for everyone to change.

--
Sven Sandberg   svsa1977@xxxxxxxxxx   home.student.uu.se/svsa1977