> From: Bruno Haible
> Date: Thu, 08 Dec 2022 01:21:51 +0100
>
> Gavin Smith wrote:
> > I expect it is not a gnulib problem. install-info/install-info.c declares
> > a function called "error" which appears to clash with a function from glibc.
> > ... The "error" module is brought in by "xalloc"
Gavin Smith wrote:
> I expect it is not a gnulib problem. install-info/install-info.c declares
> a function called "error" which appears to clash with a function from glibc.
> ... The "error" module is brought in by "xalloc" (which we
> ask for explicitly).
Yes, I think the problems already
Sam James writes:
> ../gnulib/lib/error.h:33:13: error: type of ‘error’ does not match original
> declaration [-Werror=lto-type-mismatch]
>33 | extern void error (int __status, int __errnum, const char *__format,
> ...)
> | ^
> install-info.c:218:1: note: type mismatch
Hi,
Compiling texinfo 7.0.1 with CFLAGS="-O2 -flto -Werror=lto-type-mismatch"
results
in the following:
```
make[3]: Entering directory
'/var/tmp/portage/sys-apps/texinfo-7.0.1/work/texinfo-7.0.1/install-info'
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../gnulib/lib
> We should assume that spaces inside @verb are important and should
> be apparent to the reader. This may not be the case if we allow
> line breaking before or after spaces.
I agree, a situation like
```
foo
bar
```
is ambiguous. However, AFAICS, the main usage of `@verb` is having an
easy
>> As can be seen in the attached output, there is no hyphen in the
>> split word. I consider this a bug, since there is zero reason for
>> such a surprising (and undocumented) behaviour.
>
> A hyphen could be confusing as it may be treated as a literal part
> of the code. I doubt this has
