| Message ID | 20171012072440.8704-1-simon@rozman.si |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [Openvpn-devel] Uniform snwprintf() across MinGW and MSVC compilers | expand |
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
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 >
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: <<span class="" id=":3c6.1" tabindex="-1">msgid</span>> 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"><<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>></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's snwprintf() is a replacement for ISO C'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 'swprintf' and my suggestion</div><div>was to just use 'swprintf' 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<1900<br> +#if _MSC_VER < 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 < 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"\\DEVICE\\TCPIP_%S", guid);<br> + snwprintf(wbuf, SIZE(wbuf), L"\\DEVICE\\TCPIP_%S", guid);<br> wbuf [SIZE(wbuf) - 1] = 0;<br> if (GetAdapterIndex(wbuf, &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 "Process ID" on line 3<br> */<br> - _snwprintf(buf, _countof(buf), L"0x%08x\n0x%08x\n%s", 0, pid, msg);<br> + snwprintf(buf, _countof(buf), L"0x%08x\n0x%08x\n%s", 0, pid, msg);<br> buf[_countof(buf) - 1] = '\0';<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"%s\\%s", sys_path, L"ipconfig.exe");<br> + snwprintf(ipcfg, MAX_PATH, L"%s\\%s", sys_path, L"ipconfig.exe");<br> ipcfg[MAX_PATH-1] = L'\0';<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"OpenVPN exited with error: exit code = %lu", exit_code);<br> + snwprintf(buf, _countof(buf),<br> + L"OpenVPN exited with error: exit code = %lu", exit_code);<br> buf[_countof(buf) - 1] = L'\0';<br> ReturnError(pipe, ERROR_OPENVPN_STARTUP, buf, 1, &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'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
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
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"><<a href="mailto:simon@rozman.si" target="_blank">simon@rozman.si</a>></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> > As said above, I would have replaced all _snwprintf and snwprintf by<br> > swprintf<br> > and avoided the #define. That has the added advantage that mingw builds<br> > 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'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'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'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'\0'.</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
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
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"><<a href="mailto:samuli@openvpn.net" target="_blank">samuli@openvpn.net</a>></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> > Hi,<br> ><br> > On Fri, Oct 13, 2017 at 12:55 AM, Simon Rozman <<a href="mailto:simon@rozman.si">simon@rozman.si</a><br> </span><div><div class="h5">> <mailto:<a href="mailto:simon@rozman.si">simon@rozman.si</a>>> wrote:<br> > ...<br> ><br> ><br> > > As said above, I would have replaced all _snwprintf and snwprintf by<br> > > swprintf<br> > > and avoided the #define. That has the added advantage that mingw builds<br> > > also will no longer depend on the non-standard snwprintf.<br> ><br> > Are you sure MinGW supports swprintf() in an ISO C conformant way?<br> > People all<br> > over the web complain about MinGW'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/<wbr>questions/35072373/swprintf-<wbr>declaration-mismatch</a><br> > <<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> > As said before, I am not familiar with MinGW. I read OpenVPN has a<br> > patched<br> > version of it. Perhaps you moved to a more recent VC runtime library<br> > meanwhile. <br> ><br> ><br> > If we change _snwprintf/snwprintf() to swprintf() as you suggested, I am<br> > afraid OpenVPN would not compile on MinGW anymore without #define<br> > tweaks. But,<br> > this time MinGW will need them, not MSVC*2017*.<br> ><br> ><br> > There are two issues here: sprintf signature in Windows runtime and<br> > mingw-w64's support for the standard conforming variant.<br> ><br> > @samuli: Which versions of mingw-w64 should we test against to ensure<br> > 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'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'm afraid, it's not possible to build openvpn with mingw-gcc-4.8.X due to lack of firewall manipulation api<br></div><div>(that'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> ><br> > Windows runtime used to have an swprintf that does not take the buffer <br> > size. But to get that non-conformant behaviour you will need some<br> > preprocessor define like ....NON_CONFORMING_SWPRINTF... so hopefully<br> > modern VS installations does pick the right function. <br> ><br> > As for mingw, note that I use mingw-w64, not the older one<br> </span>> from <a href="http://mingw.org" rel="noreferrer" target="_blank">mingw.org</a> <<a href="http://mingw.org" rel="noreferrer" target="_blank">http://mingw.org</a>>.<br> <span class="">> In the former, my understanding is that an implementation based on <br> > _vsnwprintf is used unless the above NON_CONFORMING.. define is active.<br> ><br> > Probably there are some old mingw releases where this was broken --- <br> > I'll test your latest patch. That said, I would not depend on any of these<br> > for nul-termination, we should continue to append an explicit L'\0'.<br> ><br> > Selva<br> <br> </span>------------------------------<wbr>------------------------------<wbr>------------------<br> Check out the vibrant tech community on one of the world'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
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"><<a href="mailto:samuli@openvpn.net" target="_blank">samuli@openvpn.net</a>></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> > @samuli: Which versions of mingw-w64 should we test against to ensure<br> > 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'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
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"><<a href="mailto:chipitsine@gmail.com" target="_blank"><span class="" id=":2cz.1" tabindex="-1">chipitsine</span>@gmail.com</a>></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"><<a href="mailto:samuli@openvpn.net" target="_blank">samuli@openvpn.net</a>></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> > @samuli: Which versions of mingw-w64 should we test against to ensure<br> > 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'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'm afraid, it's not possible to build openvpn with mingw-gcc-4.8.X due to lack of firewall manipulation api<br></div><div>(that'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
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
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"><<a href="mailto:selva.nair@gmail.com" target="_blank">selva.nair@gmail.com</a>></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"><<a href="mailto:chipitsine@gmail.com" target="_blank"><span id="m_7069633959543461732:2cz.1">chipitsine</span>@gmail.com</a>></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"><<a href="mailto:samuli@openvpn.net" target="_blank">samuli@openvpn.net</a>></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> > @samuli: Which versions of mingw-w64 should we test against to ensure<br> > 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'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'm afraid, it's not possible to build openvpn with mingw-gcc-4.8.X due to lack of firewall manipulation api<br></div><div>(that'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
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"><<a href="mailto:gert@greenie.muc.de" target="_blank">gert@greenie.muc.de</a>></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> > I did a quick test on ubuntu trusty (14.04.05 LTS), and as you pointed<br> > out, it fails while<br> > compiling block_dns.c because of some errors in the headers for the<br> > windows filtering platform API. All the bits are there so its possible to<br> > build<br> > after tweaking the installed headers (only a couple of lines) but not<br> > something<br> > one would normally want to do.<br> ><br> > It does look like targeting 14.04 is no more relevant.<br> <br> </span>I have some sort of mixed feedback from Samuli's buildbots here - it<br> *used* to compile just fine, but since the latest patch (removing the<br> "manual" dynamic linking stuff), it fails with<br> <br> openvpnserv-interactive.o:inte<wbr>ractive.c:(.text+0xee2): undefined reference to `InitializeUnicastIpAddressEnt<wbr>ry'<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 '<wbr>InitializeUnicastIpAddressEntr<wbr>y'</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 "16.04 is what you need" - that would work<br> for me, as cross-building is really not "I have this <any breed of unix<br> OS> and want to build and run OpenVPN here!" building... (I have much<br> stricter requirements wrt breaking platforms for "run here" 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
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"><<a href="mailto:selva.nair@gmail.com" target="_blank">selva.nair@gmail.com</a>></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"><<a href="mailto:gert@greenie.muc.de" target="_blank">gert@greenie.muc.de</a>></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> > I did a quick test on ubuntu trusty (14.04.05 LTS), and as you pointed<br> > out, it fails while<br> > compiling block_dns.c because of some errors in the headers for the<br> > windows filtering platform API. All the bits are there so its possible to<br> > build<br> > after tweaking the installed headers (only a couple of lines) but not<br> > something<br> > one would normally want to do.<br> ><br> > It does look like targeting 14.04 is no more relevant.<br> <br> </span>I have some sort of mixed feedback from Samuli's buildbots here - it<br> *used* to compile just fine, but since the latest patch (removing the<br> "manual" dynamic linking stuff), it fails with<br> <br> openvpnserv-interactive.o:inte<wbr>ractive.c:(.text+0xee2): undefined reference to `InitializeUnicastIpAddressEnt<wbr>ry'<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 'InitializeUnicastIpAddressEnt<wbr>ry'</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 "16.04 is what you need" - that would work<br> for me, as cross-building is really not "I have this <any breed of unix<br> OS> and want to build and run OpenVPN here!" building... (I have much<br> stricter requirements wrt breaking platforms for "run here" 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 "InitializeUnicastIpAddressEntr<wbr>y" would be nice (and making configure gently complain like "please use Ubuntu 16.04") </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
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.
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); }