From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.devel Subject: Re: 23.0.50; dbus Date: Wed, 02 Jan 2008 06:10:00 +0100 Message-ID: <87tzlwyfrr.fsf@gmx.de> References: <87abod2b1x.fsf@gmx.de> <878x3umeo1.fsf@gmx.de> <87k5mufsl7.fsf@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199250426 30045 80.91.229.12 (2 Jan 2008 05:07:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Jan 2008 05:07:06 +0000 (UTC) Cc: Peter Dyballa , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 02 06:07:25 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1J9vp6-0005Ho-TY for ged-emacs-devel@m.gmane.org; Wed, 02 Jan 2008 06:07:25 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J9vok-0000od-Sc for ged-emacs-devel@m.gmane.org; Wed, 02 Jan 2008 00:07:02 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J9voh-0000lk-0G for emacs-devel@gnu.org; Wed, 02 Jan 2008 00:06:59 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J9voe-0000jl-9j for emacs-devel@gnu.org; Wed, 02 Jan 2008 00:06:57 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J9voe-0000ji-73 for emacs-devel@gnu.org; Wed, 02 Jan 2008 00:06:56 -0500 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1J9vod-00039c-MA for emacs-devel@gnu.org; Wed, 02 Jan 2008 00:06:55 -0500 Original-Received: (qmail invoked by alias); 02 Jan 2008 05:06:53 -0000 Original-Received: from p57A20E11.dip0.t-ipconnect.de (EHLO arthur.local) [87.162.14.17] by mail.gmx.net (mp011) with SMTP; 02 Jan 2008 06:06:53 +0100 X-Authenticated: #3708877 X-Provags-ID: V01U2FsdGVkX19JhLgDcPJJvDFaHnAkMlzqQ+9E5XNIsYXUqxukQd fal5vJ5OE1il3V In-Reply-To: (Stefan Monnier's message of "Tue, 01 Jan 2008 22:06:07 -0500") User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.50 (gnu/linux) X-Y-GMX-Trusted: 0 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:85856 Archived-At: Stefan Monnier writes: >> Here I'm lost. I use something like > >> if (NILP (uname) || (strlen (SDATA (uname)) > 0)) > >> uname is a Lisp_Object. SDATA (uname) returns (char *). What kind of >> signedness do I break in strlen? Does anybody have an idea? > > Someone else already answered the question, but I'll just take the > opportunity to point out that the above code is a common small bug: > the strlen may crash if uname is neither nil nor a string. > A better way to write such code is > > if (STRINGP (uname) && (strlen (SDATA (uname)) > 0)) Not really. NILP (uname) is explicitely one condition for the "then" branch, that's intended. A robust check would be if (NILP (uname) || (STRINGP (uname) && (strlen (SDATA (uname)) > 0))) I'm relatively sure that, if uname is non-nil, it must be a string. However, an additional check wouldn't hurt. > Another benefit is that the compiler can do a better job of > eliminating the (now) redundant STRINGP test that may lurk > inside SDATA. Yes. But I still don't know what to do in the MacOS case, where tons of compiler warnings are raised due to the signedness of the SDATA return value. Peter has shown it in a recent message. Shall we always cast the type like "strlen ((char *) SDATA (uname))"? This would affect much more files but dbusbind.c. > Stefan Best regards, Michael.