From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: dhruva Newsgroups: gmane.emacs.devel Subject: Re: 23.0.50 compile problem on Windows XP Date: Fri, 5 Oct 2007 15:30:58 +0530 Message-ID: References: <47035169.8070402@gnu.org> <4703869F.6070909@gnu.org> <47038922.10105@gnu.org> <4705652C.5070803@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1191578482 17977 80.91.229.12 (5 Oct 2007 10:01:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 5 Oct 2007 10:01:22 +0000 (UTC) Cc: sridhar_ml@yahoo.com, emacs-devel@gnu.org, Jason Rumney To: "Eli Zaretskii" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 05 12:01:16 2007 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 1Idjzd-0006GI-S7 for ged-emacs-devel@m.gmane.org; Fri, 05 Oct 2007 12:01:14 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IdjzZ-0005JT-3R for ged-emacs-devel@m.gmane.org; Fri, 05 Oct 2007 06:01:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IdjzW-0005IN-3P for emacs-devel@gnu.org; Fri, 05 Oct 2007 06:01:06 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IdjzR-0005Hp-Cf for emacs-devel@gnu.org; Fri, 05 Oct 2007 06:01:05 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IdjzR-0005Hm-9D for emacs-devel@gnu.org; Fri, 05 Oct 2007 06:01:01 -0400 Original-Received: from nf-out-0910.google.com ([64.233.182.189]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IdjzQ-00020Q-2c for emacs-devel@gnu.org; Fri, 05 Oct 2007 06:01:01 -0400 Original-Received: by nf-out-0910.google.com with SMTP id f5so407010nfh for ; Fri, 05 Oct 2007 03:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=4kgDHze3DL38ym8w38a8vtE7AZbwwJ+4DOxCnAfaaio=; b=grMpRSLGhfL5cbKx6EgLJnt+EGBTYiTtNSmIIPYKgBZVICfIbYS5VyrN4tAWj9cwBXKqD998HGLkiYOSBPt8XpxLVDecw2nHbvx8Qzv7gMLBQMBmadIhDfIbNjXLejmE78Q4K7RSj76rYbQnhSv4wIBcIae3/EPa6zPFobnpOmo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fDLXVltyeHPmBY0JfAtf9O+zghf/hz/Xwb9dHRi1SM222ZaajV0m1CAaflYCcS9vOm/ER7mlydPk0LCW1Bl4dl/6M7qODymp5yWvyN6Ml9xMmC04wpIuFx6zgGHghS6T3b5Lv2usyNHzqy/qRgZLd5Nw9Q4DL7AVLwG54HjKmlg= Original-Received: by 10.78.183.8 with SMTP id g8mr1932675huf.1191578458807; Fri, 05 Oct 2007 03:00:58 -0700 (PDT) Original-Received: by 10.78.205.1 with HTTP; Fri, 5 Oct 2007 03:00:58 -0700 (PDT) In-Reply-To: Content-Disposition: inline X-Detected-Kernel: Linux 2.6 (newer, 2) 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:80287 Archived-At: Hi, On 10/5/07, Eli Zaretskii wrote: > I still think that we should avoid a macro with a name that's > identical to a standard function. We should rename it to something > that cannot clash with the standard C library. If we are trying to overcome a limitation, IMHO, we are forced to redifine the macro with the same name, else, we will have to make changes in the code to use a different name. Samba project has done this sort of a thing by using function pointers to all (almost) system API functions. On platforms which have those APIs, they point to the system provided function and on platforms where they are not, we implement them in a shared library (to delay the binding and provide flexibility by just replacing the shared library/implementation). -dky -- Dhruva Krishnamurthy Contents reflect my personal views only!