From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: jtc@redback.com Cc: GCC Patches , GDB Patches Subject: Re: [RFC] Move/Rename include/wait.h ("wait.h") Date: Thu, 09 Dec 1999 15:16:00 -0000 Message-id: <385037DA.1730A44E@cygnus.com> References: <384F481D.A77D2CEF@cygnus.com> <5mn1rk6j43.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q4/msg00361.html "J.T. Conklin" wrote: > > >>>>> "Andrew" == Andrew Cagney writes: > Andrew> I'd like to put forward the proposal that the file > Andrew> ``include/wait.h'' be either: > Andrew> o renamed to include/gnu-wait.h (?) > Andrew> o moved to gdb/gdb-wait.h > > If it's not used by other programs, I'd recommend that it be moved to > gdb_wait.h (with an underscore, not a dash). I created gdb_string.h > and gdb_stat.h long ago for the same sort of reasons. Ah, that explains the rationale. We're going to have to put that one into the GDB programing guidelines! :-) Andrew >From rth@cygnus.com Thu Dec 09 23:43:00 1999 From: Richard Henderson To: Andrew Cagney Cc: GCC Patches , GDB Patches Subject: Re: [RFC] Move/Rename include/wait.h ("wait.h") Date: Thu, 09 Dec 1999 23:43:00 -0000 Message-id: <19991209234347.B19791@cygnus.com> References: <384F481D.A77D2CEF@cygnus.com> X-SW-Source: 1999-q4/msg00362.html Content-length: 287 On Thu, Dec 09, 1999 at 05:11:41PM +1100, Andrew Cagney wrote: > I'd like to rename/move the file so that this problem goes away :-) My > preferred option is to move it to the GDB directory as gdb-wait.h since, > to the best of my knowledge, nothing else is using it. Have at it. r~ >From ac131313@cygnus.com Fri Dec 10 06:10:00 1999 From: Andrew Cagney To: "Brown, Rodney" Cc: "'gdb-patches@sourceware.cygnus.com'" Subject: Re: Patches to 19991116 snapshot for vendor compilers on AIX and OSF14.0 Date: Fri, 10 Dec 1999 06:10:00 -0000 Message-id: <3851099E.66043C5C@cygnus.com> References: <9150F3E779F0D211BD370008C733141C38AA0E@aus-msg-02.au.pmsc.com> X-SW-Source: 1999-q4/msg00363.html Content-length: 515 > "Brown, Rodney" wrote: > > Digital (Compaq) errors comparing a function pointer with another with Can you expand this one a bit more. Are the consequence ``bad'' or just that DEC is being pedantic? :-) I ask as GDB currently contains many casts using (make_cleanup_func). The code has been identified as something that violates the ANSI spec but, fortunatly, works. If Alphas really do have a technical problem with that cast/compare then there could easily be the same problem in make_cleanups(). Andrew >From rodneybrown@pmsc.com Fri Dec 10 13:10:00 1999 From: "Brown, Rodney" To: "'Andrew Cagney'" Cc: "'gdb-patches@sourceware.cygnus.com'" Subject: RE: Patches to 19991116 snapshot for vendor compilers on AIX and OSF14.0 Date: Fri, 10 Dec 1999 13:10:00 -0000 Message-id: <9150F3E779F0D211BD370008C733141C38AA2B@aus-msg-02.au.pmsc.com> X-SW-Source: 1999-q4/msg00364.html Content-length: 1340 Title: RE: Patches to 19991116 snapshot for vendor compilers on AIX and OSF14.0   > > Digital (Compaq) errors comparing a function pointer with > another with > > Can you expand this one a bit more.  Are the consequence > ``bad'' or just > that DEC is being pedantic? :-) I think it is only pedantry - it does fail to compile cc: Error: ../../gdb-19991116/gdb/target.c, line 2840: In this statement, "current_target.to_rcmd" and "(void ...)tcomplain" cannot be compared for equality or inequality. (noequality)   if ((current_target.to_rcmd == (void*) tcomplain) -------^ cc: Error: ../../gdb-19991116/gdb/target.c, line 2842: In this statement, "debug_target.to_rcmd" and "(void ...)tcomplain" cannot be compared for equality or inequality. (noequality)           && (debug_target.to_rcmd == (void*) tcomplain))) --------------^ > I ask as GDB currently contains many casts using (make_cleanup_func). > The code has been identified as something that violates the ANSI spec > but, fortunatly, works.  If Alphas really do have a technical problem > with that cast/compare then there could easily be the same problem in > make_cleanups(). If make_cleanups was already present in 19991116, then it has already compiled without erroring out, otherwise I'll find out when I build the new snapshot on the alpha.