[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: decodeBase64() input need not be NUL-terminated [patch]
From: |
Ken Hornstein |
Subject: |
Re: decodeBase64() input need not be NUL-terminated [patch] |
Date: |
Wed, 04 Jun 2025 14:06:04 -0400 |
>Change decodeBase64() to accept a length for the encoded string and
>not assume it is NUL-terminated.
>
>In all cases, I found the length of the encoded string was already
>available to the caller. That let me remove a strlen() in
>decodeBase64 and not add a strlen() to any call site. One call site
>even got simpler: in mhparse.c I was able to remove an apologetic
>comment.
>
>This change is part of an effort to move the nmh code base away
>from assuming C strings and towards using a length for all data.
>A comment in popsbr.c says this is a good idea.
>
>And that effort is also deep background for fixing bug #66407, inc
>long lines. The fix there is complicated by how awkward it is for
>the current code to deal with an arbitrary sequence of bytes from
>the middle of a stream.
I took a look at this and it makes sense to me. Does anyone object
if I commit it?
A larger meta-issue: I know we've had some discussion in recent times
about fixing some issue and the ball kind of just gets dropped. My
life has been complicated lately but I am hoping it will be less
complicated soon; please, if you're someone in this situation it's
not that we're ignoring you, it's more that "life is complicated
and I got distracted".
--Ken