walt wrote:
Well, I fixed it, sorta but not really. Take a look at uulib/uunconc.c
line 476:
/* suspicious = 1;we're careful here REMOVED 0.4.15 __FP__ */
The HISTORY file says this about version 0.4.15:
- in previous versions, I have very much relaxed the checking for uudecoded
lines (v
On 08/13/2009 08:41 AM, Paul Crawford (at UoD) wrote:
Per Hedeland wrote:
The decode-for-viewing is in pan/usenet-utils/mime-utils.cc (relies
heavily on gmime), decode-for-saving (or maybe it's actually
decode-after-saving) seems to be in the uulib directory (driven by
pan/tasks/decoder.cc).
T
Per Hedeland wrote:
The decode-for-viewing is in pan/usenet-utils/mime-utils.cc (relies
heavily on gmime), decode-for-saving (or maybe it's actually
decode-after-saving) seems to be in the uulib directory (driven by
pan/tasks/decoder.cc).
Thanks, that is useful to know and I can take a look lat
On 08/13/2009 06:50 AM, Rhialto wrote:
On Wed 12 Aug 2009 at 20:11:47 -0700, walt wrote:
Now, that last line begins with 'E', so uudeview figures that this line
of code should contain (69-32)*4/3 characters, which is 49.3. It then
reads the next 49 chars from that line and proceeds to uudecode
On Wed 12 Aug 2009 at 20:11:47 -0700, walt wrote:
> Now, that last line begins with 'E', so uudeview figures that this line
> of code should contain (69-32)*4/3 characters, which is 49.3. It then
> reads the next 49 chars from that line and proceeds to uudecode them,
> even though it produces garb
Paul Crawford wrote:
>
>Per Hedeland wrote:
>> Pan's decode-for-viewing is completely separate from the
>> decode-for-saving - the former uses gmime stuff (I fixed some bugs with
>> the opposite problem, i.e. saving worked but viewing didn't, in the
>> past).
>
>Can you tell me where in the code e
