Re: [Nmh-workers] fgets bug in mhbuildsbr.c

[David E. West]

Josh,

Sorry about that.  Yeah  I messed up when sending the first  message.  I sent a
second email with the attachment  encoded correctly.  I'll attach the test file
to this email for you.  It should be 195 characters long and its MD5 is:
7a093565d1474332174bd6e884429d51. 

(The first message  messed up because I was reling  on the automimeproc setting
and had  only installed my patched mhbuild  into "~/usr/local/bin".  Apparently
when  using the auto  feature, nmh  didn't check  my "$path"  and used  the old
unpatched version in "/usr/local/bin".  I  fixed this by explicitly pointing to
my version  using "buildmimeproc".   Its easier to  shoot yourself in  the foot
with nhm, but  I think the extra flexability and  transparancy of its operation
outways that aspect of it.) 

Talk to you later,

David E. West

> > I  patched  my version  of  mhbuildsbr.c  by adding  a  wrapper  to fgets
> > th at determines the  proper number of  characters read in.   Then I
> > changed  the for loop to  make use of this information  instead of simply
> > looking  for the first 0x00 character.  This is probably an  inefficient
> > solution.  My guess is that >  a better solution  would be to  make use  of
> > fread instead,  and do all  the line detection stuff manually.
> 
> > I've attached my patch to this email as well.
> 
> David,
> 
> I'm trying to reproduce this, but this message is pretty messed up.  The
> zip file you've included has no NULLs and is only 6 bytes long.  Have you
> been bitten by your own bug?
> 
> It seems when you ran mhbuild over this message, it mangled your example.
> I'm trying to reproduce this bug, but I'm not having any luck.
> 
> -- 
>     JB

foo.zip
Description: Zip archive