#15630 [Opn]: imap_utf7_decode appears to be broken

ID: 15630 Updated by: kalowsky@php.net Reported By: robert.marchand@umontreal.ca Status: Open Bug Type: IMAP related Operating System: SGI Irix 6.5 PHP Version: 4.2.2 New Comment: re-applied patch for SGI. Previous Comments: ------------------------------------------------------------------------ [2002-09-09 15:22:47] robert.marchand@umontreal.ca Hi, the fix for the SGI compiler has not made it in 4.2.3. According to the cvs repository, php_imap.c 1.112.2.3 has it but not the version 1.112.2.4. Bye. ------------------------------------------------------------------------ [2002-09-05 15:50:46] gamid@isayev.net Are you going to fix this bug in PHP 4.2.3? ------------------------------------------------------------------------ [2002-08-14 16:56:31] kalowsky@php.net I've commited the SGI compiler patch to the CVS head. I have yet to see any real conclusion though on the utf7_decode() issue, and I really would not prefer to break BC. If there is some kind of agreement upon all whom this bug effects I'm open to it. ------------------------------------------------------------------------ [2002-08-14 16:16:26] spc@sgi.com The patch added by Robert Marchand corrects a deficiency in the original code. The statement *outp++ |= outp[1] >> 2; in the ext/imap/php_imap.c file is clearly non-standard C. This means that the result is *compiler*-dependent, and no compiler can be considered "wrong". The C standard says that the order in which operands of an assignment operator are evaluated is undefined. In other words, it is equally correct for a compiler to produce code equivalent to temp = outp[1] >> 2; *outp++ |= temp; or to produce code equivalent to temp = outp; outp++; *temp |= outp[1] >> 2; Since these are not equivalent bits of code, the *source code* is wrong, not the compiler. Robert's patch suggested on 13 August corrects this non-standard source code. ------------------------------------------------------------------------ [2002-08-13 13:29:37] robert.marchand@umontreal.ca Hi, I've found the culprit in regards to the SGI problem. It is related to auto-increment operator and complex assignment. This doesn't work on SGI: *outp++ |= outp[1] >> 2; Here is my patch that correct the two function on SGI with the SGI Compiler (MIPSPRO): --- php_imap.c.nowarn Tue Jul 30 10:04:24 2002 +++ php_imap.c Tue Aug 13 11:44:50 2002 @@ -2187,6 +2187,7 @@ zval **arg; const unsigned char *in, *inp, *endp; unsigned char *out, *outp; + unsigned char c; int inlen, outlen; enum { ST_NORMAL, /* printable text */ @@ -2289,13 +2290,15 @@ break; case ST_DECODE1: outp[1] = UNB64(*inp); - *outp++ |= outp[1] >> 4; + c = outp[1] >> 4; + *outp++ |= c; *outp <<= 4; state = ST_DECODE2; break; case ST_DECODE2: outp[1] = UNB64(*inp); - *outp++ |= outp[1] >> 2; + c = outp[1] >> 2; + *outp++ |= c; *outp <<= 6; state = ST_DECODE3; break; @@ -2329,6 +2332,7 @@ zval **arg; const unsigned char *in, *inp, *endp; unsigned char *out, *outp; + unsigned char c; int inlen, outlen; enum { ST_NORMAL, /* printable text */ @@ -2399,7 +2403,8 @@ } else if (inp == endp || !SPECIAL(*inp)) { /* flush overflow and terminate region */ if (state != ST_ENCODE0) { - *outp++ = B64(*outp); + c = B64(*outp); + *outp++ = c; } *outp++ = '-'; state = ST_NORMAL; @@ -2412,12 +2417,14 @@ state = ST_ENCODE1; break; case ST_ENCODE1: - *outp++ = B64(*outp | *inp >> 4); + c = B64(*outp | *inp >> 4); + *outp++ = c; *outp = *inp++ << 2; state = ST_ENCODE2; break; case ST_ENCODE2: - *outp++ = B64(*outp | *inp >> 6); + c = B64(*outp | *inp >> 6); + *outp++ = c; *outp++ = B64(*inp++); state = ST_ENCODE0; case ST_NORMAL: This patch was applied to the original php_imap.c (4.2.2) but it can also be applied to the new version from Gamid Isayev. Thanks. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/15630 -- Edit this bug report at http://bugs.php.net/?id=15630&edit=1