Re: [RFC] Move/Rename include/wait.h ("wait.h")

[Andrew Cagney <ac131313@cygnus.com>]

[-- 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.