[PATCH] Reserve enough memory when storing a DC's nickname

[Lubomir I. Ivanov]

On 16 December 2012 07:54, Dirk Hohndel <dirk at hohndel.org> wrote:
> "Lubomir I. Ivanov" <neolit123 at gmail.com> writes:
>
>> On 15 December 2012 17:53, Dirk Hohndel <dirk at hohndel.org> wrote:
>>> Sorry, just a quick email from my phone; on my way to the morning dives.
>>> The function cleanedup_nickname was supposed to correctly shorten the string
>>> if necessary to fit in the number of bytes allocated. Doesn't it do that
>>> (and why?)
>>>
>>
>> actually it seems to be working, i.e. remember_dc() does receive a
>> reduced string.
>>
>> but what i've said before about the size of the "nickname" buffer in
>> set_dc_nickname() previosly was correct.
>> it has to be twice the size of the max allowed characters in:
>> gtk_entry_set_max_length(GTK_ENTRY(entry), 68);
>>
>> otherwise this call in there:
>> dive->dc.nickname =
>> cleanedup_nickname(gtk_entry_get_text(GTK_ENTRY(entry)),
>> sizeof(nickname));
>> will always discard user entered characters at the end.
>>
>> i would simply increase both stack buffers to 256 in set_dc_nickname()
>> and remember_dc() and this should make it always have space for the
>> user entered unicode string, given that gtk_entry_set_max_length()
>> sets the limit.
>>
>
> That makes sense. Pushed your change with an adjusted commit message
>

here a patch that sets both buffers to 160 chars (or 80 unichars).
that is pretty much the last paragraph of the previous email.
i've tested and it doesn't seem to ever truncate the string this way
i.e. the user entered string in the nickname dialog _is preserved_.
gtk_entry_set_max_length() should provide a sufficient limitation to
how much characters are entered by the user.

lubomir
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Make-sure-that-the-user-entered-nickname-is-never-tr.patch
Type: application/octet-stream
Size: 1530 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20121216/922d1787/attachment.obj>