Make MSVC happy about route.c
PATCH 1/1 Make MSVC happy about route.c
Move the definition of out to the beginning of functions to comply with old-style C compilers. Tested on MSVC 2010.
--- src/openvpn/route.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
src/openvpn/route.c +8 -3
@@ -1551,6 +1551,9 @@ add_route_ipv6 (struct route_ipv6 *r6, const struct tuntap *tt, unsigned int fla {struct gc_arena gc;struct argv argv; +#ifdef WIN32 +struct buffer out; +#endif const char *network;const char *gateway;
@@ -1622,8 +1625,7 @@ add_route_ipv6 (struct route_ipv6 *r6, const struct tuntap *tt, unsigned int fla status =openvpn_execve_check (&argv, es,0 ,"ERROR: Linux route -6/-A inet6 add command failed" );#elif defined (WIN32 ) - -struct buffer out =alloc_buf_gc (64 , &gc); + out =alloc_buf_gc (64 , &gc);buf_printf (&out,"interface=%d" , tt->adapter_index ); device =buf_bptr (&out);
@@ -1900,6 +1902,9 @@ delete_route_ipv6 (const struct route_ipv6 *r6, const struct tuntap *tt, unsigne {struct gc_arena gc;struct argv argv; +#ifdef WIN32 +struct buffer out; +#endif const char *network;const char *gateway;const char *device = tt->actual_name;
@@ -1958,7 +1963,7 @@ delete_route_ipv6 (const struct route_ipv6 *r6, const struct tuntap *tt, unsigne#elif defined (WIN32 ) -struct buffer out =alloc_buf_gc (64 , &gc); + out =alloc_buf_gc (64 , &gc);buf_printf (&out,"interface=%d" , tt->adapter_index ); device =buf_bptr (&out);
Signature · 1 line
2.6.4
ACK.
I don't have VC2010, but at least on 2013 it compiles nicely.
Hi,
Quoted 2 lines · Fish
Move the definition of out to the beginning of functions to comply with old-style C compilers. Tested on MSVC 2010.
[..]
src/openvpn/route.c add_route_ipv6 (struct route_ipv6 *r6, const struct tuntap *tt, unsigned int fla · line 1630
Quoted 6 lines
#elif defined (WIN32)
src/openvpn/route.c +1
-2- -struct buffer out =alloc_buf_gc (64 , &gc); + out =alloc_buf_gc (64 , &gc);buf_printf (&out,"interface=%d" , tt->adapter_index ); device =buf_bptr (&out);
As things turns out, this is now actually no longer needed in the release/2.3 branch, as with the new code from Lev, this looks like:
#elif defined (WIN32)
if (win32_version_info() != WIN_XP)
{
struct buffer out = alloc_buf_gc (64, &gc);
buf_printf (&out, "interface=%d", tt->adapter_index );
device = buf_bptr(&out);
}... and as such, avoids this VS2010 pitfall (thanks anyway!).
Master still has problematic code here, so if VS2010 compatibility is desired, I'd appreciate a patch for it.
gert
Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]...
fax: +49-89-35655025 [email protected]...Thanks for your response. I'll ship a patch for master soon :-)
Best,
Fish
-----Original Message-----
From: Gert Doering [mailto:[email protected]...]
Sent: Friday, January 8, 2016 10:23 AM
To: Fish <[email protected]...>
Cc: [email protected]
Subject: Re: [Openvpn-devel] [PATCH] Make MSVC happy about route.c
Hi,
Quoted 2 lines · Fish
Move the definition of out to the beginning of functions to comply with old-style C compilers. Tested on MSVC 2010.
[..]
src/openvpn/route.c add_route_ipv6 (struct route_ipv6 *r6, const struct tuntap *tt, unsigned int fla · line 1630
Quoted 6 lines
#elif defined (WIN32)
src/openvpn/route.c +1
-2- -struct buffer out =alloc_buf_gc (64 , &gc); + out =alloc_buf_gc (64 , &gc);buf_printf (&out,"interface=%d" , tt->adapter_index ); device =buf_bptr (&out);
As things turns out, this is now actually no longer needed in the release/2.3 branch, as with the new code from Lev, this looks like:
#elif defined (WIN32)
if (win32_version_info() != WIN_XP)
{
struct buffer out = alloc_buf_gc (64, &gc);
buf_printf (&out, "interface=%d", tt->adapter_index );
device = buf_bptr(&out);
}... and as such, avoids this VS2010 pitfall (thanks anyway!).
Master still has problematic code here, so if VS2010 compatibility is desired, I'd appreciate a patch for it.
gert
Signature · 7 lines
USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [email protected]... fax: +49-89-35655025 [email protected]...