Bruce,
I pulled down the latest string.test from gitweb and made a patch for
autogen-5.12. For some reason the patch below wouldn't apply. The 'make
check' pass when building with your RPM .spec file for autogen-5.12
passed without a problem.
Did the Guile team really decide to break backward compatibility (wrt
removing the high order bit of characters) like that or is it just a bug
with Guile 2.0.2?
Leo
On 11/24/2011 10:18 AM, Bruce Korb wrote:
> Hi Leo,
>
> Thank you for the report. I do my development on openSuSE 11.4, not having
> upgraded yet. I'll upgrade in a week or two. Meanwhile,
>
> On Wed, Nov 23, 2011 at 2:08 PM, Leo Davis<lda...@speechfxinc.com> wrote:
>> Hello,
>>
>> I'm getting a failure on string.test with autogen-5.13.0pre4, autogen-5.12,
>> and autogen-5.11.9 on openSUSE 12.1 x86_64. I'm using the source RPM files
>> to build the released versions, BTW. I've attached the entire contents of
>> the FAILURES directory for autogen-5.13.0pre4.
> I dug into this. It seems your version of Guile presumes that it is okay to
> silently remove the high-order bit from a string of characters because
> everybody knows that valid characters are in the range of 0x0a through 0x7E.
> Guile is being "helpful". When I started there was no notion of an
> array of bytes,
> now I must change all my string references to the array-of-bytes interfaces.
>
> *sigh*.
>
> Please apply the following patch to the agen5/test/string.test script.
> If this also fails, then replace the "177" with "176" (the '~' character).
> That *must* work.
>
> Your result means that it is no longer possible to reliably generate arbitrary
> arrays of bytes with autogen. Not until I figure out how to use the Guile
> array-of-bytes stuff anyway....
>
> Regards, Bruce
>
>
>
> diff --git a/agen5/test/string.test b/agen5/test/string.test
> index 0439e6c..438dbd3 100755
> --- a/agen5/test/string.test
> +++ b/agen5/test/string.test
> @@ -82,7 +82,8 @@ CASE (suffix) =][=
> =]
> _EOF_
>
> -test -z "$LINENO"&& LINENO=85
> +test -z "$LINENO"&& LINENO=`
> + grep -n FIND-THIS-LINE-NUMBER $0 | sed 's/:.*//'` # close enough
> printf '\nchar zTestFile[] = "%s";\n#line %s\n' \
> ${testname}.raw `expr $LINENO + 4`>&4
>
> @@ -94,13 +95,14 @@ char zExpect[] = "'\f\r\b\v\t\a\n\n"
> "\"Wow!\" This'll be \\hard\\'\n"
> "#endif /* .\n"
> "and it'll be a \"hassle\"."
> - "\001\002\003\377\n'";
> + "\001\002\003\177\n'";
> #define expectSize ((int)(sizeof(zExpect) - 1))
> int checkStr( char* pz, char const* pzWhat );
> int checkStr( char* pz, char const* pzWhat )
> {
> static char const zNotMatch[] =
> "%s generated string mismatches at offset %d of %d\n"
> + "Expected char: 0x%02X saw char: 0x%02X\n"
> "Expected string:\n==>%s<==\n\n"
> "Generated string:\n-->%s<--\n\n";
>
> @@ -116,8 +118,8 @@ int checkStr( char* pz, char const* pzWhat )
>
> for (ix = 0; ix< expectSize; ix++) {
> if (*(pzE++) != *(pzR++)) {
> - fprintf( stderr, zNotMatch, pzWhat, ix, expectSize,
> - zExpect, pz );
> + fprintf(stderr, zNotMatch, pzWhat, ix, expectSize,
> + (unsigned char)pzE[-1], (unsigned char)pzR[-1],
> zExpect, pz);
> return 1;
> }
> }
> @@ -217,7 +219,7 @@ string =
> \#endif /* .
> '
> "and it'll be a \"hassle\"."
> - "\001\x02\X03\377\n'";
> + "\001\x02\X03\177\n'";
>
> _EOF_
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Autogen-users mailing list
Autogen-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/autogen-users
