bug#40737: Segfault in arm gcc7, thumb2 builroot, with arm patch

[Andrew Gierth]

Patch attached.

-- 
Andrew.

diff --git a/libguile/lightening/lightening/arm-cpu.c b/libguile/lightening/lightening/arm-cpu.c
index 4445266af..2b4eecc29 100644
--- a/libguile/lightening/lightening/arm-cpu.c
+++ b/libguile/lightening/lightening/arm-cpu.c
@@ -230,7 +230,7 @@ encode_thumb_immediate(unsigned int v)
 return ((v & 0xff) | (1 << 12));
   /* abcdefgh  abcdefgh  */
   if (((v & 0x) >> 16) == (v & 0x) && (v & 0xff) == 0)
-return ((v & 0x00ff) | (2 << 12));
+return (((v & 0xff00) >> 8) | (2 << 12));
   /* abcdefgh abcdefgh abcdefgh abcdefgh */
   if ( (v &0xff)== ((v & 0xff00) >>  8) &&
((v &   0xff00) >> 8) == ((v &   0xff) >> 16) &&

bug#38269: SSAX incorrect handling of in CDATA

[Andrew Gierth]

The bug:

> (xml->sxml "")
$2 = (*TOP* (e ">"))

The expected result is (*TOP* (e "")).

In upstream/SSAX.scm:

; procedure+:   ssax:read-cdata-body PORT STR-HANDLER SEED
[...]
; Within a CDATA section all characters are taken at their face value,
; with only three exceptions:
[..]
;is treated as an embedded #\> character

This handling of  is contrary to the XML specification, in which
there are no special character sequences inside CDATA except newline and
the "]]>" closing tag. I have confirmed this by checking other XML
parsers. The code seems to be based on a wild misreading of another
section of the specification that does not apply here. (And
unfortunately, the W3C validation suite for XML happens not to contain
any instances of  inside CDATA.)

I believe the fix should be as simple as removing the entire (#\&) case
from the function (and fixing the test cases).

This bug seems to exist in all versions of SSAX.

-- 
Andrew.