* Re: [RFC] Move/Rename include/wait.h ("wait.h")
1999-12-09 10:54 ` [RFC] Move/Rename include/wait.h ("wait.h") J.T. Conklin
@ 1999-12-09 15:16 ` Andrew Cagney
0 siblings, 0 replies; 2+ messages in thread
From: Andrew Cagney @ 1999-12-09 15:16 UTC (permalink / raw)
To: jtc; +Cc: GCC Patches, GDB Patches
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4225 bytes --]
"J.T. Conklin" wrote:
>
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> 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 <rth@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>, GDB Patches <gdb-patches@sourceware.cygnus.com>
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 <ac131313@cygnus.com>
To: "Brown, Rodney" <rodneybrown@pmsc.com>
Cc: "'gdb-patches@sourceware.cygnus.com'" <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" <rodneybrown@pmsc.com>
To: "'Andrew Cagney'" <ac131313@cygnus.com>
Cc: "'gdb-patches@sourceware.cygnus.com'" <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.
^ permalink raw reply [flat|nested] 2+ messages in thread