Re: Spurious testsuite failures due to multibyte locale

[Michael Elizabeth Chastain <mec at shout dot net>]

Andreas Schwab writes:
> I'm getting numerous spurious testsuite failures when running in a
> multibyte locale like utf8 because the version of readline included in
> gdb forces the command line to be always redrawn completely when
> running in a multibyte locale.  The output of the prompt will look
> like "\r\n\r\r(gdb) \r(gdb) " which won't be matched by $gdb_prompt.

Me too:

  http://sources.redhat.com/ml/gdb-patches/2002-12/msg00294.html

At first I thought it was an artifact of my test bed configuration, but
I've straightened out my test bed and it still happens.  This is with
host=i686-pc-linux-gnu, osversion=red-hat-8.0, with $LANG=en_us.UTF-8.

I work around it now by setting $LANG=en_us when I run the test suite.

> -# Copyright 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000
> +# Copyright 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2003

As long as you are touching this line, can you add 2001 and 2002
to the copyright years?  I checked "cvs log gdb.exp" and there
were plenty of changes during those two years.

> +# Make sure we are using the C locale.
> +set env(LC_ALL) "C"
> +

Seems okay to me but I don't have the resources to test it right now.

I've appended my brain dump just in case anyone is curious.
It's on my TODO list to write a small "readline" test program and
file a bug report with the readline maintainers.

Michael C

===

# 2002-12-13: readline 4.3 was imported into gdb HEAD last week.
# It causes perverse screen output: instead of "(gdb) print x",
# I see "(gdb) ^M(gdb) p^M(gdb) pr^M(gdb) pri^m..." with a
# carriage return for each character.
#
# This output style comes as a surprise to all the dejagnu
# patterns.  The symptoms are massive timeouts starting in
# gdb.base/annota1.exp and continuing throughout the test suite.
#
# It looks like readline/display.c:_rl_move_cursor_relative
# has a multibyte bug (MB_CUR_MAX != 1 &&d rl_byte_oriented == 0).
# The first optimization "_rl_last_c_pos == new" is disabled
# because "_rl_last_c_pos" is a display position but "new"
# is an index in a a multibyte string, so they are not comparable.
# That is okay.  But later on, this block appears:
#
#  #if defined (HANDLE_MULTIBYTE)
#  /* NEW points to the buffer point, but _rl_last_c_pos is the display point.
#       The byte length of the string is probably bigger than the column width
#       of the string, which means that if NEW == _rl_last_c_pos, then NEW's
#       display point is less than _rl_last_c_pos. */
#    else if (_rl_last_c_pos >= new)
#  #else
#    else if (_rl_last_c_pos > new)
#  #endif
#
# Not so fast, cowboy!  _rl_last_c_pos == new here, but all the
# characters are plain, so they might match just fine.  But readline
# pessimizes out and issues a CR and reprints the line every time.
# There should be logic here to compare the strings rather than just
# assume that a left-move is needed.
#
# To work around this, I just change $LANG.  The default $LANG
# on my installation of red hat linux 8 is "en_US.UTF-8".
# Just plain "en_US" appears to work.