bug#18366: 24.3.93; Definition of strnicmp needed for Cygwin-w32 build

bug#18366: 24.3.93; Definition of strnicmp needed for Cygwin-w32 build

[Ken Brown]

Cygwin's /usr/include/string.h, which comes from newlib, contains a 
definition of strnicmp; this is needed for the Cygwin-w32 build.  That 
definition has recently been dropped from newlib, and so it will be gone 
in the next Cygwin release.  The following patch fixes the problem.  Is 
it OK for the release branch?

=== modified file 'src/cygw32.h'
--- src/cygw32.h        2014-01-01 07:43:34 +0000
+++ src/cygw32.h        2014-08-30 17:51:36 +0000
@@ -33,6 +33,11 @@
  #include "lisp.h"
  #include "coding.h"

+/* The following was in /usr/include/string.h prior to Cygwin 1.7.33.  */
+#ifndef strnicmp
+#define strnicmp strncasecmp
+#endif
+
  extern void syms_of_cygw32 (void);
  extern char * w32_strerror (int error_no);


=== modified file 'src/w32font.c'
--- src/w32font.c       2014-01-19 15:42:48 +0000
+++ src/w32font.c       2014-08-30 17:47:35 +0000
@@ -35,6 +35,8 @@
  #include "w32font.h"
  #ifdef WINDOWSNT
  #include "w32.h"
+#else  /* CYGWIN */
+#include "cygw32.h"
  #endif

  /* Cleartype available on Windows XP, cleartype_natural from XP SP1.

=== modified file 'src/w32reg.c'
--- src/w32reg.c        2014-01-01 07:43:34 +0000
+++ src/w32reg.c        2014-08-30 17:47:35 +0000
@@ -26,6 +26,10 @@

  #include <stdio.h>

+#ifdef CYGWIN
+#include "cygw32.h"
+#endif
+
  #define REG_ROOT "SOFTWARE\\GNU\\Emacs"

  /* Default system colors from the Display Control Panel settings.  */

bug#18366: 24.3.93; Definition of strnicmp needed for Cygwin-w32 build

[Eli Zaretskii]

> Date: Sat, 30 Aug 2014 14:16:03 -0400
> From: Ken Brown <kbrown@cornell.edu>
> 
> Cygwin's /usr/include/string.h, which comes from newlib, contains a 
> definition of strnicmp; this is needed for the Cygwin-w32 build.  That 
> definition has recently been dropped from newlib

Why did they do such a thing?

> --- src/cygw32.h        2014-01-01 07:43:34 +0000
> +++ src/cygw32.h        2014-08-30 17:51:36 +0000
> @@ -33,6 +33,11 @@
>   #include "lisp.h"
>   #include "coding.h"
> 
> +/* The following was in /usr/include/string.h prior to Cygwin 1.7.33.  */
> +#ifndef strnicmp
> +#define strnicmp strncasecmp
> +#endif

The proper place for this kind of thing is src/conf_post.h, which will
also make sure you won't need to include cygw32.h in every file that
uses that function.  (You'd probably need to condition this on
HAVE_NTGUI in addition to __CYGWIN__.)

I'd also suggest to consider whether to make this a macro or an inline
function, and perhaps also condition that on the Cygwin or newlib's
version rather than on #ifndef (what if newlib will add a function by
that name?).  But this is up to you.

> Is it OK for the release branch?

Yes, with the above taken care of.

Thanks.

bug#18366: 24.3.93; Definition of strnicmp needed for Cygwin-w32 build

[Ken Brown]

Version: 24.3.94

On 8/30/2014 3:15 PM, Eli Zaretskii wrote:
>> Date: Sat, 30 Aug 2014 14:16:03 -0400
>> From: Ken Brown <kbrown@cornell.edu>
>>
>> Cygwin's /usr/include/string.h, which comes from newlib, contains a
>> definition of strnicmp; this is needed for the Cygwin-w32 build.  That
>> definition has recently been dropped from newlib
>
> Why did they do such a thing?

https://sourceware.org/ml/newlib/2014/msg00309.html

> The proper place for this kind of thing is src/conf_post.h, which will
> also make sure you won't need to include cygw32.h in every file that
> uses that function.  (You'd probably need to condition this on
> HAVE_NTGUI in addition to __CYGWIN__.)

OK.

> I'd also suggest to consider whether to make this a macro or an inline
> function, and perhaps also condition that on the Cygwin or newlib's
> version rather than on #ifndef (what if newlib will add a function by
> that name?).  But this is up to you.

It was added to newlib in 1977 (as a macro), and the discussion in the 
URL above explains why it has long been obsolete from Cygwin's point of 
view.  So I think I'll leave it as a macro.

>> Is it OK for the release branch?
>
> Yes, with the above taken care of.

Thanks.  Done, as revision 117467.

Ken