Modify ↓
Opened at 2005-12-04T10:42:46Z
Last modified at 2008-06-23T14:22:25Z
#46 new defect
Long AIM profiles get chopped
Reported by: | f0rked | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | BitlBee | Version: | devel |
Keywords: | Cc: | ||
IRC client+version: | Client-independent | Operating System: | Public server |
OS version/distro: |
Description
Long lines in AIM profiles will get chopped off if they are 'too long'.
Attachments (0)
Change History (5)
comment:1 Changed at 2006-01-28T23:08:36Z by
comment:2 Changed at 2006-01-30T13:22:22Z by
Yes, increasing the buffer size a little bit is the easy fix, but I'm looking for something better (as-in something that wastes less memory). :-)
comment:3 Changed at 2006-01-30T13:23:04Z by
Component: | OSCAR → BitlBee |
---|---|
Owner: | Jelmer Vernooij deleted |
Argh, forgot to log in...
So anyway, not really an OSCAR bug.
comment:4 Changed at 2006-01-31T17:09:59Z by
Note that it is a buffer on the stack, so the memory isn't in use for very long. It is probably better not to use fixed-size buffers in any case though.
Note: See
TracTickets for help on using
tickets.
I have experienced the problem of the entire profile text being chopped; perhaps this is what the user that posted this bug report really meant. I also found a solution to the problem I was experiencing.
The truncation was due to the fixed buffer lengths specified in
serv_got_crap' defined in protocols/nogaim.c. I simply increased the buffer lengths (for the
text' and `buf' buffers) to 8192 bytes from 1024 bytes, and then changed the parameter to do_iconv to 8192 as well. It might be better to fix this problem by not using fixed-length buffers, but this solution has worked okay so far, as I have not yet come across a profile that exceeds that length. I think that 1024 bytes is certainly too short though, so this change should probably be made if the code isn't going to be fixed to not use fixed lengths.