[Openvpn-devel] Uniform snwprintf() across MinGW and MSVC compilers

Message ID 20171012072440.8704-1-simon@rozman.si
State Superseded
Headers show
Series
  • [Openvpn-devel] Uniform snwprintf() across MinGW and MSVC compilers
Related show

Commit Message

Simon Rozman Oct. 12, 2017, 7:24 a.m.
MinGW's snwprintf() is a replacement for ISO C's swprintf() used by
MSVC. MSVC also provides _snwprintf(), however using it leads to
unportable code.

After a discussion with Selva Nair on devel mailing list, an agreement
was reached to use swprintf() for MSVC builds.

This patch uniforms snwprintf() usage while making it compile using
MinGW and MSVC.

Assigning _snwprintf() return value to unused variable was also removed
at one occasion.
---
 config-msvc.h                 | 3 ++-
 src/openvpn/tun.c             | 2 +-
 src/openvpnserv/interactive.c | 8 ++++----
 3 files changed, 7 insertions(+), 6 deletions(-)

Comments

Simon Rozman Oct. 12, 2017, 8:09 a.m. | #1
This is a follow-up (or better worded: a replacement) patch for "[PATCH
01/13] snwprintf() => _snwprintf()".

I have taken into consideration all Selva's recommendations.

Best regards,
Simon

> -----Original Message-----
> From: Simon Rozman [mailto:simon@rozman.si]
> Sent: Thursday, October 12, 2017 9:25 AM
> To: openvpn-devel@lists.sourceforge.net
> Cc: Simon Rozman
> Subject: [PATCH] Uniform snwprintf() across MinGW and MSVC compilers
> 
> MinGW's snwprintf() is a replacement for ISO C's swprintf() used by MSVC.
> MSVC also provides _snwprintf(), however using it leads to unportable
code.
> 
> After a discussion with Selva Nair on devel mailing list, an agreement was
> reached to use swprintf() for MSVC builds.
> 
> This patch uniforms snwprintf() usage while making it compile using MinGW
> and MSVC.
> 
> Assigning _snwprintf() return value to unused variable was also removed at
> one occasion.
> ---
>  config-msvc.h                 | 3 ++-
>  src/openvpn/tun.c             | 2 +-
>  src/openvpnserv/interactive.c | 8 ++++----
>  3 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/config-msvc.h b/config-msvc.h index 0bb153d..c940d15 100644
> --- a/config-msvc.h
> +++ b/config-msvc.h
> @@ -93,9 +93,10 @@
>  #define strncasecmp strnicmp
>  #define strcasecmp _stricmp
> 
> -#if _MSC_VER<1900
> +#if _MSC_VER < 1900
>  #define snprintf _snprintf
>  #endif
> +#define snwprintf swprintf
> 
>  #if _MSC_VER < 1800
>  #define strtoull strtoul
> diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c index 3639718..9e3ca41
> 100644
> --- a/src/openvpn/tun.c
> +++ b/src/openvpn/tun.c
> @@ -4622,7 +4622,7 @@ get_adapter_index_method_1(const char *guid)
>      DWORD index;
>      ULONG aindex;
>      wchar_t wbuf[256];
> -    _snwprintf(wbuf, SIZE(wbuf), L"\\DEVICE\\TCPIP_%S", guid);
> +    snwprintf(wbuf, SIZE(wbuf), L"\\DEVICE\\TCPIP_%S", guid);
>      wbuf [SIZE(wbuf) - 1] = 0;
>      if (GetAdapterIndex(wbuf, &aindex) != NO_ERROR)
>      {
> diff --git a/src/openvpnserv/interactive.c b/src/openvpnserv/interactive.c
> index 823b25b..a060a06 100644
> --- a/src/openvpnserv/interactive.c
> +++ b/src/openvpnserv/interactive.c
> @@ -276,7 +276,7 @@ ReturnProcessId(HANDLE pipe, DWORD pid, DWORD
> count, LPHANDLE events)
>       * Same format as error messages (3 line string) with error = 0 in
>       * 0x%08x format, PID on line 2 and a description "Process ID" on
line 3
>       */
> -    _snwprintf(buf, _countof(buf), L"0x%08x\n0x%08x\n%s", 0, pid, msg);
> +    snwprintf(buf, _countof(buf), L"0x%08x\n0x%08x\n%s", 0, pid, msg);
>      buf[_countof(buf) - 1] = '\0';
> 
>      WritePipeAsync(pipe, buf, wcslen(buf) * 2, count, events); @@ -1066,7
> +1066,7 @@ RegisterDNS(LPVOID unused)
> 
>      if (GetSystemDirectory(sys_path, MAX_PATH))
>      {
> -        _snwprintf(ipcfg, MAX_PATH, L"%s\\%s", sys_path,
L"ipconfig.exe");
> +        snwprintf(ipcfg, MAX_PATH, L"%s\\%s", sys_path,
> + L"ipconfig.exe");
>          ipcfg[MAX_PATH-1] = L'\0';
>      }
> 
> @@ -1706,8 +1706,8 @@ RunOpenvpn(LPVOID p)
>      else if (exit_code != 0)
>      {
>          WCHAR buf[256];
> -        int len = _snwprintf(buf, _countof(buf),
> -                             L"OpenVPN exited with error: exit code =
%lu", exit_code);
> +        snwprintf(buf, _countof(buf),
> +                  L"OpenVPN exited with error: exit code = %lu",
> + exit_code);
>          buf[_countof(buf) - 1] =  L'\0';
>          ReturnError(pipe, ERROR_OPENVPN_STARTUP, buf, 1, &exit_event);
>      }
> --
> 2.9.0.windows.1
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Antonio Quartulli Oct. 12, 2017, 8:19 a.m. | #2
Hi Simon,

On 12/10/17 16:09, Simon Rozman wrote:
> This is a follow-up (or better worded: a replacement) patch for "[PATCH
> 01/13] snwprintf() => _snwprintf()".
> 
> I have taken into consideration all Selva's recommendations.
> 

In case you weren't, you can write comments like the one above right
after the '---' in the patch itself.
This way you don't need to rush to reply to your own patch, but
everything comes together.

So basically you first create the patch with git-format-patch, then edit
it and then send it with git-send-email.

> Best regards,
> Simon
> 
>> -----Original Message-----
>> From: Simon Rozman [mailto:simon@rozman.si]
>> Sent: Thursday, October 12, 2017 9:25 AM
>> To: openvpn-devel@lists.sourceforge.net
>> Cc: Simon Rozman
>> Subject: [PATCH] Uniform snwprintf() across MinGW and MSVC compilers
>>
>> MinGW's snwprintf() is a replacement for ISO C's swprintf() used by MSVC.
>> MSVC also provides _snwprintf(), however using it leads to unportable
> code.
>>
>> After a discussion with Selva Nair on devel mailing list, an agreement was
>> reached to use swprintf() for MSVC builds.
>>
>> This patch uniforms snwprintf() usage while making it compile using MinGW
>> and MSVC.
>>
>> Assigning _snwprintf() return value to unused variable was also removed at
>> one occasion.
>> ---

Here you can write what you want. This text will be dropped when
applying the patch.


Cheers,


>>  config-msvc.h                 | 3 ++-
>>  src/openvpn/tun.c             | 2 +-
>>  src/openvpnserv/interactive.c | 8 ++++----
>>  3 files changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/config-msvc.h b/config-msvc.h index 0bb153d..c940d15 100644
>> --- a/config-msvc.h
>> +++ b/config-msvc.h
>> @@ -93,9 +93,10 @@
>>  #define strncasecmp strnicmp
>>  #define strcasecmp _stricmp
>>
>> -#if _MSC_VER<1900
>> +#if _MSC_VER < 1900
>>  #define snprintf _snprintf
>>  #endif
>> +#define snwprintf swprintf
>>
>>  #if _MSC_VER < 1800
>>  #define strtoull strtoul
>> diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c index 3639718..9e3ca41
>> 100644
>> --- a/src/openvpn/tun.c
>> +++ b/src/openvpn/tun.c
>> @@ -4622,7 +4622,7 @@ get_adapter_index_method_1(const char *guid)
>>      DWORD index;
>>      ULONG aindex;
>>      wchar_t wbuf[256];
>> -    _snwprintf(wbuf, SIZE(wbuf), L"\\DEVICE\\TCPIP_%S", guid);
>> +    snwprintf(wbuf, SIZE(wbuf), L"\\DEVICE\\TCPIP_%S", guid);
>>      wbuf [SIZE(wbuf) - 1] = 0;
>>      if (GetAdapterIndex(wbuf, &aindex) != NO_ERROR)
>>      {
>> diff --git a/src/openvpnserv/interactive.c b/src/openvpnserv/interactive.c
>> index 823b25b..a060a06 100644
>> --- a/src/openvpnserv/interactive.c
>> +++ b/src/openvpnserv/interactive.c
>> @@ -276,7 +276,7 @@ ReturnProcessId(HANDLE pipe, DWORD pid, DWORD
>> count, LPHANDLE events)
>>       * Same format as error messages (3 line string) with error = 0 in
>>       * 0x%08x format, PID on line 2 and a description "Process ID" on
> line 3
>>       */
>> -    _snwprintf(buf, _countof(buf), L"0x%08x\n0x%08x\n%s", 0, pid, msg);
>> +    snwprintf(buf, _countof(buf), L"0x%08x\n0x%08x\n%s", 0, pid, msg);
>>      buf[_countof(buf) - 1] = '\0';
>>
>>      WritePipeAsync(pipe, buf, wcslen(buf) * 2, count, events); @@ -1066,7
>> +1066,7 @@ RegisterDNS(LPVOID unused)
>>
>>      if (GetSystemDirectory(sys_path, MAX_PATH))
>>      {
>> -        _snwprintf(ipcfg, MAX_PATH, L"%s\\%s", sys_path,
> L"ipconfig.exe");
>> +        snwprintf(ipcfg, MAX_PATH, L"%s\\%s", sys_path,
>> + L"ipconfig.exe");
>>          ipcfg[MAX_PATH-1] = L'\0';
>>      }
>>
>> @@ -1706,8 +1706,8 @@ RunOpenvpn(LPVOID p)
>>      else if (exit_code != 0)
>>      {
>>          WCHAR buf[256];
>> -        int len = _snwprintf(buf, _countof(buf),
>> -                             L"OpenVPN exited with error: exit code =
> %lu", exit_code);
>> +        snwprintf(buf, _countof(buf),
>> +                  L"OpenVPN exited with error: exit code = %lu",
>> + exit_code);
>>          buf[_countof(buf) - 1] =  L'\0';
>>          ReturnError(pipe, ERROR_OPENVPN_STARTUP, buf, 1, &exit_event);
>>      }
>> --
>> 2.9.0.windows.1
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
Selva Nair Oct. 13, 2017, 2:18 a.m. | #3
Hi,

For book keeping its easier if version 2 of a patch is sent to the same
thread as
the original (e.g., use --in-reply-to: <msgid> in git send-email) and
[PATCH v2 01/13]
in header.

Anyway, this one is v2 of [PATCH 01/13]
https://www.mail-archive.com/openvpn-devel@lists.sourceforge
.net/msg15583.html

On Thu, Oct 12, 2017 at 3:24 AM, Simon Rozman <simon@rozman.si> wrote:

> MinGW's snwprintf() is a replacement for ISO C's swprintf() used by
> MSVC.


A confusing statement as MinGW too has 'swprintf' and my suggestion
was to just use 'swprintf' both for mingw and MSVC. Then neither build
would depend on non-standard variants.

That said its fine if you want to keep this as just an MSVC compliance
patch..


> MSVC also provides _snwprintf(), however using it leads to
> unportable code.
>
> After a discussion with Selva Nair on devel mailing list, an agreement
> was reached to use swprintf() for MSVC builds.
>
> This patch uniforms snwprintf() usage while making it compile using
> MinGW and MSVC.
>
> Assigning _snwprintf() return value to unused variable was also removed
> at one occasion.
> ---
>  config-msvc.h                 | 3 ++-
>  src/openvpn/tun.c             | 2 +-
>  src/openvpnserv/interactive.c | 8 ++++----
>  3 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/config-msvc.h b/config-msvc.h
> index 0bb153d..c940d15 100644
> --- a/config-msvc.h
> +++ b/config-msvc.h
> @@ -93,9 +93,10 @@
>  #define strncasecmp strnicmp
>  #define strcasecmp _stricmp
>
> -#if _MSC_VER<1900
> +#if _MSC_VER < 1900
>  #define snprintf _snprintf
>  #endif
> +#define snwprintf swprintf


>  #if _MSC_VER < 1800
>  #define strtoull strtoul
> diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
> index 3639718..9e3ca41 100644
> --- a/src/openvpn/tun.c
> +++ b/src/openvpn/tun.c
> @@ -4622,7 +4622,7 @@ get_adapter_index_method_1(const char *guid)
>      DWORD index;
>      ULONG aindex;
>      wchar_t wbuf[256];
> -    _snwprintf(wbuf, SIZE(wbuf), L"\\DEVICE\\TCPIP_%S", guid);
> +    snwprintf(wbuf, SIZE(wbuf), L"\\DEVICE\\TCPIP_%S", guid);
>      wbuf [SIZE(wbuf) - 1] = 0;
>      if (GetAdapterIndex(wbuf, &aindex) != NO_ERROR)
>      {
> diff --git a/src/openvpnserv/interactive.c b/src/openvpnserv/interactive.c
> index 823b25b..a060a06 100644
> --- a/src/openvpnserv/interactive.c
> +++ b/src/openvpnserv/interactive.c
> @@ -276,7 +276,7 @@ ReturnProcessId(HANDLE pipe, DWORD pid, DWORD count,
> LPHANDLE events)
>       * Same format as error messages (3 line string) with error = 0 in
>       * 0x%08x format, PID on line 2 and a description "Process ID" on
> line 3
>       */
> -    _snwprintf(buf, _countof(buf), L"0x%08x\n0x%08x\n%s", 0, pid, msg);
> +    snwprintf(buf, _countof(buf), L"0x%08x\n0x%08x\n%s", 0, pid, msg);
>      buf[_countof(buf) - 1] = '\0';
>
>      WritePipeAsync(pipe, buf, wcslen(buf) * 2, count, events);
> @@ -1066,7 +1066,7 @@ RegisterDNS(LPVOID unused)
>
>      if (GetSystemDirectory(sys_path, MAX_PATH))
>      {
> -        _snwprintf(ipcfg, MAX_PATH, L"%s\\%s", sys_path, L"ipconfig.exe");
> +        snwprintf(ipcfg, MAX_PATH, L"%s\\%s", sys_path, L"ipconfig.exe");
>          ipcfg[MAX_PATH-1] = L'\0';
>      }
>
> @@ -1706,8 +1706,8 @@ RunOpenvpn(LPVOID p)
>      else if (exit_code != 0)
>      {
>          WCHAR buf[256];
> -        int len = _snwprintf(buf, _countof(buf),
> -                             L"OpenVPN exited with error: exit code =
> %lu", exit_code);
> +        snwprintf(buf, _countof(buf),
> +                  L"OpenVPN exited with error: exit code = %lu",
> exit_code);
>          buf[_countof(buf) - 1] =  L'\0';
>          ReturnError(pipe, ERROR_OPENVPN_STARTUP, buf, 1, &exit_event);
>      }
>

As said above, I would have replaced all _snwprintf and snwprintf by
swprintf and avoided the #define. That has the added advantage that mingw
builds also will no longer depend on the non-standard snwprintf.

Nevertheless I'm ok with this unless someone else objects.

Selva
<div dir="ltr">Hi,<div><br></div><div>For book keeping its easier if version 2 of a patch is sent to the same thread as</div><div>the original (e.g., use --in-reply-to: &lt;<span class="" id=":3c6.1" tabindex="-1">msgid</span>&gt; in git send-email) and [PATCH v2 01/13]</div><div>in header. </div><div><br></div><div>Anyway, this one is v2 of [PATCH 01/13] </div><div><a href="https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15583.html" target="_blank">https://www.mail-archive.com/o<wbr><span class="" id=":3c6.2" tabindex="-1">penvpn</span>-<span class="" id=":3c6.3" tabindex="-1">devel</span>@lists.<span class="" id=":3c6.4" tabindex="-1">sourceforge</span><wbr>.net/msg15583.html</a></div><div><br><div><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 12, 2017 at 3:24 AM, Simon <span class="" id=":3c6.5" tabindex="-1">Rozman</span> <span dir="ltr">&lt;<a href="mailto:simon@rozman.si" target="_blank"><span class="" id=":3c6.6" tabindex="-1">simon</span>@<span class="" id=":3c6.7" tabindex="-1">rozman</span>.<span class="" id=":3c6.8" tabindex="-1">si</span></a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">MinGW&#39;s snwprintf() is a replacement for ISO C&#39;s swprintf() used by<br>
MSVC. </blockquote><div><br></div><div>A confusing statement as <span class="" id=":3c6.9" tabindex="-1">MinGW</span> too has &#39;swprintf&#39; and my suggestion</div><div>was to just use &#39;swprintf&#39; both for <span class="" id=":3c6.10" tabindex="-1">mingw</span> and <span class="" id=":3c6.11" tabindex="-1">MSVC</span>. Then neither build</div><div>would depend on non-standard variants.</div><div><br></div><div>That said its fine if you want to keep this as just an <span class="" id=":3c6.12" tabindex="-1">MSVC</span> compliance patch..</div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">MSVC also provides _snwprintf(), however using it leads to<br>
unportable code.<br>
<br>
After a discussion with Selva Nair on devel mailing list, an agreement<br>
was reached to use swprintf() for MSVC builds.<br>
<br>
This patch uniforms snwprintf() usage while making it compile using<br>
MinGW and MSVC.<br>
<br>
Assigning _snwprintf() return value to unused variable was also removed<br>
at one occasion.<br>
---<br>
 config-msvc.h                 | 3 ++-<br>
 src/openvpn/tun.c             | 2 +-<br>
 src/openvpnserv/interactive.c | 8 ++++----<br>
 3 files changed, 7 insertions(+), 6 deletions(-)<br>
<br>
diff --git a/config-msvc.h b/config-msvc.h<br>
index 0bb153d..c940d15 100644<br>
--- a/config-msvc.h<br>
+++ b/config-msvc.h<br>
@@ -93,9 +93,10 @@<br>
 #define strncasecmp strnicmp<br>
 #define strcasecmp _stricmp<br>
<br>
-#if _MSC_VER&lt;1900<br>
+#if _MSC_VER &lt; 1900<br>
 #define snprintf _snprintf<br>
 #endif<br>
+#define snwprintf swprintf </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
 #if _MSC_VER &lt; 1800<br>
 #define strtoull strtoul<br>
diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c<br>
index 3639718..9e3ca41 100644<br>
--- a/src/openvpn/tun.c<br>
+++ b/src/openvpn/tun.c<br>
@@ -4622,7 +4622,7 @@ get_adapter_index_method_1(con<wbr>st char *guid)<br>
     DWORD index;<br>
     ULONG aindex;<br>
     wchar_t wbuf[256];<br>
-    _snwprintf(wbuf, SIZE(wbuf), L&quot;\\DEVICE\\TCPIP_%S&quot;, guid);<br>
+    snwprintf(wbuf, SIZE(wbuf), L&quot;\\DEVICE\\TCPIP_%S&quot;, guid);<br>
     wbuf [SIZE(wbuf) - 1] = 0;<br>
     if (GetAdapterIndex(wbuf, &amp;aindex) != NO_ERROR)<br>
     {<br>
diff --git a/src/openvpnserv/interactive.<wbr>c b/src/openvpnserv/interactive.<wbr>c<br>
index 823b25b..a060a06 100644<br>
--- a/src/openvpnserv/interactive.<wbr>c<br>
+++ b/src/openvpnserv/interactive.<wbr>c<br>
@@ -276,7 +276,7 @@ ReturnProcessId(HANDLE pipe, DWORD pid, DWORD count, LPHANDLE events)<br>
      * Same format as error messages (3 line string) with error = 0 in<br>
      * 0x%08x format, PID on line 2 and a description &quot;Process ID&quot; on line 3<br>
      */<br>
-    _snwprintf(buf, _countof(buf), L&quot;0x%08x\n0x%08x\n%s&quot;, 0, pid, msg);<br>
+    snwprintf(buf, _countof(buf), L&quot;0x%08x\n0x%08x\n%s&quot;, 0, pid, msg);<br>
     buf[_countof(buf) - 1] = &#39;\0&#39;;<br>
<br>
     WritePipeAsync(pipe, buf, wcslen(buf) * 2, count, events);<br>
@@ -1066,7 +1066,7 @@ RegisterDNS(LPVOID unused)<br>
<br>
     if (GetSystemDirectory(sys_path, MAX_PATH))<br>
     {<br>
-        _snwprintf(ipcfg, MAX_PATH, L&quot;%s\\%s&quot;, sys_path, L&quot;ipconfig.exe&quot;);<br>
+        snwprintf(ipcfg, MAX_PATH, L&quot;%s\\%s&quot;, sys_path, L&quot;ipconfig.exe&quot;);<br>
         ipcfg[MAX_PATH-1] = L&#39;\0&#39;;<br>
     }<br>
<br>
@@ -1706,8 +1706,8 @@ RunOpenvpn(LPVOID p)<br>
     else if (exit_code != 0)<br>
     {<br>
         WCHAR buf[256];<br>
-        int len = _snwprintf(buf, _countof(buf),<br>
-                             L&quot;OpenVPN exited with error: exit code = %lu&quot;, exit_code);<br>
+        snwprintf(buf, _countof(buf),<br>
+                  L&quot;OpenVPN exited with error: exit code = %lu&quot;, exit_code);<br>
         buf[_countof(buf) - 1] =  L&#39;\0&#39;;<br>
         ReturnError(pipe, ERROR_OPENVPN_STARTUP, buf, 1, &amp;exit_event);<br>
     }<br></blockquote><div><br></div><div>As said above, I would have replaced all _<span class="" id=":3c6.13" tabindex="-1">snwprintf</span> and <span class="" id=":3c6.14" tabindex="-1">snwprintf</span> by</div><div><span class="" id=":3c6.15" tabindex="-1">swprintf</span> and avoided the #define. That has the added advantage that <span class="" id=":3c6.16" tabindex="-1">mingw</span></div><div>builds also will no longer depend on the non-standard <span class="" id=":3c6.17" tabindex="-1">snwprintf</span>.</div><div><br></div><div>Nevertheless I&#39;m <span class="" id=":3c6.18" tabindex="-1">ok</span> with this unless someone else objects.</div><div><br></div><div><span class="" id=":3c6.19" tabindex="-1">Selva</span></div></div></div></div></div></div>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Simon Rozman Oct. 13, 2017, 4:55 a.m. | #4
Hi,

> For book keeping its easier if version 2 of a patch is sent to the same 
> thread
> as the original (e.g., use --in-reply-to: <msgid> in git send-email) and 
> [PATCH
> v2 01/13] in header.

Thank you, I'll learn the team-play. Please have patience with me. :)

> > On Thu, Oct 12, 2017 at 3:24 AM, Simon Rozman <simon@rozman.si> wrote:
> > MinGW's snwprintf() is a replacement for ISO C's swprintf() used by MSVC.
>
> A confusing statement as MinGW too has 'swprintf' and my suggestion was
> to just use 'swprintf' both for mingw and MSVC. Then neither build would
> depend on non-standard variants.

Actually, the statement would have been correct if you change "MSVC" to 
"MSVC2017".

> As said above, I would have replaced all _snwprintf and snwprintf by 
> swprintf
> and avoided the #define. That has the added advantage that mingw builds
> also will no longer depend on the non-standard snwprintf.

Are you sure MinGW supports swprintf() in an ISO C conformant way? People all 
over the web complain about MinGW's non-ISO C conformant swprintf() 
declaration being a legacy of VC 6.0 runtime library used: 
https://stackoverflow.com/questions/35072373/swprintf-declaration-mismatch
As said before, I am not familiar with MinGW. I read OpenVPN has a patched 
version of it. Perhaps you moved to a more recent VC runtime library 
meanwhile.

If we change _snwprintf/snwprintf() to swprintf() as you suggested, I am 
afraid OpenVPN would not compile on MinGW anymore without #define tweaks. But, 
this time MinGW will need them, not MSVC*2017*.

Selva, if you can confirm that swprintf() really works on OpenVPN's 
distribution of MinGW in an ISO C conformant way, I'll gladly use it. I can 
prepare a patch for you if you can give it a try.

Best regards,
Simon
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Selva Nair Oct. 13, 2017, 5:48 p.m. | #5
Hi,

On Fri, Oct 13, 2017 at 12:55 AM, Simon Rozman <simon@rozman.si> wrote:
...

>
> > As said above, I would have replaced all _snwprintf and snwprintf by
> > swprintf
> > and avoided the #define. That has the added advantage that mingw builds
> > also will no longer depend on the non-standard snwprintf.
>
> Are you sure MinGW supports swprintf() in an ISO C conformant way? People
> all
> over the web complain about MinGW's non-ISO C conformant swprintf()
> declaration being a legacy of VC 6.0 runtime library used:
> https://stackoverflow.com/questions/35072373/swprintf-declaration-mismatch
> As said before, I am not familiar with MinGW. I read OpenVPN has a patched
> version of it. Perhaps you moved to a more recent VC runtime library
> meanwhile.


> If we change _snwprintf/snwprintf() to swprintf() as you suggested, I am
> afraid OpenVPN would not compile on MinGW anymore without #define tweaks.
> But,
> this time MinGW will need them, not MSVC*2017*.


There are two issues here: sprintf signature in Windows runtime and
mingw-w64's  support for the standard conforming variant.

@samuli: Which versions of mingw-w64 should we test against to ensure
release and snapshot builds would succeed?

Windows runtime used to have an swprintf that does not take the buffer
size. But to get that non-conformant behaviour you will need some
preprocessor define like ....NON_CONFORMING_SWPRINTF... so hopefully
modern VS installations does pick the right function.

As for mingw, note that I use mingw-w64, not the older one from mingw.org.
In the former, my understanding is that an implementation based on
_vsnwprintf is used unless the above NON_CONFORMING.. define is active.

Probably there are some old mingw releases where this was broken ---
I'll test your latest patch. That said, I would not depend on any of these
for nul-termination, we should continue to append an explicit L'\0'.

Selva
<div dir="ltr">Hi,<br><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 13, 2017 at 12:55 AM, Simon Rozman <span dir="ltr">&lt;<a href="mailto:simon@rozman.si" target="_blank">simon@rozman.si</a>&gt;</span> wrote:</div><div class="gmail_quote">...</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><br>
&gt; As said above, I would have replaced all _snwprintf and snwprintf by<br>
&gt; swprintf<br>
&gt; and avoided the #define. That has the added advantage that mingw builds<br>
&gt; also will no longer depend on the non-standard snwprintf.<br>
<br>
</span>Are you sure MinGW supports swprintf() in an ISO C conformant way? People all<br>
over the web complain about MinGW&#39;s non-ISO C conformant swprintf()<br>
declaration being a legacy of VC 6.0 runtime library used:<br>
<a href="https://stackoverflow.com/questions/35072373/swprintf-declaration-mismatch" rel="noreferrer" target="_blank">https://stackoverflow.com/ques<wbr>tions/35072373/swprintf-declar<wbr>ation-mismatch</a><br>
As said before, I am not familiar with MinGW. I read OpenVPN has a patched<br>
version of it. Perhaps you moved to a more recent VC runtime library<br>
meanwhile. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If we change _snwprintf/snwprintf() to swprintf() as you suggested, I am<br>
afraid OpenVPN would not compile on MinGW anymore without #define tweaks. But,<br>
this time MinGW will need them, not MSVC*2017*.</blockquote><div><br></div><div>There are two issues here: sprintf signature in Windows runtime and</div><div>mingw-w64&#39;s  support for the standard conforming variant.</div><div><br></div><div><div><div>@samuli: Which versions of mingw-w64 should we test against to ensure</div><div>release and snapshot builds would succeed?</div></div></div><div><br></div><div>Windows runtime used to have an swprintf that does not take the buffer </div><div>size. But to get that non-conformant behaviour you will need some</div><div>preprocessor define like ....NON_CONFORMING_SWPRINTF... so hopefully</div><div>modern VS installations does pick the right function. </div><div><br></div><div>As for mingw, note that I use mingw-w64, not the older one from <a href="http://mingw.org" target="_blank">mingw.org</a>.</div><div>In the former, my understanding is that an implementation based on </div><div>_vsnwprintf is used unless the above NON_CONFORMING.. define is active.</div><div><br></div><div>Probably there are some old mingw releases where this was broken --- </div><div>I&#39;ll test your latest patch. That said, I would not depend on any of these</div><div>for nul-termination, we should continue to append an explicit L&#39;\0&#39;.</div><div><br></div><div>Selva</div></div></div></div>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Samuli Seppänen Oct. 16, 2017, 8:05 a.m. | #6
On 13/10/2017 20:48, Selva wrote:
> Hi,
> 
> On Fri, Oct 13, 2017 at 12:55 AM, Simon Rozman <simon@rozman.si
> <mailto:simon@rozman.si>> wrote:
> ...
> 
> 
>     > As said above, I would have replaced all _snwprintf and snwprintf by
>     > swprintf
>     > and avoided the #define. That has the added advantage that mingw builds
>     > also will no longer depend on the non-standard snwprintf.
> 
>     Are you sure MinGW supports swprintf() in an ISO C conformant way?
>     People all
>     over the web complain about MinGW's non-ISO C conformant swprintf()
>     declaration being a legacy of VC 6.0 runtime library used:
>     https://stackoverflow.com/questions/35072373/swprintf-declaration-mismatch
>     <https://stackoverflow.com/questions/35072373/swprintf-declaration-mismatch>
>     As said before, I am not familiar with MinGW. I read OpenVPN has a
>     patched
>     version of it. Perhaps you moved to a more recent VC runtime library
>     meanwhile. 
> 
> 
>     If we change _snwprintf/snwprintf() to swprintf() as you suggested, I am
>     afraid OpenVPN would not compile on MinGW anymore without #define
>     tweaks. But,
>     this time MinGW will need them, not MSVC*2017*.
> 
> 
> There are two issues here: sprintf signature in Windows runtime and
> mingw-w64's  support for the standard conforming variant.
> 
> @samuli: Which versions of mingw-w64 should we test against to ensure
> release and snapshot builds would succeed?

Right now _we_ use Ubuntu 16.04 for building:

  mingw-w64 4.0.4
  gcc-mingw-w64 5.3.1
  g++-mingw-w64 5.3.1

That said, I'm pretty sure many people still build with Ubuntu 14.04. So
keeping support for it would make sense if it is not horribly painful.
This is what Ubuntu 14.04 comes with:

  mingw-w64 3.1.0
  gcc-mingw-w64 4.8.2
  g++-mingw-w64 4.8.2

Samuli

> 
> Windows runtime used to have an swprintf that does not take the buffer 
> size. But to get that non-conformant behaviour you will need some
> preprocessor define like ....NON_CONFORMING_SWPRINTF... so hopefully
> modern VS installations does pick the right function. 
> 
> As for mingw, note that I use mingw-w64, not the older one
> from mingw.org <http://mingw.org>.
> In the former, my understanding is that an implementation based on 
> _vsnwprintf is used unless the above NON_CONFORMING.. define is active.
> 
> Probably there are some old mingw releases where this was broken --- 
> I'll test your latest patch. That said, I would not depend on any of these
> for nul-termination, we should continue to append an explicit L'\0'.
> 
> Selva

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Илья Шипицин Oct. 16, 2017, 8:22 a.m. | #7
2017-10-16 13:05 GMT+05:00 Samuli Seppänen <samuli@openvpn.net>:

> On 13/10/2017 20:48, Selva wrote:
> > Hi,
> >
> > On Fri, Oct 13, 2017 at 12:55 AM, Simon Rozman <simon@rozman.si
> > <mailto:simon@rozman.si>> wrote:
> > ...
> >
> >
> >     > As said above, I would have replaced all _snwprintf and snwprintf
> by
> >     > swprintf
> >     > and avoided the #define. That has the added advantage that mingw
> builds
> >     > also will no longer depend on the non-standard snwprintf.
> >
> >     Are you sure MinGW supports swprintf() in an ISO C conformant way?
> >     People all
> >     over the web complain about MinGW's non-ISO C conformant swprintf()
> >     declaration being a legacy of VC 6.0 runtime library used:
> >     https://stackoverflow.com/questions/35072373/swprintf-
> declaration-mismatch
> >     <https://stackoverflow.com/questions/35072373/swprintf-
> declaration-mismatch>
> >     As said before, I am not familiar with MinGW. I read OpenVPN has a
> >     patched
> >     version of it. Perhaps you moved to a more recent VC runtime library
> >     meanwhile.
> >
> >
> >     If we change _snwprintf/snwprintf() to swprintf() as you suggested,
> I am
> >     afraid OpenVPN would not compile on MinGW anymore without #define
> >     tweaks. But,
> >     this time MinGW will need them, not MSVC*2017*.
> >
> >
> > There are two issues here: sprintf signature in Windows runtime and
> > mingw-w64's  support for the standard conforming variant.
> >
> > @samuli: Which versions of mingw-w64 should we test against to ensure
> > release and snapshot builds would succeed?
>
> Right now _we_ use Ubuntu 16.04 for building:
>
>   mingw-w64 4.0.4
>   gcc-mingw-w64 5.3.1
>   g++-mingw-w64 5.3.1
>
> That said, I'm pretty sure many people still build with Ubuntu 14.04. So
> keeping support for it would make sense if it is not horribly painful.
> This is what Ubuntu 14.04 comes with:
>
>   mingw-w64 3.1.0
>   gcc-mingw-w64 4.8.2
>   g++-mingw-w64 4.8.2
>

I'm afraid, it's not possible to build openvpn with mingw-gcc-4.8.X due to
lack of firewall manipulation api
(that's why we use xenial repo during travis-ci build)


Samuli, can you please try to build on ubuntu 14.04 ? am I wrong ?


>
> Samuli
>
> >
> > Windows runtime used to have an swprintf that does not take the buffer
> > size. But to get that non-conformant behaviour you will need some
> > preprocessor define like ....NON_CONFORMING_SWPRINTF... so hopefully
> > modern VS installations does pick the right function.
> >
> > As for mingw, note that I use mingw-w64, not the older one
> > from mingw.org <http://mingw.org>.
> > In the former, my understanding is that an implementation based on
> > _vsnwprintf is used unless the above NON_CONFORMING.. define is active.
> >
> > Probably there are some old mingw releases where this was broken ---
> > I'll test your latest patch. That said, I would not depend on any of
> these
> > for nul-termination, we should continue to append an explicit L'\0'.
> >
> > Selva
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-10-16 13:05 GMT+05:00 Samuli Seppänen <span dir="ltr">&lt;<a href="mailto:samuli@openvpn.net" target="_blank">samuli@openvpn.net</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 13/10/2017 20:48, Selva wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; On Fri, Oct 13, 2017 at 12:55 AM, Simon Rozman &lt;<a href="mailto:simon@rozman.si">simon@rozman.si</a><br>
</span><div><div class="h5">&gt; &lt;mailto:<a href="mailto:simon@rozman.si">simon@rozman.si</a>&gt;&gt; wrote:<br>
&gt; ...<br>
&gt;<br>
&gt;<br>
&gt;     &gt; As said above, I would have replaced all _snwprintf and snwprintf by<br>
&gt;     &gt; swprintf<br>
&gt;     &gt; and avoided the #define. That has the added advantage that mingw builds<br>
&gt;     &gt; also will no longer depend on the non-standard snwprintf.<br>
&gt;<br>
&gt;     Are you sure MinGW supports swprintf() in an ISO C conformant way?<br>
&gt;     People all<br>
&gt;     over the web complain about MinGW&#39;s non-ISO C conformant swprintf()<br>
&gt;     declaration being a legacy of VC 6.0 runtime library used:<br>
&gt;     <a href="https://stackoverflow.com/questions/35072373/swprintf-declaration-mismatch" rel="noreferrer" target="_blank">https://stackoverflow.com/<wbr>questions/35072373/swprintf-<wbr>declaration-mismatch</a><br>
&gt;     &lt;<a href="https://stackoverflow.com/questions/35072373/swprintf-declaration-mismatch" rel="noreferrer" target="_blank">https://stackoverflow.com/<wbr>questions/35072373/swprintf-<wbr>declaration-mismatch</a>&gt;<br>
&gt;     As said before, I am not familiar with MinGW. I read OpenVPN has a<br>
&gt;     patched<br>
&gt;     version of it. Perhaps you moved to a more recent VC runtime library<br>
&gt;     meanwhile. <br>
&gt;<br>
&gt;<br>
&gt;     If we change _snwprintf/snwprintf() to swprintf() as you suggested, I am<br>
&gt;     afraid OpenVPN would not compile on MinGW anymore without #define<br>
&gt;     tweaks. But,<br>
&gt;     this time MinGW will need them, not MSVC*2017*.<br>
&gt;<br>
&gt;<br>
&gt; There are two issues here: sprintf signature in Windows runtime and<br>
&gt; mingw-w64&#39;s  support for the standard conforming variant.<br>
&gt;<br>
&gt; @samuli: Which versions of mingw-w64 should we test against to ensure<br>
&gt; release and snapshot builds would succeed?<br>
<br>
</div></div>Right now _we_ use Ubuntu 16.04 for building:<br>
<br>
  mingw-w64 4.0.4<br>
  gcc-mingw-w64 5.3.1<br>
  g++-mingw-w64 5.3.1<br>
<br>
That said, I&#39;m pretty sure many people still build with Ubuntu 14.04. So<br>
keeping support for it would make sense if it is not horribly painful.<br>
This is what Ubuntu 14.04 comes with:<br>
<br>
  mingw-w64 3.1.0<br>
  gcc-mingw-w64 4.8.2<br>
  g++-mingw-w64 4.8.2<br></blockquote><div><br></div><div>I&#39;m afraid, it&#39;s not possible to build openvpn with mingw-gcc-4.8.X due to lack of firewall manipulation api<br></div><div>(that&#39;s why we use xenial repo during travis-ci build)<br><br><br></div><div>Samuli, can you please try to build on ubuntu 14.04 ? am I wrong ?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Samuli<br>
<span class=""><br>
&gt;<br>
&gt; Windows runtime used to have an swprintf that does not take the buffer <br>
&gt; size. But to get that non-conformant behaviour you will need some<br>
&gt; preprocessor define like ....NON_CONFORMING_SWPRINTF... so hopefully<br>
&gt; modern VS installations does pick the right function. <br>
&gt;<br>
&gt; As for mingw, note that I use mingw-w64, not the older one<br>
</span>&gt; from <a href="http://mingw.org" rel="noreferrer" target="_blank">mingw.org</a> &lt;<a href="http://mingw.org" rel="noreferrer" target="_blank">http://mingw.org</a>&gt;.<br>
<span class="">&gt; In the former, my understanding is that an implementation based on <br>
&gt; _vsnwprintf is used unless the above NON_CONFORMING.. define is active.<br>
&gt;<br>
&gt; Probably there are some old mingw releases where this was broken --- <br>
&gt; I&#39;ll test your latest patch. That said, I would not depend on any of these<br>
&gt; for nul-termination, we should continue to append an explicit L&#39;\0&#39;.<br>
&gt;<br>
&gt; Selva<br>
<br>
</span>------------------------------<wbr>------------------------------<wbr>------------------<br>
Check out the vibrant tech community on one of the world&#39;s most<br>
engaging tech sites, Slashdot.org! <a href="http://sdm.link/slashdot" rel="noreferrer" target="_blank">http://sdm.link/slashdot</a><br>
______________________________<wbr>_________________<br>
Openvpn-devel mailing list<br>
<a href="mailto:Openvpn-devel@lists.sourceforge.net">Openvpn-devel@lists.<wbr>sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/openvpn-devel" rel="noreferrer" target="_blank">https://lists.sourceforge.net/<wbr>lists/listinfo/openvpn-devel</a><br>
</blockquote></div><br></div></div>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Selva Nair Oct. 16, 2017, 3:18 p.m. | #8
Hi,

On Mon, Oct 16, 2017 at 4:05 AM, Samuli Seppänen <samuli@openvpn.net> wrote:

> On 13/10/2017 20:48, Selva wrote:
>
> > @samuli: Which versions of mingw-w64 should we test against to ensure
> > release and snapshot builds would succeed?
>
> Right now _we_ use Ubuntu 16.04 for building:
>
>   mingw-w64 4.0.4
>   gcc-mingw-w64 5.3.1
>   g++-mingw-w64 5.3.1
>
> That said, I'm pretty sure many people still build with Ubuntu 14.04. So
> keeping support for it would make sense if it is not horribly painful.
> This is what Ubuntu 14.04 comes with:
>
>   mingw-w64 3.1.0
>   gcc-mingw-w64 4.8.2
>   g++-mingw-w64 4.8.2
>

Thanks.

For the purpose of the present discussion (i.e., behaviour of fwprintf),
14.04 is ok.

Selva
<div dir="ltr"><div class="gmail_extra">Hi,</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 16, 2017 at 4:05 AM, Samuli Seppänen <span dir="ltr">&lt;<a href="mailto:samuli@openvpn.net" target="_blank">samuli@openvpn.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 13/10/2017 20:48, Selva wrote:<br></span><div><div class="m_3700458728655591434h5"><br>
&gt; @samuli: Which versions of mingw-w64 should we test against to ensure<br>
&gt; release and snapshot builds would succeed?<br>
<br>
</div></div>Right now _we_ use Ubuntu 16.04 for building:<br>
<br>
  mingw-w64 4.0.4<br>
  gcc-mingw-w64 5.3.1<br>
  g++-mingw-w64 5.3.1<br>
<br>
That said, I&#39;m pretty sure many people still build with Ubuntu 14.04. So<br>
keeping support for it would make sense if it is not horribly painful.<br>
This is what Ubuntu 14.04 comes with:<br>
<br>
  mingw-w64 3.1.0<br>
  gcc-mingw-w64 4.8.2<br>
  g++-mingw-w64 4.8.2<br></blockquote><div><br></div><div>Thanks.</div><div><br></div><div>For the purpose of the present discussion (i.e., behaviour of fwprintf), 14.04 is ok.</div><div><br></div><div>Selva</div></div></div></div>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Selva Nair Oct. 16, 2017, 3:33 p.m. | #9
Hi

On Mon, Oct 16, 2017 at 4:22 AM, Илья Шипицин <chipitsine@gmail.com> wrote:

>
>
> 2017-10-16 13:05 GMT+05:00 Samuli Seppänen <samuli@openvpn.net>:
>
>> On 13/10/2017 20:48, Selva wrote:
>>
>> > @samuli: Which versions of mingw-w64 should we test against to ensure
>> > release and snapshot builds would succeed?
>>
>> Right now _we_ use Ubuntu 16.04 for building:
>>
>>   mingw-w64 4.0.4
>>   gcc-mingw-w64 5.3.1
>>   g++-mingw-w64 5.3.1
>>
>> That said, I'm pretty sure many people still build with Ubuntu 14.04. So
>> keeping support for it would make sense if it is not horribly painful.
>> This is what Ubuntu 14.04 comes with:
>>
>>   mingw-w64 3.1.0
>>   gcc-mingw-w64 4.8.2
>>   g++-mingw-w64 4.8.2
>>
>
> I'm afraid, it's not possible to build openvpn with mingw-gcc-4.8.X due to
> lack of firewall manipulation api
> (that's why we use xenial repo during travis-ci build)
>

Good to know mingw-w64 from xenial is used in the travis-ci script.

I did a quick test on ubuntu trusty (14.04.05 LTS),  and as you pointed
out, it fails while
compiling block_dns.c because of some errors in the headers for the
windows filtering platform API. All the bits are there so its possible to
build
after tweaking the installed headers (only a couple of lines) but not
something
one would normally want to do.

It does look like targeting 14.04 is no more relevant.

Selva
<div dir="ltr"><br><div class="gmail_extra">Hi </div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 16, 2017 at 4:22 AM, Илья Шипицин <span dir="ltr">&lt;<a href="mailto:chipitsine@gmail.com" target="_blank"><span class="" id=":2cz.1" tabindex="-1">chipitsine</span>@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_4654747034667883082h5">2017-10-16 13:05 GMT+05:00 Samuli Seppänen <span dir="ltr">&lt;<a href="mailto:samuli@openvpn.net" target="_blank">samuli@openvpn.net</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 13/10/2017 20:48, Selva wrote:<br></span><div><div class="m_4654747034667883082m_3741800002398384404h5"><br>
&gt; @samuli: Which versions of mingw-w64 should we test against to ensure<br>
&gt; release and snapshot builds would succeed?<br>
<br>
</div></div>Right now _we_ use Ubuntu 16.04 for building:<br>
<br>
  mingw-w64 4.0.4<br>
  gcc-mingw-w64 5.3.1<br>
  g++-mingw-w64 5.3.1<br>
<br>
That said, I&#39;m pretty sure many people still build with Ubuntu 14.04. So<br>
keeping support for it would make sense if it is not horribly painful.<br>
This is what Ubuntu 14.04 comes with:<br>
<br>
  mingw-w64 3.1.0<br>
  gcc-mingw-w64 4.8.2<br>
  g++-mingw-w64 4.8.2<br></blockquote><div><br></div></div></div><div>I&#39;m afraid, it&#39;s not possible to build openvpn with mingw-gcc-4.8.X due to lack of firewall manipulation api<br></div><div>(that&#39;s why we use xenial repo during travis-ci build)<br></div></div></div></div></blockquote><div><br></div><div>Good to know mingw-w64 from xenial is used in the travis-ci script.</div><div> </div><div>I did a quick test on <span class="" id=":2cz.2" tabindex="-1">ubuntu</span> trusty (14.04.05 LTS),  and as you pointed out, it fails while</div><div>compiling block_<span class="" id=":2cz.3" tabindex="-1">dns</span>.c because of some errors in the headers for the</div><div>windows filtering platform API. All the bits are there so its possible to build</div><div>after tweaking the installed headers (only a couple of lines) but not something</div><div>one would normally want to do.</div><div><br></div><div>It does look like targeting 14.04 is no more relevant.</div><div><br></div><div><span class="" id=":2cz.6" tabindex="-1">Selva</span></div></div></div></div>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Gert Doering Oct. 16, 2017, 4:57 p.m. | #10
Hi,

On Mon, Oct 16, 2017 at 11:33:02AM -0400, Selva wrote:
> I did a quick test on ubuntu trusty (14.04.05 LTS),  and as you pointed
> out, it fails while
> compiling block_dns.c because of some errors in the headers for the
> windows filtering platform API. All the bits are there so its possible to
> build
> after tweaking the installed headers (only a couple of lines) but not
> something
> one would normally want to do.
> 
> It does look like targeting 14.04 is no more relevant.

I have some sort of mixed feedback from Samuli's buildbots here - it
*used* to compile just fine, but since the latest patch (removing the
"manual" dynamic linking stuff), it fails with

openvpnserv-interactive.o:interactive.c:(.text+0xee2): undefined reference to `InitializeUnicastIpAddressEntry'

... so it seems 14.04 mingw does not truly expose all the Vista API bits.


OTOH, we can just document "16.04 is what you need" - that would work
for me, as cross-building is really not "I have this <any breed of unix
OS> and want to build and run OpenVPN here!" building...   (I have much
stricter requirements wrt breaking platforms for "run here" builds :) )

gert
Илья Шипицин Oct. 16, 2017, 5:34 p.m. | #11
2017-10-16 20:33 GMT+05:00 Selva <selva.nair@gmail.com>:

>
> Hi
>
> On Mon, Oct 16, 2017 at 4:22 AM, Илья Шипицин <chipitsine@gmail.com>
> wrote:
>
>>
>>
>> 2017-10-16 13:05 GMT+05:00 Samuli Seppänen <samuli@openvpn.net>:
>>
>>> On 13/10/2017 20:48, Selva wrote:
>>>
>>> > @samuli: Which versions of mingw-w64 should we test against to ensure
>>> > release and snapshot builds would succeed?
>>>
>>> Right now _we_ use Ubuntu 16.04 for building:
>>>
>>>   mingw-w64 4.0.4
>>>   gcc-mingw-w64 5.3.1
>>>   g++-mingw-w64 5.3.1
>>>
>>> That said, I'm pretty sure many people still build with Ubuntu 14.04. So
>>> keeping support for it would make sense if it is not horribly painful.
>>> This is what Ubuntu 14.04 comes with:
>>>
>>>   mingw-w64 3.1.0
>>>   gcc-mingw-w64 4.8.2
>>>   g++-mingw-w64 4.8.2
>>>
>>
>> I'm afraid, it's not possible to build openvpn with mingw-gcc-4.8.X due
>> to lack of firewall manipulation api
>> (that's why we use xenial repo during travis-ci build)
>>
>
> Good to know mingw-w64 from xenial is used in the travis-ci script.
>
> I did a quick test on ubuntu trusty (14.04.05 LTS),  and as you pointed
> out, it fails while
> compiling block_dns.c because of some errors in the headers for the
> windows filtering platform API. All the bits are there so its possible to
> build
> after tweaking the installed headers (only a couple of lines) but not
> something
> one would normally want to do.
>
> It does look like targeting 14.04 is no more relevant.
>

it used to work on 14.04 ... with patched debs (header issue is relatively
easy to fix)

however, it does not work now because of not supporting Vista things


yes, 16.04 is just fine


>
> Selva
>
<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-10-16 20:33 GMT+05:00 Selva <span dir="ltr">&lt;<a href="mailto:selva.nair@gmail.com" target="_blank">selva.nair@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra">Hi </div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Oct 16, 2017 at 4:22 AM, Илья Шипицин <span dir="ltr">&lt;<a href="mailto:chipitsine@gmail.com" target="_blank"><span id="m_7069633959543461732:2cz.1">chipitsine</span>@gmail.com</a>&gt;</span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_7069633959543461732m_4654747034667883082h5"><span class="">2017-10-16 13:05 GMT+05:00 Samuli Seppänen <span dir="ltr">&lt;<a href="mailto:samuli@openvpn.net" target="_blank">samuli@openvpn.net</a>&gt;</span>:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><span>On 13/10/2017 20:48, Selva wrote:<br></span></span><span class=""><div><div class="m_7069633959543461732m_4654747034667883082m_3741800002398384404h5"><br>
&gt; @samuli: Which versions of mingw-w64 should we test against to ensure<br>
&gt; release and snapshot builds would succeed?<br>
<br>
</div></div>Right now _we_ use Ubuntu 16.04 for building:<br>
<br>
  mingw-w64 4.0.4<br>
  gcc-mingw-w64 5.3.1<br>
  g++-mingw-w64 5.3.1<br>
<br>
That said, I&#39;m pretty sure many people still build with Ubuntu 14.04. So<br>
keeping support for it would make sense if it is not horribly painful.<br>
This is what Ubuntu 14.04 comes with:<br>
<br>
  mingw-w64 3.1.0<br>
  gcc-mingw-w64 4.8.2<br>
  g++-mingw-w64 4.8.2<br></span></blockquote><div><br></div></div></div><span class=""><div>I&#39;m afraid, it&#39;s not possible to build openvpn with mingw-gcc-4.8.X due to lack of firewall manipulation api<br></div><div>(that&#39;s why we use xenial repo during travis-ci build)<br></div></span></div></div></div></blockquote><div><br></div><div>Good to know mingw-w64 from xenial is used in the travis-ci script.</div><div> </div><div>I did a quick test on <span id="m_7069633959543461732:2cz.2">ubuntu</span> trusty (14.04.05 LTS),  and as you pointed out, it fails while</div><div>compiling block_<span id="m_7069633959543461732:2cz.3">dns</span>.c because of some errors in the headers for the</div><div>windows filtering platform API. All the bits are there so its possible to build</div><div>after tweaking the installed headers (only a couple of lines) but not something</div><div>one would normally want to do.</div><div><br></div><div>It does look like targeting 14.04 is no more relevant.</div></div></div></div></blockquote><div><br></div><div>it used to work on 14.04 ... with patched debs (header issue is relatively easy to fix)<br><br></div><div>however, it does not work now because of not supporting Vista things<br><br><br></div><div>yes, 16.04 is just fine<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="HOEnZb"><font color="#888888"><div><br></div><div><span id="m_7069633959543461732:2cz.6">Selva</span></div></font></span></div></div></div>
</blockquote></div><br></div></div>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Selva Nair Oct. 16, 2017, 6:17 p.m. | #12
Hi,

On Mon, Oct 16, 2017 at 12:57 PM, Gert Doering <gert@greenie.muc.de> wrote:

> Hi,
>
> On Mon, Oct 16, 2017 at 11:33:02AM -0400, Selva wrote:
> > I did a quick test on ubuntu trusty (14.04.05 LTS),  and as you pointed
> > out, it fails while
> > compiling block_dns.c because of some errors in the headers for the
> > windows filtering platform API. All the bits are there so its possible to
> > build
> > after tweaking the installed headers (only a couple of lines) but not
> > something
> > one would normally want to do.
> >
> > It does look like targeting 14.04 is no more relevant.
>
> I have some sort of mixed feedback from Samuli's buildbots here - it
> *used* to compile just fine, but since the latest patch (removing the
> "manual" dynamic linking stuff), it fails with
>
> openvpnserv-interactive.o:interactive.c:(.text+0xee2): undefined
> reference to `InitializeUnicastIpAddressEntry'
>
> ... so it seems 14.04 mingw does not truly expose all the Vista API bits.
>

My bad, I missed that warning when tested on a 14.04 instance (it was a
google compute engine
with 14.04.5 LTS image with mingw-w64 3.1.0). I do  now see that '
InitializeUnicastIpAddressEntry'
is missing in there.

As these buildbots used to succeed the other header issues I saw (an extra
ifdef
and a duplicate declaration) must be already patched in them.

The function stub is there in the import library library (libiphlpapi.lib),
so we could add
VOID NETIOAPI_API_  InitializeUnicastIpAddressEntry
(PMIB_UNICASTIPADDRESS_ROW Row);
to interactive.c.

But.


> OTOH, we can just document "16.04 is what you need" - that would work
> for me, as cross-building is really not "I have this <any breed of unix
> OS> and want to build and run OpenVPN here!" building...   (I have much
> stricter requirements wrt breaking platforms for "run here" builds :) )
>

I would prefer that option and and we just require 16.04 or better from
now on.

Selva
<div dir="ltr"><div class="gmail_extra">Hi,</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 16, 2017 at 12:57 PM, Gert Doering <span dir="ltr">&lt;<a href="mailto:gert@greenie.muc.de" target="_blank">gert@greenie.muc.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<span class="m_2672371004063453133gmail-"><br>
On Mon, Oct 16, 2017 at 11:33:02AM -0400, Selva wrote:<br>
&gt; I did a quick test on ubuntu trusty (14.04.05 LTS),  and as you pointed<br>
&gt; out, it fails while<br>
&gt; compiling block_dns.c because of some errors in the headers for the<br>
&gt; windows filtering platform API. All the bits are there so its possible to<br>
&gt; build<br>
&gt; after tweaking the installed headers (only a couple of lines) but not<br>
&gt; something<br>
&gt; one would normally want to do.<br>
&gt;<br>
&gt; It does look like targeting 14.04 is no more relevant.<br>
<br>
</span>I have some sort of mixed feedback from Samuli&#39;s buildbots here - it<br>
*used* to compile just fine, but since the latest patch (removing the<br>
&quot;manual&quot; dynamic linking stuff), it fails with<br>
<br>
openvpnserv-interactive.o:inte<wbr>ractive.c:(.text+0xee2): undefined reference to `InitializeUnicastIpAddressEnt<wbr>ry&#39;<br>
<br>
... so it seems 14.04 mingw does not truly expose all the Vista API bits.<br></blockquote><div><br></div><div>My bad, I missed that warning when tested on a 14.04 instance (it was a google compute engine</div><div>with 14.04.5 LTS image with mingw-w64 3.1.0). I do  now see that &#39;<wbr>InitializeUnicastIpAddressEntr<wbr>y&#39;</div><div>is missing in there.</div><div><br></div><div>As these buildbots used to succeed the other header issues I saw (an extra ifdef</div><div>and a duplicate declaration) must be already patched in them.</div><div><br></div><div>The function stub is there in the import library library (libiphlpapi.lib), so we could add</div><div>VOID NETIOAPI_API_  InitializeUnicastIpAddressEntr<wbr>y (PMIB_UNICASTIPADDRESS_ROW Row);</div><div>to interactive.c.</div><div><br></div><div>But.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
OTOH, we can just document &quot;16.04 is what you need&quot; - that would work<br>
for me, as cross-building is really not &quot;I have this &lt;any breed of unix<br>
OS&gt; and want to build and run OpenVPN here!&quot; building...   (I have much<br>
stricter requirements wrt breaking platforms for &quot;run here&quot; builds :) )<br></blockquote><div><br></div><div>I would prefer that option and and we just require 16.04 or better from<br></div><div>now on.</div><div><br></div><div>Selva</div></div><br></div></div>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Илья Шипицин Oct. 16, 2017, 6:47 p.m. | #13
2017-10-16 23:17 GMT+05:00 Selva <selva.nair@gmail.com>:

> Hi,
>
> On Mon, Oct 16, 2017 at 12:57 PM, Gert Doering <gert@greenie.muc.de>
> wrote:
>
>> Hi,
>>
>> On Mon, Oct 16, 2017 at 11:33:02AM -0400, Selva wrote:
>> > I did a quick test on ubuntu trusty (14.04.05 LTS),  and as you pointed
>> > out, it fails while
>> > compiling block_dns.c because of some errors in the headers for the
>> > windows filtering platform API. All the bits are there so its possible
>> to
>> > build
>> > after tweaking the installed headers (only a couple of lines) but not
>> > something
>> > one would normally want to do.
>> >
>> > It does look like targeting 14.04 is no more relevant.
>>
>> I have some sort of mixed feedback from Samuli's buildbots here - it
>> *used* to compile just fine, but since the latest patch (removing the
>> "manual" dynamic linking stuff), it fails with
>>
>> openvpnserv-interactive.o:interactive.c:(.text+0xee2): undefined
>> reference to `InitializeUnicastIpAddressEntry'
>>
>> ... so it seems 14.04 mingw does not truly expose all the Vista API bits.
>>
>
> My bad, I missed that warning when tested on a 14.04 instance (it was a
> google compute engine
> with 14.04.5 LTS image with mingw-w64 3.1.0). I do  now see that
> 'InitializeUnicastIpAddressEntry'
> is missing in there.
>
> As these buildbots used to succeed the other header issues I saw (an extra
> ifdef
> and a duplicate declaration) must be already patched in them.
>
> The function stub is there in the import library library
> (libiphlpapi.lib), so we could add
> VOID NETIOAPI_API_  InitializeUnicastIpAddressEntry
> (PMIB_UNICASTIPADDRESS_ROW Row);
> to interactive.c.
>
> But.
>
>
>> OTOH, we can just document "16.04 is what you need" - that would work
>> for me, as cross-building is really not "I have this <any breed of unix
>> OS> and want to build and run OpenVPN here!" building...   (I have much
>> stricter requirements wrt breaking platforms for "run here" builds :) )
>>
>
> I would prefer that option and and we just require 16.04 or better from
> now on.
>

based on the above, I would say that adding configure check for
"InitializeUnicastIpAddressEntry" would be nice (and making configure
gently complain like "please use Ubuntu 16.04")


>
> Selva
>
>
<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-10-16 23:17 GMT+05:00 Selva <span dir="ltr">&lt;<a href="mailto:selva.nair@gmail.com" target="_blank">selva.nair@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Hi,</div><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-">On Mon, Oct 16, 2017 at 12:57 PM, Gert Doering <span dir="ltr">&lt;<a href="mailto:gert@greenie.muc.de" target="_blank">gert@greenie.muc.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<span class="gmail-m_-9066416347882930197m_2672371004063453133gmail-"><br>
On Mon, Oct 16, 2017 at 11:33:02AM -0400, Selva wrote:<br>
&gt; I did a quick test on ubuntu trusty (14.04.05 LTS),  and as you pointed<br>
&gt; out, it fails while<br>
&gt; compiling block_dns.c because of some errors in the headers for the<br>
&gt; windows filtering platform API. All the bits are there so its possible to<br>
&gt; build<br>
&gt; after tweaking the installed headers (only a couple of lines) but not<br>
&gt; something<br>
&gt; one would normally want to do.<br>
&gt;<br>
&gt; It does look like targeting 14.04 is no more relevant.<br>
<br>
</span>I have some sort of mixed feedback from Samuli&#39;s buildbots here - it<br>
*used* to compile just fine, but since the latest patch (removing the<br>
&quot;manual&quot; dynamic linking stuff), it fails with<br>
<br>
openvpnserv-interactive.o:inte<wbr>ractive.c:(.text+0xee2): undefined reference to `InitializeUnicastIpAddressEnt<wbr>ry&#39;<br>
<br>
... so it seems 14.04 mingw does not truly expose all the Vista API bits.<br></blockquote><div><br></div></span><div>My bad, I missed that warning when tested on a 14.04 instance (it was a google compute engine</div><div>with 14.04.5 LTS image with mingw-w64 3.1.0). I do  now see that &#39;InitializeUnicastIpAddressEnt<wbr>ry&#39;</div><div>is missing in there.</div><div><br></div><div>As these buildbots used to succeed the other header issues I saw (an extra ifdef</div><div>and a duplicate declaration) must be already patched in them.</div><div><br></div><div>The function stub is there in the import library library (libiphlpapi.lib), so we could add</div><div>VOID NETIOAPI_API_  <wbr>InitializeUnicastIpAddressEntr<wbr>y (PMIB_UNICASTIPADDRESS_ROW Row);</div><div>to interactive.c.</div><div><br></div><div>But.</div><span class="gmail-"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
OTOH, we can just document &quot;16.04 is what you need&quot; - that would work<br>
for me, as cross-building is really not &quot;I have this &lt;any breed of unix<br>
OS&gt; and want to build and run OpenVPN here!&quot; building...   (I have much<br>
stricter requirements wrt breaking platforms for &quot;run here&quot; builds :) )<br></blockquote><div><br></div></span><div>I would prefer that option and and we just require 16.04 or better from<br></div><div>now on.</div></div></div></div></blockquote><div><br></div><div>based on the above, I would say that adding configure check for &quot;InitializeUnicastIpAddressEntr<wbr>y&quot; would be nice (and making configure gently complain like &quot;please use Ubuntu 16.04&quot;) </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-HOEnZb"><font color="#888888"><div><br></div><div>Selva</div></font></span></div><br></div></div>
</blockquote></div><br></div></div>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Samuli Seppänen Oct. 17, 2017, 1:43 p.m. | #14
On 16/10/2017 20:34, Илья Шипицин wrote:
> 
> 
> 2017-10-16 20:33 GMT+05:00 Selva <selva.nair@gmail.com
> <mailto:selva.nair@gmail.com>>:
> 
> 
>     Hi 
> 
>     On Mon, Oct 16, 2017 at 4:22 AM, Илья Шипицин <chipitsine@gmail.com
>     <mailto:chipitsine@gmail.com>> wrote:
> 
> 
> 
>         2017-10-16 13:05 GMT+05:00 Samuli Seppänen <samuli@openvpn.net
>         <mailto:samuli@openvpn.net>>:
> 
>             On 13/10/2017 20:48, Selva wrote:
> 
>             > @samuli: Which versions of mingw-w64 should we test against to ensure
>             > release and snapshot builds would succeed?
> 
>             Right now _we_ use Ubuntu 16.04 for building:
> 
>               mingw-w64 4.0.4
>               gcc-mingw-w64 5.3.1
>               g++-mingw-w64 5.3.1
> 
>             That said, I'm pretty sure many people still build with
>             Ubuntu 14.04. So
>             keeping support for it would make sense if it is not
>             horribly painful.
>             This is what Ubuntu 14.04 comes with:
> 
>               mingw-w64 3.1.0
>               gcc-mingw-w64 4.8.2
>               g++-mingw-w64 4.8.2
> 
> 
>         I'm afraid, it's not possible to build openvpn with
>         mingw-gcc-4.8.X due to lack of firewall manipulation api
>         (that's why we use xenial repo during travis-ci build)
> 
> 
>     Good to know mingw-w64 from xenial is used in the travis-ci script.
>      
>     I did a quick test on ubuntu trusty (14.04.05 LTS),  and as you
>     pointed out, it fails while
>     compiling block_dns.c because of some errors in the headers for the
>     windows filtering platform API. All the bits are there so its
>     possible to build
>     after tweaking the installed headers (only a couple of lines) but
>     not something
>     one would normally want to do.
> 
>     It does look like targeting 14.04 is no more relevant.
> 
> 
> it used to work on 14.04 ... with patched debs (header issue is
> relatively easy to fix)
> 
> however, it does not work now because of not supporting Vista things
> 
> 
> yes, 16.04 is just fine
>  

I'm fine with dropping support for the Ubuntu 14.04 version of
mingw-w64, as the unpatched version does not work anyways. Better keep
code at the OpenVPN end as simple as possible.

Patch

diff --git a/config-msvc.h b/config-msvc.h
index 0bb153d..c940d15 100644
--- a/config-msvc.h
+++ b/config-msvc.h
@@ -93,9 +93,10 @@ 
 #define strncasecmp strnicmp
 #define strcasecmp _stricmp
 
-#if _MSC_VER<1900
+#if _MSC_VER < 1900
 #define snprintf _snprintf
 #endif
+#define snwprintf swprintf
 
 #if _MSC_VER < 1800
 #define strtoull strtoul
diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index 3639718..9e3ca41 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -4622,7 +4622,7 @@  get_adapter_index_method_1(const char *guid)
     DWORD index;
     ULONG aindex;
     wchar_t wbuf[256];
-    _snwprintf(wbuf, SIZE(wbuf), L"\\DEVICE\\TCPIP_%S", guid);
+    snwprintf(wbuf, SIZE(wbuf), L"\\DEVICE\\TCPIP_%S", guid);
     wbuf [SIZE(wbuf) - 1] = 0;
     if (GetAdapterIndex(wbuf, &aindex) != NO_ERROR)
     {
diff --git a/src/openvpnserv/interactive.c b/src/openvpnserv/interactive.c
index 823b25b..a060a06 100644
--- a/src/openvpnserv/interactive.c
+++ b/src/openvpnserv/interactive.c
@@ -276,7 +276,7 @@  ReturnProcessId(HANDLE pipe, DWORD pid, DWORD count, LPHANDLE events)
      * Same format as error messages (3 line string) with error = 0 in
      * 0x%08x format, PID on line 2 and a description "Process ID" on line 3
      */
-    _snwprintf(buf, _countof(buf), L"0x%08x\n0x%08x\n%s", 0, pid, msg);
+    snwprintf(buf, _countof(buf), L"0x%08x\n0x%08x\n%s", 0, pid, msg);
     buf[_countof(buf) - 1] = '\0';
 
     WritePipeAsync(pipe, buf, wcslen(buf) * 2, count, events);
@@ -1066,7 +1066,7 @@  RegisterDNS(LPVOID unused)
 
     if (GetSystemDirectory(sys_path, MAX_PATH))
     {
-        _snwprintf(ipcfg, MAX_PATH, L"%s\\%s", sys_path, L"ipconfig.exe");
+        snwprintf(ipcfg, MAX_PATH, L"%s\\%s", sys_path, L"ipconfig.exe");
         ipcfg[MAX_PATH-1] = L'\0';
     }
 
@@ -1706,8 +1706,8 @@  RunOpenvpn(LPVOID p)
     else if (exit_code != 0)
     {
         WCHAR buf[256];
-        int len = _snwprintf(buf, _countof(buf),
-                             L"OpenVPN exited with error: exit code = %lu", exit_code);
+        snwprintf(buf, _countof(buf),
+                  L"OpenVPN exited with error: exit code = %lu", exit_code);
         buf[_countof(buf) - 1] =  L'\0';
         ReturnError(pipe, ERROR_OPENVPN_STARTUP, buf, 1, &exit_event);
     }