X-Authentication-Warning:	delorie.com: mail set sender to djgpp-workers-bounces using -f
X-Recipient:	djgpp-workers AT delorie DOT com
Date:	Sun, 20 Sep 2009 08:29:38 +0300
From:	Eli Zaretskii <eliz AT gnu DOT org>
Subject:	Re: [brobecker AT adacore DOT com: GDB 6.8.91 available for testing]
In-reply-to:	<200909192333.50394.juan.guerrero@gmx.de>
X-012-Sender:	halo1 AT inter DOT net DOT il
To:	djgpp-workers AT delorie DOT com
Message-id:	<83skeiuqt9.fsf@gnu.org>
References:	<833a6jwd5d DOT fsf AT gnu DOT org> <200909192120 DOT 52643 DOT juan DOT guerrero AT gmx DOT de> <83vdjevfzt DOT fsf AT gnu DOT org> <200909192333 DOT 50394 DOT juan DOT guerrero AT gmx DOT de>
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
> Date: Sat, 19 Sep 2009 23:33:50 +0200
> 
> Am Samstag, 19. September 2009 schrieb Eli Zaretskii:
> [snip]
> > What version of GCC is that?
> gcc 4.4.1

I'm a happy user of gcc 3.4.4.

>   add_prefix_cmd ((char*) problem->name,
>     class_maintenance, set_internal_problem_cmd, set_doc,
>     set_cmd_list,
>     concat ("maintenance set ", problem->name, " ", 0),
>     0 , &maintenance_set_cmdlist);

Yes, that's what I get as well.  It seems this is an issue with the
last argument to `concat': GCC 4 wants it to be a pointer, not an
integer.  See

 http://www.linuxonly.nl/docs/2/2_GCC_4_warnings_about_sentinels.html

We get zero because NULL is defined as zero in DJGPP headers.  I
remember endless arguments about this with GCC developers several
years ago, when the headers that come with GCC started to redefine
NULL to their liking.  We won then, by a small change in our headers
IIRC.  It looks like this problem is back.

I think this is a real bug in GCC: on an ILP32 target, there's no
problem passing an integer zero instead of a pointer, since they have
the same size and the same bit pattern.  There's a Bugzilla bug 33403
against GCC 4.2.1, but it was closed by GCC developers because they
claim this warning is for portability reasons (LP64 targets etc.).
However, if the warning is caused by the definition of NULL in the
system headers, the source-level portability is not hampered in any
way, and the warning is bogus.

I would suggest to re-open that bug, this time with a DJGPP specific
content.

Any comments or other suggestions?  DJ?

> gcc -c -DHAVE_CONFIG_H -g -O2  -I. -I./../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  ./strsignal.c -o strsignal.o
> ./strsignal.c: In function 'strsignal':
> ./strsignal.c:427: warning: the address of 'sys_siglist' will never be NULL

This is a real problem, for a change, albeit a minor one: sys_siglist
can be NULL only under #ifndef HAVE_SYS_SIGLIST.  So the comparison to
NULL should be conditioned on that symbol.

- Raw text -