23.0.50 compile problem on Windows XP

23.0.50 compile problem on Windows XP

[Sridhar Boovaraghavan]

With recently updated (2007-02-10, 18:36-0400) code from CVS, I am not
able to compile Emacs. I am using VC 2002 and Windows XP. The
configuration process proceeds without errors (configure.bat
--with-msvc --without-xpm) and I run nmake bootstrap.

What follows is a section of the log before nmake stops. It doesn't
tell me which file causes the error. Any ideas?

Thanks,
Sridhar

--
category.c
ccl.c
fontset.c
fontset.c(1473) : warning C4113: 'void (__cdecl *)()' differs in parameter lists
 from 'void (__cdecl *)(Lisp_Object,Lisp_Object,Lisp_Object)'
fontset.c(1485) : warning C4113: 'void (__cdecl *)()' differs in parameter lists
 from 'void (__cdecl *)(Lisp_Object,Lisp_Object,Lisp_Object)'
fringe.c
image.c
image.c(5273) : warning C4244: '=' : conversion from 'double' to 'int', possible
 loss of data
image.c(5278) : warning C4244: '=' : conversion from 'double' to 'int', possible
 loss of data
image.c(5879) : warning C4244: '=' : conversion from 'double' to 'int', possible
 loss of data
image.c(5880) : warning C4244: '=' : conversion from 'double' to 'int', possible
 loss of data
image.c(5881) : warning C4244: '=' : conversion from 'double' to 'int', possible
 loss of data
d:\cygwin\usr\include\jmorecfg.h(195) : warning C4142: benign redefinition of ty
pe
d:\cygwin\usr\include\jmorecfg.h(249) : warning C4005: 'FAR' : macro redefinitio
n
        D:\Program Files\Microsoft Visual Studio .NET\Vc7\PlatformSDK\Include\Wi
nDef.h(135) : see previous definition of 'FAR'
image.c(6842) : warning C4113: 'void (__cdecl *)()' differs in parameter lists f
rom 'void (__cdecl *)(j_decompress_ptr)'
image.c(6843) : warning C4113: 'boolean (__cdecl *)()' differs in parameter list
s from 'boolean (__cdecl *)(j_decompress_ptr)'
image.c(6844) : warning C4113: 'void (__cdecl *)()' differs in parameter lists f
rom 'void (__cdecl *)(j_decompress_ptr,long)'
image.c(6845) : warning C4113: 'boolean (__cdecl *)()' differs in parameter list
s from 'boolean (__cdecl *)(j_decompress_ptr,int)'
image.c(6846) : warning C4113: 'void (__cdecl *)()' differs in parameter lists f
rom 'void (__cdecl *)(j_decompress_ptr)'
image.c(6956) : warning C4113: 'void (__cdecl *)()' differs in parameter lists f
rom 'void (__cdecl *)(j_decompress_ptr)'
image.c(6957) : warning C4113: 'boolean (__cdecl *)()' differs in parameter list
s from 'boolean (__cdecl *)(j_decompress_ptr)'
image.c(6958) : warning C4113: 'void (__cdecl *)()' differs in parameter lists f
rom 'void (__cdecl *)(j_decompress_ptr,long)'
image.c(6959) : warning C4113: 'boolean (__cdecl *)()' differs in parameter list
s from 'boolean (__cdecl *)(j_decompress_ptr,int)'
image.c(6960) : warning C4113: 'void (__cdecl *)()' differs in parameter lists f
rom 'void (__cdecl *)(j_decompress_ptr)'
image.c(7016) : warning C4113: 'void (__cdecl *)()' differs in parameter lists f
rom 'void (__cdecl *)(j_common_ptr)'
terminal.c
Generating Code...
d:\emacs\src\coding.c(6590) : warning C4715: 'Fcheck_coding_system' : not all co
ntrol paths return a value
d:\emacs\src\charset.c(1034) : warning C4715: 'Fmake_char_internal' : not all co
ntrol paths return a value
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"D:\Program Files\Microsoft Visual Studio .NET\VC7\B
IN\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"D:\Program Files\Microsoft Visual Studio .NET\VC7\B
IN\nmake.exe"' : return code '0x2'
Stop.
-- 
Sridhar Boovaraghavan

Re: 23.0.50 compile problem on Windows XP

[Eli Zaretskii]

> From: Sridhar Boovaraghavan <sridhar_ml@yahoo.com>
> Date: Tue, 02 Oct 2007 18:42:24 -0400
> 
> With recently updated (2007-02-10, 18:36-0400) code from CVS, I am not
> able to compile Emacs. I am using VC 2002 and Windows XP. The
> configuration process proceeds without errors (configure.bat
> --with-msvc --without-xpm) and I run nmake bootstrap.

I cannot reproduce this problem with MinGW GCC.  I don't see even a
single warning from the compiler.

> What follows is a section of the log before nmake stops. It doesn't
> tell me which file causes the error. Any ideas?

Can it be that VC bails out after too many warnings?  If so, can you
use some compiler option to make it less noisy, i.e. lower the warning
threshold?  Or at least bump up the number of warnings that cause it
to give up (if I'm right and the sheer number of warnings causes the
failure)?

Re: 23.0.50 compile problem on Windows XP

[dhruva]

Hi,

On 10/3/07, Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Sridhar Boovaraghavan <sridhar_ml@yahoo.com>
> > Date: Tue, 02 Oct 2007 18:42:24 -0400
> >
> > With recently updated (2007-02-10, 18:36-0400) code from CVS, I am not
> > able to compile Emacs. I am using VC 2002 and Windows XP. The
> > configuration process proceeds without errors (configure.bat
> > --with-msvc --without-xpm) and I run nmake bootstrap.

I am looking into it. The error is slightly above that. A simple way
to get to the root of the problem (reproduce).

1. Set up the MSVC build setup (configure --with-msvc)
2. Go to "src" folder
3. nmake data.obj

You will see the error, it is something to do with inclusion of
"math.h", I am looking into it right now. This does not happen on
MinGW.

I will post my findings shortly.

-dky

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: 23.0.50 compile problem on Windows XP

[Jason Rumney]

dhruva wrote:
> I am looking into it. The error is slightly above that. A simple way
> to get to the root of the problem (reproduce).
>
> 1. Set up the MSVC build setup (configure --with-msvc)
> 2. Go to "src" folder
> 3. nmake data.obj
>
> You will see the error,

Since MSVC is a proprietary program, most of us cannot see the error
this way. Can you post it here? Even if we cannot reproduce the error,
seeing it may lead us to the problem.

Re: 23.0.50 compile problem on Windows XP

[dhruva]

Hi,

On 10/3/07, Jason Rumney <jasonr@gnu.org> wrote:
> dhruva wrote:
> > I am looking into it. The error is slightly above that. A simple way
> > to get to the root of the problem (reproduce).
> >
> > 1. Set up the MSVC build setup (configure --with-msvc)
> > 2. Go to "src" folder
> > 3. nmake data.obj
> >
> > You will see the error,
>
> Since MSVC is a proprietary program, most of us cannot see the error
> this way. Can you post it here? Even if we cannot reproduce the error,
> seeing it may lead us to the problem.
>
>

Here you go... I also have the preprocessed output which I am trying
to examine (that is rather big as expected).

$nmake data.obj

Microsoft (R) Program Maintenance Utility Version 7.10.3077
Copyright (C) Microsoft Corporation.  All rights reserved.

        cl -I. -DWIN32_LEAN_AND_MEAN -D_WIN32_WINNT=0x0400 -nologo
-D_X86_=1 -c -Zel -W2 -H63 -Oxsb2 -Oy- -G6dF -Zp8 -Zi -Di386
-D_CRTAPI1=_cdecl   -Demacs=1 -DWINDOWSNT -DDOS_NT -DHAVE_CONFIG_H
-I../nt/inc -D_UCHAR_T -DHAVE_NTGUI=1  /c data.c
data.c
C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\include\math.h(182) : error C2059: syntax error : '('
data.c(3470) : warning C4113: 'void (__cdecl *)()' differs in
parameter lists from 'void (__cdecl *)(int)'
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Stop.

-dky

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: 23.0.50 compile problem on Windows XP

[Jason Rumney]

dhruva wrote:
> data.c
> C:\Program Files\Microsoft Visual Studio .NET
> 2003\Vc7\include\math.h(182) : error C2059: syntax error : '('
>   

It could be this change, since lisp.h is included before math.h in
data.c, and the MS headers use a different constant to protect against
redefining abs.


2007-09-23  Johannes Weiner  <hannes@saeurebad.de>

    * lisp.h (abs): Define if not defined.

Re: 23.0.50 compile problem on Windows XP

[Eli Zaretskii]

> Date: Wed, 3 Oct 2007 15:31:25 +0530
> From: dhruva <dhruvakm@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, Sridhar Boovaraghavan <sridhar_ml@yahoo.com>,
> 	emacs-devel@gnu.org
> 
>         cl -I. -DWIN32_LEAN_AND_MEAN -D_WIN32_WINNT=0x0400 -nologo
> -D_X86_=1 -c -Zel -W2 -H63 -Oxsb2 -Oy- -G6dF -Zp8 -Zi -Di386
> -D_CRTAPI1=_cdecl   -Demacs=1 -DWINDOWSNT -DDOS_NT -DHAVE_CONFIG_H
> -I../nt/inc -D_UCHAR_T -DHAVE_NTGUI=1  /c data.c
> data.c
> C:\Program Files\Microsoft Visual Studio .NET
> 2003\Vc7\include\math.h(182) : error C2059: syntax error : '('
> data.c(3470) : warning C4113: 'void (__cdecl *)()' differs in
> parameter lists from 'void (__cdecl *)(int)'
> NMAKE : fatal error U1077: 'cl' : return code '0x2'
> Stop.

What is on and around line 182 of VC's math.h?

Re: 23.0.50 compile problem on Windows XP

[Jason Rumney]

Jason Rumney wrote:
> It could be this change, since lisp.h is included before math.h in
> data.c, and the MS headers use a different constant to protect against
> redefining abs.
>
>
> 2007-09-23  Johannes Weiner  <hannes@saeurebad.de>
>
>     * lisp.h (abs): Define if not defined.
>   

If this is the problem, I would expect the same error from floatfns.c,
lread.c and print.c, which also include lisp.h before math.h

Re: 23.0.50 compile problem on Windows XP

[dhruva]

Hi,

On 10/3/07, Jason Rumney <jasonr@gnu.org> wrote:
> Jason Rumney wrote:
> > It could be this change, since lisp.h is included before math.h in
> > data.c, and the MS headers use a different constant to protect against
> > redefining abs.
> >
> >
> > 2007-09-23  Johannes Weiner  <hannes@saeurebad.de>
> >
> >     * lisp.h (abs): Define if not defined.
> >
>
> If this is the problem, I would expect the same error from floatfns.c,
> lread.c and print.c, which also include lisp.h before math.h
>
>

I confirm that all the above files have the same problem. I admire you
remote debugging skills, I was lost working my way through the
preprocessed file!

-dky


-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: 23.0.50 compile problem on Windows XP

[Sridhar Boovaraghavan]

Thank you for looking into and diagnosing the problem. I have moved
the inclusion of <math.h> above "lisp.h" in the affected files and
here's a patch against HEAD that solves this issue.

Regards,
Sridhar

--
Index: data.c
===================================================================
RCS file: /sources/emacs/emacs/src/data.c,v
retrieving revision 1.278
diff -r1.278 data.c
26,33d25
< #include "lisp.h"
< #include "puresize.h"
< #include "charset.h"
< #include "buffer.h"
< #include "keyboard.h"
< #include "frame.h"
< #include "syssignal.h"
< #include "termhooks.h"  /* For FRAME_KBOARD reference in y-or-n-p. */
64a57,65
> #include "lisp.h"
> #include "puresize.h"
> #include "charset.h"
> #include "buffer.h"
> #include "keyboard.h"
> #include "frame.h"
> #include "syssignal.h"
> #include "termhooks.h"  /* For FRAME_KBOARD reference in y-or-n-p. */
> 
Index: floatfns.c
===================================================================
RCS file: /sources/emacs/emacs/src/floatfns.c,v
retrieving revision 1.95
diff -r1.95 floatfns.c
50,51d49
< #include "lisp.h"
< #include "syssignal.h"
78a77,79
> #include "lisp.h"
> #include "syssignal.h"
> 
Index: lread.c
===================================================================
RCS file: /sources/emacs/emacs/src/lread.c,v
retrieving revision 1.380
diff -r1.380 lread.c
30a31
> #include <math.h>
62,63d62
< #include <math.h>
< 
Index: print.c
===================================================================
RCS file: /sources/emacs/emacs/src/print.c,v
retrieving revision 1.240
diff -r1.240 print.c
25a26,38
> 
> /* Work around a problem that happens because math.h on hpux 7
>    defines two static variables--which, in Emacs, are not really static,
>    because `static' is defined as nothing.  The problem is that they are
>    defined both here and in lread.c.
>    These macros prevent the name conflict.  */
> #if defined (HPUX) && !defined (HPUX8)
> #define _MAXLDBL print_maxldbl
> #define _NMAXLDBL print_nmaxldbl
> #endif
> 
> #include <math.h>
> 
48,59d60
< /* Work around a problem that happens because math.h on hpux 7
<    defines two static variables--which, in Emacs, are not really static,
<    because `static' is defined as nothing.  The problem is that they are
<    defined both here and in lread.c.
<    These macros prevent the name conflict.  */
< #if defined (HPUX) && !defined (HPUX8)
< #define _MAXLDBL print_maxldbl
< #define _NMAXLDBL print_nmaxldbl
< #endif
< 
< #include <math.h>
< 

-- 
Sridhar Boovaraghavan

Re: 23.0.50 compile problem on Windows XP

[Jason Rumney]

Sridhar Boovaraghavan wrote:
> Thank you for looking into and diagnosing the problem. I have moved
> the inclusion of <math.h> above "lisp.h" in the affected files and
> here's a patch against HEAD that solves this issue.
>   
There are several other files that include stdlib.h after lisp.h
conditional on WINDOWSNT too. Does that not also cause the same problem?
Also msdos.c includes lisp.h before stdlib.h, so there could be a
problem there too.

I think it is better to remove this definition from lisp.h and include
stdlib.h in the files that need it. But perhaps there is a good reason
not to do that in the first place, so I'll wait and let others comment
on my mail from yesterday before making that change.

Re: 23.0.50 compile problem on Windows XP

[David Robinow]

On 10/4/07, Jason Rumney <jasonr@gnu.org> wrote:
> Sridhar Boovaraghavan wrote:
> > Thank you for looking into and diagnosing the problem. I have moved
> > the inclusion of <math.h> above "lisp.h" in the affected files and
> > here's a patch against HEAD that solves this issue.
> >
> There are several other files that include stdlib.h after lisp.h
> conditional on WINDOWSNT too. Does that not also cause the same problem?
> Also msdos.c includes lisp.h before stdlib.h, so there could be a
> problem there too.
>
> I think it is better to remove this definition from lisp.h and include
> stdlib.h in the files that need it. But perhaps there is a good reason
> not to do that in the first place, so I'll wait and let others comment
> on my mail from yesterday before making that change.
 I agree with Jason. Take 'abs' out of lisp.h
 I used to wonder why "abs" wasn't defined in math.h, since it seems
an obvious place to put it. Apparently somebody at Microsoft was
thinking the same thing. Bad idea.

 Anyway, a good rule is: don't use "abs".   It's not that complicated
an algorithm.

Re: 23.0.50 compile problem on Windows XP

[Sridhar Boovaraghavan]

Jason Rumney <jasonr@gnu.org> writes:

> Sridhar Boovaraghavan wrote:
>> Thank you for looking into and diagnosing the problem. I have moved
>> the inclusion of <math.h> above "lisp.h" in the affected files and
>> here's a patch against HEAD that solves this issue.
>>   
> There are several other files that include stdlib.h after lisp.h
> conditional on WINDOWSNT too. Does that not also cause the same problem?
> Also msdos.c includes lisp.h before stdlib.h, so there could be a
> problem there too.

It doesn't seem to affect other files that an nmake bootstrap uses.

>
> I think it is better to remove this definition from lisp.h and include
> stdlib.h in the files that need it. But perhaps there is a good reason
> not to do that in the first place, so I'll wait and let others comment
> on my mail from yesterday before making that change.

Sounds good.
-- 
Sridhar Boovaraghavan

Re: 23.0.50 compile problem on Windows XP

[Eli Zaretskii]

> Date: Wed, 03 Oct 2007 13:10:07 +0100
> From: Jason Rumney <jasonr@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, Sridhar Boovaraghavan <sridhar_ml@yahoo.com>,
> 	emacs-devel@gnu.org
> 
> the MS headers use a different constant to protect against
> redefining abs.

What constant? I don't see it in the MinGW headers, but maybe MSVC
headers are different.

And I still didn't get an answer to my question from yesterday: What
is on and around line 182 of VC's math.h that causes the failure below?

>         cl -I. -DWIN32_LEAN_AND_MEAN -D_WIN32_WINNT=0x0400 -nologo
> -D_X86_=1 -c -Zel -W2 -H63 -Oxsb2 -Oy- -G6dF -Zp8 -Zi -Di386
> -D_CRTAPI1=_cdecl   -Demacs=1 -DWINDOWSNT -DDOS_NT -DHAVE_CONFIG_H
> -I../nt/inc -D_UCHAR_T -DHAVE_NTGUI=1  /c data.c
> data.c
> C:\Program Files\Microsoft Visual Studio .NET
> 2003\Vc7\include\math.h(182) : error C2059: syntax error : '('
> data.c(3470) : warning C4113: 'void (__cdecl *)()' differs in
> parameter lists from 'void (__cdecl *)(int)'
> NMAKE : fatal error U1077: 'cl' : return code '0x2'
> Stop.

Re: 23.0.50 compile problem on Windows XP

[Eli Zaretskii]

> Date: Thu, 04 Oct 2007 23:11:56 +0100
> From: Jason Rumney <jasonr@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> I think it is better to remove this definition from lisp.h and include
> stdlib.h in the files that need it.

Are you assuming that stdlib.h defines `abs' as a macro?  If so, can
you tell why this assumption is valid?  If not, how would including
stdlib.h help with this problem?

Re: 23.0.50 compile problem on Windows XP

[Eli Zaretskii]

> Date: Thu, 4 Oct 2007 20:46:22 -0400
> From: "David Robinow" <drobinow@gmail.com>
> Cc: Sridhar Boovaraghavan <sridhar_ml@yahoo.com>, emacs-devel@gnu.org
> 
>  I used to wonder why "abs" wasn't defined in math.h, since it seems
> an obvious place to put it.

There's nothing obvious about it, since `abs' is not a floating-point
function.

Re: 23.0.50 compile problem on Windows XP

[Eli Zaretskii]

> From: Sridhar Boovaraghavan <sridhar_ml@yahoo.com>
> Date: Thu, 04 Oct 2007 21:17:08 -0400
> 
> Jason Rumney <jasonr@gnu.org> writes:
> 
> > There are several other files that include stdlib.h after lisp.h
> > conditional on WINDOWSNT too. Does that not also cause the same problem?
> > Also msdos.c includes lisp.h before stdlib.h, so there could be a
> > problem there too.
> 
> It doesn't seem to affect other files that an nmake bootstrap uses.

Then perhaps we don't understand the real cause of the original
problem.  Which is not surprising, since the offending line in MSVC
version of math.h was never shown here.

Re: 23.0.50 compile problem on Windows XP

[Jason Rumney]

Eli Zaretskii wrote:
> What constant? I don't see it in the MinGW headers, but maybe MSVC
> headers are different.
>   
mingw only defines abs in stdlib.h, and has no "protection" against
redefinition. msvc defines it in both stdlib.h and math.h, with an
#ifdef _CRT_ABS_DEFINED (and corresponding #define) around it.

> And I still didn't get an answer to my question from yesterday: What
> is on and around line 182 of VC's math.h that causes the failure below?
>   
I have a different version of VC, but it seems it is the declaration of
abs that causes the problem:

        int     __cdecl abs(__in int _X);

Since lisp.h has already been included, this gets expanded as the macro
defined there, which causes a syntax error.

Re: 23.0.50 compile problem on Windows XP

[Jason Rumney]

Eli Zaretskii wrote:
>> Date: Thu, 04 Oct 2007 23:11:56 +0100
>> From: Jason Rumney <jasonr@gnu.org>
>> Cc: emacs-devel@gnu.org
>>
>> I think it is better to remove this definition from lisp.h and include
>> stdlib.h in the files that need it.
>>     
>
> Are you assuming that stdlib.h defines `abs' as a macro?  If so, can
> you tell why this assumption is valid?  If not, how would including
> stdlib.h help with this problem?
>   
No, stdlib.h includes it as a function declaration. In the general case,
the abs macro is dangerous, as it evaluates its argument twice. Is it
really an important optimization to use a macro for this?

Re: 23.0.50 compile problem on Windows XP

[Eli Zaretskii]

> Date: Fri, 05 Oct 2007 09:08:32 +0100
> From: Jason Rumney <jasonr@gnu.org>
> Cc: sridhar_ml@yahoo.com, emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > What constant? I don't see it in the MinGW headers, but maybe MSVC
> > headers are different.
> >   
> mingw only defines abs in stdlib.h

It defines a _function_ `abs', not a macro.  A macro is not defined
anywhere, AFAICS.

> > And I still didn't get an answer to my question from yesterday: What
> > is on and around line 182 of VC's math.h that causes the failure below?
> >   
> I have a different version of VC, but it seems it is the declaration of
> abs that causes the problem:
> 
>         int     __cdecl abs(__in int _X);
> 
> Since lisp.h has already been included, this gets expanded as the macro
> defined there, which causes a syntax error.

So we are talking about a function-vs-macro mess?  If so, I'd suggest
to rename the macro to something like `emacs_abs', because there's no
good solution to this that I know of.  Carefully crafted headers can
avoid this by taking function names in parens, like this:

      int     __cdecl (abs)(__in int _X);

but if they don't, there's nothing we can do to fix this in general.
Changing the order of headers is just a temporary kludge, IMHO; if we
do that, the problem will continue to haunt us.

Re: 23.0.50 compile problem on Windows XP

[dhruva]

On 10/5/07, Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Wed, 03 Oct 2007 13:10:07 +0100
> > From: Jason Rumney <jasonr@gnu.org>
> > Cc: Eli Zaretskii <eliz@gnu.org>, Sridhar Boovaraghavan <sridhar_ml@yahoo.com>,
> >       emacs-devel@gnu.org
> >
> > the MS headers use a different constant to protect against
> > redefining abs.
>
> What constant? I don't see it in the MinGW headers, but maybe MSVC
> headers are different.
>
> And I still didn't get an answer to my question from yesterday: What
> is on and around line 182 of VC's math.h that causes the failure below?
>

Sorry for the delay... Here you go

   177 _CRTIMP double  __cdecl sinh(double);
   178 _CRTIMP double  __cdecl tan(double);
   179 _CRTIMP double  __cdecl tanh(double);
   180 _CRTIMP double  __cdecl sqrt(double);
   181 #else
   182         int     __cdecl abs(int);
   183         double  __cdecl acos(double);
   184         double  __cdecl asin(double);
   185         double  __cdecl atan(double);
   186         double  __cdecl atan2(double, double);
   187         double  __cdecl cos(double);
   188         double  __cdecl cosh(double);
   189         double  __cdecl exp(double);
   190         double  __cdecl fabs(double);
   191         double  __cdecl fmod(double, double);
   192         long    __cdecl labs(long);
   193         double  __cdecl log(double);

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: 23.0.50 compile problem on Windows XP

[Eli Zaretskii]

> Date: Fri, 05 Oct 2007 09:11:03 +0100
> From: Jason Rumney <jasonr@gnu.org>
> Cc: sridhar_ml@yahoo.com, emacs-devel@gnu.org
> 
> In the general case, the abs macro is dangerous, as it evaluates its
> argument twice. Is it really an important optimization to use a
> macro for this?

I don't know if it's an important optimization; probably not, although
it seems to be used in the display code, where speed is important.  We
could replace it by an inline function, though.

Re: 23.0.50 compile problem on Windows XP

[Eli Zaretskii]

> Date: Fri, 5 Oct 2007 13:51:25 +0530
> From: dhruva <dhruvakm@gmail.com>
> Cc: "Jason Rumney" <jasonr@gnu.org>, sridhar_ml@yahoo.com, emacs-devel@gnu.org
> 
>    182         int     __cdecl abs(int);

Thanks.  Jason was right, it's the macro `abs' vs `abs' the library
function.

Re: 23.0.50 compile problem on Windows XP

[dhruva]

Hi,

On 10/5/07, Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Fri, 5 Oct 2007 13:51:25 +0530
> > From: dhruva <dhruvakm@gmail.com>
> > Cc: "Jason Rumney" <jasonr@gnu.org>, sridhar_ml@yahoo.com, emacs-devel@gnu.org
> >
> >    182         int     __cdecl abs(int);
>
> Thanks.  Jason was right, it's the macro `abs' vs `abs' the library
> function.

I always found this limitation in the language. There is no way to
test for a redefinition of a symbol (aka boundp). Only macros can be
checked for redifinition. Is there some other way to do this sort of
check in C/C++?

-dky

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: 23.0.50 compile problem on Windows XP

[Eli Zaretskii]

> Date: Thu, 04 Oct 2007 23:11:56 +0100
> From: Jason Rumney <jasonr@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> There are several other files that include stdlib.h after lisp.h
> conditional on WINDOWSNT too. Does that not also cause the same problem?
> Also msdos.c includes lisp.h before stdlib.h, so there could be a
> problem there too.

No, msdos.c doesn't suffer from this problem, and I think I know why.
You will see in src/config.in that if HAVE_STDLIB_H is defined,
config.h will include stdlib.h.  Since we always include config.h
before any other headers, if some source file includes stdlib.h
explicitly, that second inclusion is effectively ignored (due to
idempotency of system headers), and the fact that meanwhile lisp.h
defined `abs' as a macro does not have any adverse effects.

However, the Windows build uses its own config.h that is produced from
nt/config.nt, not from src/config.in.  And config.nt does NOT include
stdlib.h.  Which is why I think the Windows build is the only one
affected by the macro `abs' in lisp.h, since even the MSDOS build
produces config.h from config.in (by editing it with Sed scripts in
the msdos/ subdirectory).

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.

Re: 23.0.50 compile problem on Windows XP

[dhruva]

Hi,

On 10/5/07, Eli Zaretskii <eliz@gnu.org> 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!

Re: 23.0.50 compile problem on Windows XP

[Eli Zaretskii]

> Date: Fri, 5 Oct 2007 15:30:58 +0530
> From: dhruva <dhruvakm@gmail.com>
> Cc: "Jason Rumney" <jasonr@gnu.org>, sridhar_ml@yahoo.com, emacs-devel@gnu.org
> 
> On 10/5/07, Eli Zaretskii <eliz@gnu.org> 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.

Well, of course I meant to modify all the callers of `abs' to use the
alternative name!  There are about 65 places in 13 source files where
`abs' is used; renaming them all is a trivially simple job.

> 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).

I don't see how this experience is relevant: we are talking about a
macro, not a function, and a macro whose name is reserved for a
standard library function, on top of that.

Re: 23.0.50 compile problem on Windows XP

[Richard Stallman]

Let's rename the `abs' macro to avoid a collision.

Re: 23.0.50 compile problem on Windows XP

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: jasonr@gnu.org, sridhar_ml@yahoo.com, emacs-devel@gnu.org
> Date: Sat, 06 Oct 2007 09:14:30 -0400
> 
> Let's rename the `abs' macro to avoid a collision.

Done.  The new name is `eabs'.