Subject: long - 2 bugs, Pine 3.90, fixed, 1:OSF/1 & function key only, 2:MIME

From: Sharon L Kraft <[email-masked]>
Date: Thu, 13 Oct 1994 12:19:50 -0400 (EDT)

The following describes 2 bugs in Pine 3.90 (and earlier in the second case)
and the output of "diff" for their fixes.

The first bug only applies to OSF/1 (as far as I know) for Pine in function 
key mode which I tend to use most of the time, since I prefer one stroke
commands to control key commands and also since the VT keyboards have a bunch
of extra keys that can be bound to some of those hidden functions in
Pine and Pico (my favorite is the set right fill column to change the
justification column, but that's another story).

Anyway, this bug appears when some function keys are used for the answers
to questions or second level command responses, such as how to apply
the selected messages.  In fact, some of the keypad keys, especially
F3 and F4 (PF3 & FP4 on VT's) get recognized by some library functions as
being "alphabetic", so their associated command doesn't get executed at all,
either beeps or has no function as a result.  NOTE again, I've only 
encounterd this on our OSF/1 machines.  The underlying fault is that the
C library query functions, tolower and isalpha have undefined results when
the value passed is not "ascii" (according to the C standard definitions of
these functions). And they recognize PF3 & PF4 as alphabetic, when of course,
they are not.  Modifying 2 lines in status.c to check first with the
builtin function isascii fixed the bug for all the cases I've found.
The diff for this fix:

# diff status.c status.c.original
665c665
<         if(isascii(ch)) ch = isupper(ch) ? tolower(ch) : ch;
---
>         ch = isupper(ch) ? tolower(ch) : ch;
668,669c668
<          && ((isascii(ch) && isalpha(ch) && !strchr("YyNn", ch)) /* y & 
n :
<                                                                    
special cas
e */
---
>          && ((isalpha(ch) && !strchr("YyNn", ch)) /* y & n : special 
case */

The second bug appears much less likely to occur, and has been in Pine
since at least 3.85, has to do with binary attachments.  Note this was
not a bug generated locally, but as a result of mail that was received
here and the mail generation of a remote site. (elm handles this mail
just fine, which is why I figure it to be a pine bug, though I don't
know how the actual RFC822 specification would describe it.)
The bug appears with a very specific set of circumstances and causes
pine to abort.

In dealing with a multipart message, where the Boundary specification
includes blanks and is not enclosed in quotes, if the message is forwarded,
pine aborts.  Here's an example excerpted from a message that aborts pine
in that case:
---------

.
.
.
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=-- next item ----
Status: RO
X-Status:

This is the preamble of an RFC-1341 encoded, mixed message.

---- next item ----
Content-Type: Text/Plain

Attached WP file encoded in Base64.  -- Maura

---- next item ----
Content-Type: Application/X-Lotus-Notes
Content-Transfer-Encoding: Base64
Content-Description: THAI

/1dQQ8ITAAABCgABAAAAAPv/BQAyAH4HAAAGABAAAABCAAAA//9WAAAAUgAAAP//
fAYAAKgAAAD//1oAAAAkBwAAACN8AHcAAAABAAAAAAAAAFwE//+RADcAdwBDADMA
LAEBAAAAAdEdWAJ3ADYbfRJgCQAAABAAUHMAGjfXETsAWAJQ/v7+/v7+/v/+////
/v///v//////////////////////////AQEiAOIAuALKAiwDzAP2A8oE2AT/////
//94Bv///////14AMwBCAEMAmwBlAL0ApQAzAE0ATQBlAKgAMwBDADMANwBlAGUA
ZQBlAGUAZQBlAGUAZQBlADcANwCoAKgAqABjAMcAmwCKAI8AowCNAH0AowClAE0A

.
.
.

etc.

----------------

And the fix is to parse boundary attributes as a "phrase" instead of a 
"word", as follows:

tc>pwd
/mnt/d0g/slk/pine3.90/imap/ANSI/c-client
tc>diff rfc822.c rfc822.c.original
713,728d712
<
<           if(!strcmp(param->attribute,"BOUNDARY")) {  /* BOUNDARY 
attrib may
<                                  have unquoted string for param.  
Others ?? */
<           if ((*name != '=') || /* missing value is a no-no too  */
<               !(name = rfc822_parse_phrase ((s = ++name))))
<             param->value = cpystr ("UNKNOWN");
<           else {                /* good, have equals sign */
<             c = *name;          /* remember delimiter */
<             *name = '\0';       /* tie off value */
<             rfc822_skipws (&s); /* skip leading value whitespace */
<             if (*s) param->value = rfc822_cpy (s);
<             *name = c;          /* restore delimiter */
<             rfc822_skipws (&name);
<           }
<           }             /* for BOUNDARY attrib */
<           else {
740d723
<           }             /* for other attribs */
tc>cd

------------------------

And that's all.

				- Sharon Kraft
				  Sys Mgr, Univ of N.H.

 __________________________________________________________________________
|  "How can organized large-scale structures function when the atoms that  |
|   make them up are swimming in an ocean of chaos?  How can stable        |
|   patterns of behavior arise in a fundamentally chaotic world? "         |
|                                                                          |
|  "does Chaos rule the Cosmos?" - Ian Stewart  (1992, Univ. of Warwick)   |
|                                                                          |
|          [email-masked]   [email-masked]                      |
|            [email-masked]    [email-masked]                      |
|__________________________________________________________________________|