From owner-freebsd-current Sat Mar 1 17:34: 0 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B32637B401 for ; Sat, 1 Mar 2003 17:33:58 -0800 (PST) Received: from mail.liwing.de (mail.liwing.de [213.70.188.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71C2443FCB for ; Sat, 1 Mar 2003 17:33:56 -0800 (PST) (envelope-from rehsack@liwing.de) Received: (qmail 29248 invoked from network); 2 Mar 2003 01:33:55 -0000 Received: from stingray.liwing.de (HELO liwing.de) ([213.70.188.164]) (envelope-sender ) by mail.liwing.de (qmail-ldap-1.03) with SMTP for ; 2 Mar 2003 01:33:55 -0000 Message-ID: <3E615F83.7090106@liwing.de> Date: Sun, 02 Mar 2003 02:33:55 +0100 From: Jens Rehsack Organization: LiWing IT-Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Barney Wolff Cc: Juli Mallett , current@FreeBSD.ORG Subject: Re: PATCH: type errors in src-tree References: <3E5EA13E.9020208@liwing.de> <3E60F1CF.2030400@liwing.de> <20030301155546.A39174@FreeBSD.org> <3E612F7F.1090002@liwing.de> <20030301233642.GA64401@pit.databus.com> <3E614A06.5070403@liwing.de> <20030301180920.A53976@FreeBSD.org> <3E61560D.2070205@liwing.de> <20030302012530.GA65162@pit.databus.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Barney Wolff wrote: > This is an example of what I was pointing out: > > On Sun, Mar 02, 2003 at 01:53:33AM +0100, Jens Rehsack wrote: > ... > >>@@ -1444,22 +1420,19 @@ >> * none - response sent >> * >> */ >>-void >>-send_resp ( intf, Hdr, resp ) >>- int intf; >>- Snmp_Header *Hdr; >>- u_char *resp; >>+static void >>+send_resp ( const int intf, Snmp_Header *Hdr, char *resp ) >> { >> int n; >> >>- if ( ilmi_fd[intf] > 0 ) { >>- n = write ( ilmi_fd[intf], (caddr_t)&resp[1], resp[0] ); >>+ if ( ilmi_fd[intf] > 0 ) { /* FIXME: does ilmi_fd[intf] exists? out of range? */ >>+ n = write ( ilmi_fd[intf], resp+1, resp[0] ); > > ... > > Here's a case where it matters whether something is u_char or char. > write(2) takes a size_t as its third arg, and extension of a char to > that may not be the same as for u_char, for example on Sparc. If the > response is ever >127 bytes, this will fail. You're going to have to > look carefully at how things are used to see when char is appropriate > and when u_char is necessary. > That is really right, but for those check I have to know more 'bout ATM, right? I just have detected some compiler errors using -finline-functions (yes, I'm playing with optimization options :-)). If you know a real good online-reference, one fine day I'll check it and check the entire ilmid.c code for valid signment. Jens To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message