Re: [AD] file_select_ex patch

[Chris <chris.kcat@xxxxxxxxxx>]

On Tuesday 13 September 2005 06:27 am, Grzegorz Adam Hankiewicz wrote:
> > Actually, file_select_ex takes a size parameter for the buffer,
> > so it won't overrun.
>
> True. It's still terribly bad design though, you are trusting yet
> another parameter from the user.

There's no way around it, if you're going to fill the user's buffer. Allegro 
can't know the size of user-supplied buffers itself so it has to be told, by 
the user.

> > What I tried doing in this case was create a d_box/edit/button_proc
> > dialog combo [...] It just feels like this is something the
> > function itself should've done, though.
>
> Ah. In that case, maybe it would be safer to make the function
> always operate over an internal buffer and copy the contents into
> path only when you are sure the function is going to return TRUE.
> Safe, as in it's easier to work on an internal buffer than patch
> all possible return branches, should arise the need to have more
> than one.

Maybe. But I can't say I like the idea of Allegro always having a static 
buffer MAX_PATH*6 bytes in size, and it's just more memory that's dealt with. 
Since you know the size of the user buffer, and you'll never be able to 
return more than that, why use an internal buffer that may just truncate the 
returned filename? Instead, the file selector would just not allow the 
filename to grow past the user buffer's size.