This is the mail archive of the libc-alpha@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: indent 1.10.0 and glibc 2.1.1



Hi Mike,

this is a problem that's not related to egcs but to glibc and indent.
I'm therefore changing the mail adresses again and have set a
reply-to.

The problem is that glibc uses inline macros and functions for string
functions (see  <bits/string.h> and <bits/string2.h>).  If you disable 
those (compile with -D__NO_STRING_INLINES) args.c compiles.  I've been 
able to reproduce the problem with the following small program:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#include <string.h>

#define memcpy(dest,src,len) bcopy((src),(dest),len)

void
test (void)
{
  register char *str;
  char *param_start;
  strcpy (str, param_start);
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

$ /opt/egcs/bin/gcc -Wall -m486 -O2 -c t.c
t.c: In function `test':
t.c:11: void value not ignored as it ought to be

The problem here is that indent redines memcpy (which is used
internally by the inline function strcpy) to bcopy - and bcopy and
memcpy are not identical since memcpy returns a pointer:
extern void bcopy __P ((__const __ptr_t __src, __ptr_t __dest, size_t __n));
extern __ptr_t memcpy __P ((__ptr_t __restrict __dest,
                            __const __ptr_t __restrict __src, size_t __n));

Ok, now how to fix this?  The short term solution for you, Mike, is to 
use -D__STRING_INLINES to compile indent.

Carlo, the indent author might fix his configure test (it checks
for memcpy) and sys.h which uses:
/* configure defines USG if it can't find bcopy */

#ifndef USG
#define memcpy(dest,src,len) bcopy((src),(dest),len)
#endif
but apparently configure neither sets USG nor checks for bcopy.

Now the glibc part.  Is there any chance that we can guard our inline
string functions against such defines?  Or do we declare such programs 
as broken?


>>>>> Mike Castle writes:

Mike> Considering the original response, I am also including bug-glibc@gnu.org.
Mike> 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.


Mike> Well, considering that the include file entry is:

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

Mike> and the section of code in args.c is:

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


Mike> I fail to see where there could be a bug in either the glibc headers or
Mike> indent.  Though if someone could point out the exact problem to me, then
Mike> I would be convinced.
It's always good to see the preprocessed expansion of those lines.

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

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

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

Mike> param_start is declared as: char *param_start;

Mike> As I noted in the original mail (for the benefit of glibc folks), building
Mike> without optimizations is a work around.  So, it's not like this is stopping
Mike> anything.
Since the inline functions and macros are only used with optimizations.

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

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

In this case egcs is working perfectly.

Andreas
-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]