autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue with AS_TR_CPP, m4_cr_all and EBCDIC codeset


From: Steve Goetze
Subject: Re: Issue with AS_TR_CPP, m4_cr_all and EBCDIC codeset
Date: Mon, 29 Mar 2010 12:21:00 -0400

To attempt to workaround the problem, I modified m4_cr_all in my copy of
m4sugar.m4 from:

m4_translit(m4_dquote(m4_format(m4_dquote(m4_for(
  ,1,255,,[[%c]]))m4_for([i],1,255,,[,i]))), [-])-)

to

m4_translit(m4_dquote(m4_translit(m4_dquote(m4_format(m4_dquote(m4_for(
  ,1,255,,[[%c]]))m4_for([i],1,255,,[,i]))), [-])),[$*],[*$])-)

This did fix my reported problem, but not being very m4sugar literate, I
doubt the robustness of this approach.

I would be happy to test a proper fix.

Thanks much,
--Steve Goetze

On Mon, Mar 29, 2010 at 12:08 PM, Eric Blake <address@hidden> wrote:

> On 03/27/2010 04:48 PM, Steve Goetze wrote:
> > I'm trying to port autoconf to z/os, which uses an EBCDIC codeset.
> > I'm having trouble with autoconf where AC_CHECK_HEADERS_ONCE is
> > causing a bad string to be emitted to config.h.in.
> >
> > For example, what should be "HAVE_STRING_H" is appearing as
> "_____STRING_H".
>
> Thanks for the report.
>
> > When tracing the call to m4_translit, I see that the second argument
> > (the one that uses m4_cr_not_symbols2) looks something like this:
> >
> > *[]abcdefghijklmnopqrstuvwxyz...<(+|&.........!HAVE_string.h);^/-...
> >
> > The ... represent ranges of mostly unprintable characters.  In the
> > middle of the argument, the HAVE_string.h is embedded,
> > inappropriately.  Probably unfortunately in the EBCDIC codeset, the
> > characters !,$,*,) are adjacent; it appears as if the $* is being
> > interpolated to "HAVE_string.h".
>
> That is _exactly_ what is causing the problem.  This is certainly a bug
> in autoconf, although EBCDIC is so infrequently encountered that no one
> else has ever mentioned it.
>
> It is only $* that is problematic; $! is just fine.  So, the trick is to
> figure out how to make m4_cr_not_symbols2 rearrange the symbols to be in
> an order that does not interfere with m4 processing.
>
> >
> > At this point, I'm stuck - I'd appreciate any suggestions on how to
> > fix this, or even report it as a bug.
>
> You have already reported it as a bug.  However, as I don't have access
> to an EBCDIC machine, I will need your help to fix it.  The fix will be
> in lib/m4sugar/m4sugar.m4, in the places where all the m4_cr_* macros
> are defined, but I'm not exactly sure what to define them to while still
> being friendly to your encoding.
>
> --
> Eric Blake   address@hidden    +1-801-349-2682
> Libvirt virtualization library http://libvirt.org
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]