Re: HAVE_POLL is not enough - RFA

["Philippe De Muyter" <phdm@macqel.be>]

Eli Zaretskii wrote :
> 	* event-loop.c (top-level) [NO_FD_SET]: Deprecate this branch.
> 	Print an error at compile time if we are to use select, but FD_SET
> 	is not available.
> 	(SELECT_MASK, NBBY, FD_SETSIZE, NFDBITS, MASK_SIZE): Define only
> 	if HAVE_POLL is not defined and NO_FD_SET *is* defined.
> 	(create_file_handler) [!HAVE_POLL]: Use FD_SET and FD_CLR.
> 	(delete_file_handler) [!HAVE_POLL]: Use FD_CLR and FD_ISSET.
> 	(gdb_wait_for_event) [!HAVE_POLL]: Copy fd_set sets directly
> 	instead of using memcpy and memset.  Use FD_ISSET.
> 
> +#ifdef NO_FD_SET
> +/* All this stuff below is not required if select is used as God(tm)
> +   intended, with the FD_* macros.  Are there any implementations of
> +   select which don't have FD_SET and other standard FD_* macros?  I
> +   don't think there are, but if I'm wrong, we need to catch them.  */
> +#error FD_SET must be defined if select function is to be used!

I agree completely that your change is the right thing, but it misses
the following sequence :

#if HAVE_SYS_SELECT_H
#include <sys/select.h>
#endif

that is needed a.o. on AIX (See e.g. the sources of bash, screen, mc, uucp,
ncurses, inetutils, cvs or emacs)

Philippe
From cgf@cygnus.com Sat Mar 18 16:40:00 2000
From: Chris Faylor <cgf@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: kettenis@wins.uva.nl, kevinb@cygnus.com, jimb@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Linux sigtramp detection code moved to its proper place
Date: Sat, 18 Mar 2000 16:40:00 -0000
Message-id: <20000318194001.B1270@cygnus.com>
References: <200003162241.RAA19616@zwingli.cygnus.com> <jimb@cygnus.com> <1000316225504.ZM3009@ocotillo.lan> <20000316180048.A30640@cygnus.com> <200003162311.e2GNBUH00362@delius.kettenis.local> <20000316193609.D30640@cygnus.com> <200003182227.RAA07055@indy.delorie.com>
X-SW-Source: 2000-03/msg00337.html
Content-length: 1666

On Sat, Mar 18, 2000 at 05:27:17PM -0500, Eli Zaretskii wrote:
>
>> I would be in favor of just creating an i386-linux-tdep.c and working
>> out the 8.3 issues later.  Since there are already 8.3 issues in
>> the gdb source directory, adding one more is not going to aggravate
>> the problem unduly.
>
>I beg to disagree ;-).  Let me explain why.
>
>What I intend to do to resolve the problem of file names clashing in
>the 8+3 namespace is to use the feature of DJTAR, an untar utility
>which comes with DJGPP, to rename files on the fly.  To this end, I
>created a name-mapping file which specifies what files to rename and
>how; this file needs to be submitted to DJTAR when unpacking the
>distribution.  I will make the file itself part of the distribution
>(so DJGPP users will need to unpack that special file first, and then
>the rest).
>
>I already spent a frustrating evening creating this name-mapping file;
>adding any new files that clash with existing files would require me
>to reproduce that file, possibly affecting other files as well.
>
>I respect the decision not to change any names before GDB 5.0 is
>released, but in the meantime could we please not add any new files
>whose names clash?

I am sympathetic to the plight of DOS users but this sounds like it is
something that could, in the short term, be handled by a program or perl
script fairly easily.  If you actually have a solution for DOS, then
maybe that file or script should be part of the distribution and we
should not have to worry about this severe filename limitation.

IMO, in the long-term intelligent use of subdirectories should reduce
the size of all of the filenames.

cgf
From kevinb@cygnus.com Sat Mar 18 23:21:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH RFA] Another utils.c patch
Date: Sat, 18 Mar 2000 23:21:00 -0000
Message-id: <1000319072047.ZM14883@ocotillo.lan>
X-SW-Source: 2000-03/msg00338.html
Content-length: 1006

This fixes another bug uncovered by running the testsuite for the
IA-64...  may I check this one in?

	* utils.c (floatformat_from_doublest): Make sure space that we're
	writing the float to is completely initialized to zeroes, even
	when the number of bits in the float is not evenly divisible
	by FLOATFORMAT_CHAR_BIT.

Index: utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.4
diff -u -p -r1.4 utils.c
--- utils.c	2000/03/04 02:23:06	1.4
+++ utils.c	2000/03/19 07:12:00
@@ -2722,7 +2722,8 @@ floatformat_from_doublest (fmt, from, to
   unsigned char *uto = (unsigned char *) to;
 
   memcpy (&dfrom, from, sizeof (dfrom));
-  memset (uto, 0, fmt->totalsize / FLOATFORMAT_CHAR_BIT);
+  memset (uto, 0, fmt->totalsize / FLOATFORMAT_CHAR_BIT
+                  + ((fmt->totalsize % FLOATFORMAT_CHAR_BIT) == 0 ? 0 : 1));
   if (dfrom == 0)
     return;			/* Result is zero */
   if (dfrom != dfrom)		/* Result is NaN */