Hi, > But then making the variable static just to keep a valid pointer beyond the > current block local looks like a kludge. For me seeing static applied to a > variable scoped to a block is just confusing and unusual style. Think of > this: if > you remove that static the code may still build and even work on some > compilers depending on optimization level etc. and mysteriously fail on some > occasions. From that one could either conclude a static qualifier is required > her or the variable is wrongly scoped. I think the latter conclusion is the > 'right' > one and static is a misuse. > > As for the combination 'static const ...', it has a place and that is for > constants > defined outside functions to limit the scope of an otherwise global const to > that of the compilation unit. > > It may be just me.
Not necessarily. It may be just *me*. :) Anyway, you got me convinced and I shall move those structs from data segment to stack in the next version of the patch. > I like it: using "OpenVPN" as a kind of namespace also avoids name collision > with any other 'foobar' installed in HKLM\Software\foobar Exactly, introducing instances is all about avoiding namespace collisions. > Not sure I follow, but will wait for the patch. I suppose naming additional > instances as, say, 'foo' using the official package and have service pipe, > exit > event etc named after it and registry keys taken from HKLM\Software\foo > will still work. In the v1 and v2 patches, yes. But in v3 patch, the PACKAGE/PACKAGE_NAME is always used as the prefix/namespace. This way we impose the "OpenVPN" branding to all instances by compile-time default. In v3, people can't take the interactive service and make it disguise as the "Microsoft\Office\Automatic Update". The v3 made instancing less flexible on purpose. If you disagree, I can revert to v1/2 behaviour. > In fact I like the current patch in that it allows installing even the > official > instance as a named one with name = OpenVPN and thus decouples > automatic and interactive services. That makes it easy to avoid installing the > legacy service, which I think no one uses anymore. Ouch. *We* would use the automatic service if it was coded slightly different. I didn't know the legacy automatic service is on the obsolete list yet. Perhaps, a true replacement for the automatic service could be to make the openvpn.exe itself to be able to install and run as a Windows service (--daemon for Windows): - The SCM would restart it, should openvpn.exe terminate or crash. - Separate openvpn.exe service for each ovpn configuration, allowing admins to manage them individually. - Linux like behaviour, where you run each tunnel as a separate Systemd daemon. (That is exactly what I'd need for our office. Right now we are wrapping openvpn.exe inside a NSSM service helper. Would be nice to get that feature out-of-the-box.) Back to the interactive service... According to the latest [PATCH( v3 missing)], one would need to start the default instance of the interactive service only using the following service command line: openvpnserv.exe -instance interactive "" A bit odd for the command line. Again, I can revert to v1/2 behaviour and let the end-users select the whole instance name at run-time. 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 _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
