From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28317 invoked by alias); 12 May 2005 19:05:11 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 28125 invoked from network); 12 May 2005 19:04:59 -0000 Received: from unknown (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 12 May 2005 19:04:59 -0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id j4CJ4lIF006031; Thu, 12 May 2005 21:04:47 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id j4CJ4lqa032500; Thu, 12 May 2005 21:04:47 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id j4CJ4l0f012030; Thu, 12 May 2005 21:04:47 +0200 (CEST) Date: Thu, 12 May 2005 19:08:00 -0000 Message-Id: <200505121904.j4CJ4l0f012030@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: eliz@gnu.org CC: gdb-patches@sourceware.org In-reply-to: <01c556d0$Blat.v2.4$7f0d6de0@zahav.net.il> (eliz@gnu.org) Subject: Re: [RFA] Get rid of xm-go32.h (was: [COMMIT] Get rid of xm-cygwin.h) References: <200505060807.j468795E005472@jop31.nfra.nl> <01c55224$Blat.v2.4$7c5b84c0@zahav.net.il> <01c556d0$Blat.v2.4$7f0d6de0@zahav.net.il> X-SW-Source: 2005-05/txt/msg00300.txt.bz2 Date: Thu, 12 May 2005 11:55:30 +0300 From: "Eli Zaretskii" > Date: Fri, 06 May 2005 13:14:08 +0300 > From: "Eli Zaretskii" > CC: gdb-patches@sourceware.org > > > Date: Fri, 6 May 2005 10:07:09 +0200 > > From: Mark Kettenis > > CC: eliz@gnu.org > > > > Eli, any chance you can get rid of xm-go32.h too? > > Chance, yes. We have a public holiday coming up, I hope I will have > time to finally keep my promise to Andrew. The holiday came, and here's what I have in my sandbox. Is this way of solving the issue of non-standard init file names is acceptable? If so, I will commit the changes. Thanks! Note that tm-cisco.h and tm-os68k.h override the standard definition of GDBINIT_FILENAME. Should we switch those platforms to the dynamic initialization as well? I'd happily see tm-cisco.h and tm-os68k.h removed. But if there are reasons to keep them, or if you don't feel like doing the legwork needed to remove the associated targets completely, just remove the definition of GDBINIT_FILENAME from those files. --- gdb/config/i386/go32.m~0 2004-01-20 11:29:16.000000000 +0200 +++ gdb/config/i386/go32.mh 2005-05-11 19:32:58.000000000 +0300 @@ -1,7 +1,7 @@ # Host: Intel x86 running DJGPP MH_CFLAGS= -XM_FILE= xm-go32.h +XM_FILE= NAT_FILE= nm-go32.h NATDEPFILES= go32-nat.o i386-nat.o Please remove XM_FILE completely. --- gdb/top.c~0 2005-02-24 15:51:34.000000000 +0200 +++ gdb/top.c 2005-05-11 19:10:20.000000000 +0300 @@ -71,10 +71,18 @@ /* Initialization file name for gdb. This is overridden in some configs. */ +#ifndef PATH_MAX +# ifdef FILENAME_MAX +# define PATH_MAX FILENAME_MAX +# else +# define PATH_MAX 512 +# endif +#endif I think the proper constant to use here is NAME_MAX, which is the POSIX standard for the "Maximum number of bytes in a filename (not including terminating null)". Hmm, so the code should actually use `NAME_MAX + 1' for the array size. #ifndef GDBINIT_FILENAME #define GDBINIT_FILENAME ".gdbinit" #endif -char gdbinit[] = GDBINIT_FILENAME; +char gdbinit[PATH_MAX]; Why not simply write: char gdbinit[NAME_MAX + 1] = ".gdbinit"; That way we don't need the strcpy in gdb_init(). static void complete_command (char *, int); @@ -1100,6 +1096,8 @@ void init_cli_cmds (void) { struct cmd_list_element *c; + char *source_help_text; + extern char gdbinit[]; Please don't add new 'externs'. Include "top.h" instead. Mark