From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30323 invoked by alias); 20 Dec 2001 11:04:17 -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 30302 invoked from network); 20 Dec 2001 11:04:15 -0000 Received: from unknown (HELO localhost.cygnus.com) (195.224.55.237) by sources.redhat.com with SMTP; 20 Dec 2001 11:04:15 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id EB7343C8B; Thu, 20 Dec 2001 11:04:12 +0000 (GMT) Message-ID: <3C21C5AC.6090809@cygnus.com> Date: Thu, 20 Dec 2001 03:04:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.6) Gecko/20011207 X-Accept-Language: en-us MIME-Version: 1.0 To: "Martin M. Hunt" Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [RFA] new tcp_open References: <200112031918.LAA18199@cygnus.com> <200112182028.MAA25648@cygnus.com> <15393.6280.385863.67517@localhost.localdomain> <200112200816.AAA24102@cygnus.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2001-12/txt/msg00509.txt.bz2 > Those warnings were always there. My patch reverted those lines back > to what was there before. However, it does appear that changing the char * > cast to a void * would eliminate the warning and should probably work > everywhere. Systems that based their sockets on very old BSD have char * > instead of void * in their setsockopt prototypes. Can I suggest either removing the cast or making it ``void *'' with a comment to the effect that looser OS's such as solaris 2.5.1 have a ``char*'' as that argument. Modern OS's and the Single UNIX spec have ``void *'' as the parameter - I checked Red Hat 7.2 and NetBSD 1.5.2 and Solaris 2.7. http://www.opengroup.org/onlinepubs/007908799/xns/getsockopt.html > I tested void * on Linux and Windows and neither complain. I have been > trying all day on a Solaris box, but it just can't seem to compile > GDB in less than a couple of days. How can a big Ultrasparc with > a load average of 0.08 take > 12 hours to build GDB??? configure appears to be getting really slow again :-/ Andrew