Re: indent 1.10.0 and glibc 2.1.1

[Mike Castle <dalgoda@ix.netcom.com>]

Considering the original response, I am also including bug-glibc@gnu.org.

On Fri, Jun 18, 1999 at 12:40:10PM -0600, Jeffrey A Law wrote:
> 
>   In message < 19990617001241.A15022@thune.netcom.com >you write:
>   > 
>   > On a linux system using egcs 1.1.2 and glibc 2.1.1 I'm trying to build
>   > GNU indent 1.10.0.
>   > 
>   > Using "./configure --prefix=/usr", it dies with:
>   > 
>   > gcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c args.c
>   > args.c: In function `set_option':
>   > args.c:687: void value not ignored as it ought to be
>   > make: *** [args.o] Error 1
> This sounds like a bug in either the glibc header files or (more likely) the
> gnu-indent code.  It is unlikely this is a bug in egcs.


Well, considering that the include file entry is:

/* Copy SRC to DEST.  */
extern char *strcpy __P ((char *__restrict __dest,
                          __const char *__restrict __src));

and the section of code in args.c is:

        case PRO_KEY:
          {
            register char *str;
            if (*param_start == 0)
              if (!(param_start = param))
                goto arg_missing;
              else
                val = 1;
   
            str = (char *) xmalloc (strlen (param_start) + 1);
            strcpy (str, param_start);
            addkey (str, rw_decl);
          }
          break;


I fail to see where there could be a bug in either the glibc headers or
indent.  Though if someone could point out the exact problem to me, then
I would be convinced.

Moreover, replacing the xmalloc() line with a call to strdup() results in
the same message for strdup().

Modifing the string.h to get rid of __restrict does not help.

Renaming "str" to "foo" does not help (thinking of a possible conflict with
a name).

param_start is declared as: char *param_start;

As I noted in the original mail (for the benefit of glibc folks), building
without optimizations is a work around.  So, it's not like this is stopping
anything.

This is not the first time I've experienced apparently bogus messages from 
egcs 1.1.2.  (I was getting bogus "might be used uninitialized" warnings
when building the package found at:
ftp://sunsite.unc.edu/pub/Linux/system/daemons/at-2.9b.tgz when building
with -O2 or greater; I tried posting about it, but ORBS likes to bogusly
list netcom.com, so my messages only sometimes get through).

I do not see how, in this instance, either the glibc headers or the indent 
source could be causing problems.  And given past experience with suspicious 
egcs operations, I would tend to think that egcs is the culprit here.

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen