This is the mail archive of the
glibc-bugs@sources.redhat.com
mailing list for the glibc project.
[Bug manual/266] New: l64a encoding example in manual incorrect
- From: "julian dot graham at aya dot yale dot edu" <sourceware-bugzilla at sources dot redhat dot com>
- To: glibc-bugs at sources dot redhat dot com
- Date: 14 Jul 2004 01:18:50 -0000
- Subject: [Bug manual/266] New: l64a encoding example in manual incorrect
- Reply-to: sourceware-bugzilla at sources dot redhat dot com
The encode() function that's provided in the glibc manual for converting a
string of characters to pseudo-base64 encoding is very helpful, but it's not
quite correct. It assumes that l64a will always return a string of length 6,
when in fact l64a can return shorter strings on perfectly valid inputs. As it
stands, if you use the function as printed on arbitrary data, you may get back a
surprisingly short string, since one of the mempcpys can insert a terminating
null when it tries to copy a shorter-than-6 string from l64a. The fix would be
to replace each call to l64a and mempcpy with something like:
char *foo = l64a(htonl(input));
int foo_len = strlen(foo);
cp = mempcpy(cp, foo, foo_len);
cp = mempcpy(cp, "......", 6 - foo_len);
...since padding with dots plays nicely with the encoding.
Let me know if you'd like me to provide a full re-write.
--
Summary: l64a encoding example in manual incorrect
Product: glibc
Version: 2.3.3
Status: NEW
Severity: minor
Priority: P2
Component: manual
AssignedTo: roland at gnu dot org
ReportedBy: julian dot graham at aya dot yale dot edu
CC: glibc-bugs at sources dot redhat dot com
http://sources.redhat.com/bugzilla/show_bug.cgi?id=266
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.