Bug report for readline-8.2 header file issues.

[Aaron Vose]

Readline Maintainers,

 

Summary:

I think I found a (minor) bug in readline 8.2; details follow, and “config.h” is attached. Things build fine, and I can use the library, but some of the header files that are installed with “make && make install” have some issues in them which I will describe in more detail below. One of the issues I describe below appears to be a genuine bug you probably care about. The problems manifests by including the readline library header file “readline.h” and using “-Werror -Wstrict-prototypes” with GCC when building a user program, which causes the build to fail.

 

I found the following readline page:

https://tiswww.case.edu/php/chet/readline/rltop.html

 

I downloaded readline from the following link:

http://git.savannah.gnu.org/cgit/readline.git/snapshot/readline-master.tar.gz

 

I then extracted the tarball (readline 8.2) and ran the following commands to build the library:

export CC=/dept/Boston/avose/riscv/tools/install/riscv-gnu/bin/riscv64-unknown-linux-gnu-gcc

./configure --prefix /dept/Boston/avose/riscv/tools/install/riscv-readline --disable-shared --host=riscv64-unknown-linux-gnu --with-curses

 

I know the above is a cross-compile to RISCV, but I don’t think this problem is specific to the ISA, as I’ve seen the exact same issues with ARM installs of readline 8.2 as well. The issue comes from two places in the header files. One (1) is, I think, an actual issue you want to know about and probably want to fix, the other (2) is probably a more minor thing, but you might still want to know about it, and may want to think about a fix for it.

 

(1)

This first issue may actually be a problem you care about. What happens is that “readline.h” contains the following code, which in and of itself isn’t the issue, this is just where the compiler warning / error initially comes from:

#if defined (USE_VARARGS) && defined (PREFER_STDARG)

extern int rl_message (const char *, ...)  __attribute__((__format__ (printf, 1, 2)));

#else

extern int rl_message ();

#endif

 

The configure process did find “stdarg.h” as can be seen in the attached “config.h” file:

/* Define if you have the <stdarg.h> header file.  */

#define HAVE_STDARG_H 1

 

However, the “readline.h” file in the install location uses the second prototype: “extern int rl_message ();”. It should instead be using the first one: “extern int rl_message (const char *, ...)  __attribute__((__format__ (printf, 1, 2)));”. This is caused by an issue in a file included by “readline.h” called “rlstdc.h”. The problematic code in “rlstdc.h” follows:

#if defined (__STDC__) && defined (HAVE_STDARG_H)

#  define PREFER_STDARG

#  define USE_VARARGS

#else

#  if defined (HAVE_VARARGS_H)

#    define PREFER_VARARGS

#    define USE_VARARGS

#  endif

#endif

 

During the build process, this is fine because “HAVE_STDARG_H” is defined. This then causes “PREFER_STDARG” and “USE_VARARGS” to be defined. So, in the build process, the correct prototype for “rl_message” is used: “extern int rl_message (const char *, ...)  __attribute__((__format__ (printf, 1, 2)));”. However, when user programs include “readline.h” and try to build, “HAVE_STDARG_H” is not defined, and the wrong prototype for “message” is used: “extern int rl_message ();”. This is because the check for “HAVE_STDARG_H” has been “leaked” out of the build environment into the standard installed readline header files. I don’t think the installed header files should have a check for “HAVE_STDARG_H” in them. This seems like an actual bug, and it should probably be fixed.

 

My solution here was a hack. I did the following to resolve the error:

//!!avose: HAVE_STDARG_H was defined during configure, but this macro is not                   

//!!avose: included anywhere in the include files for users of readline.                       

//!!avose: Thus, this edit includes it below. This is needed to avoid issues                   

//!!avose: from "-Werror=strict-prototypes"                                                     

#ifndef HAVE_STDARG_H

#define HAVE_STDARG_H

#define AVOSE_FIX_HAVE_STDARG_H

#endif

#if defined (__STDC__) && defined (HAVE_STDARG_H)

#  define PREFER_STDARG

#  define USE_VARARGS

#else

#  if defined (HAVE_VARARGS_H)

#    define PREFER_VARARGS

#    define USE_VARARGS

#  endif

#endif

#ifdef AVOSE_FIX_HAVE_STDARG_H

#undef HAVE_STDARG_H

#undef AVOSE_FIX_HAVE_STDARG_H

#endif

 

(2)

This second issue is something you may not care about as much. The second issue is another place where compiling a user program that includes “readline.h” is an issue combined with “-Werror -Wstrict-prototypes”. In this second issue, the problem is in the header file “rltypedefs.h”. The section containing the issue is as follows:

 

#if defined(__GNUC__) || defined(__clang__)

typedef int Function () __attribute__((deprecated));

typedef void VFunction () __attribute__((deprecated));

typedef char *CPFunction () __attribute__((deprecated));

typedef char **CPPFunction () __attribute__((deprecated));

#else

typedef int Function ();

typedef void VFunction ();

typedef char *CPFunction ();

typedef char **CPPFunction ();

#endif

 

These prototypes don’t actually appear to be used anywhere by user programs compiling and linking with readline, and they are an error with “-Werror -Wstrict-prototypes”. My solution here was to just disable this whole block of code with “#if 0” as shown below. You may not care too much about this, I suppose, just mentioning it.

 

//!!avose: The following types aren't needed anywhere I can see
//!!avose: and they cause warnings from -Werror=strict-prototypes

#if 0

#if defined(__GNUC__) || defined(__clang__)

typedef int Function () __attribute__((deprecated));

typedef void VFunction () __attribute__((deprecated));

typedef char *CPFunction () __attribute__((deprecated));

typedef char **CPPFunction () __attribute__((deprecated));

#else

typedef int Function ();

typedef void VFunction ();

typedef char *CPFunction ();

typedef char **CPPFunction ();

#endif

#endif

 

It would be wonderful if someone could take a look at these issues, and possible fix them upstream so that others might avoid the problems that I’ve been hitting here. Thanks so much for your time.

 

Thanks much,

~Aaron Vose

 

config.h
Description: config.h