Vega-strike-engine-source: Use POSIX-standard code to determine the maximum path length, on each OS except Windows

[stephengtuggy]

... in vsfilesystem.cpp (instead of hard-coding a specific value, even as a constant).

[stephengtuggy]

Relates to #186

[BenjamenMeyer]

So in general, most of the functions work the same. The odd man out is Windows because as usual Microsoft has to do their own thing.

That said, we can probably make a lot more use of Boost to overcome the issues. Boost:: Filesystem can handle most all of it in a platform agnostic way that even works on Windows.

[stephengtuggy]

Boost::Filesystem does sound like a good option.

With that said, I guess what I meant was,

"Use POSIX-standard code... for all OS's except Windows." :smile:

[stephengtuggy]

Filed a separate ticket for the Boost::Filesystem proposal.

[nabaco]

Why do we concentrate on POSIX-standard here? I would say that we should either use platform agnostic code (e.g. boost), or use platform specific libraries (including windows)

[stephengtuggy]

Just that it seems easiest to me to cover all the bases with two code paths: the Windows one, and then the POSIX one for everything else. (Because everything else reasonably modern is compliant with the latter standard.)

[BenjamenMeyer]

I agree that we should move away from using platform specific stuff as much as we can - boost::filesystem is great for doing that.

The big differences between POSIX and Windows is:

• Microsoft has their own "safe" versions for many thing and generates warnings if you use the actual POSIX standard calls.
• The POSIX specification leaves a lot open to interpretation; most Unix and Linux generally agree on how stuff works; Microsoft took all the liberty they could to make things incompatible and it shows, enough so that you have to write layers to manage the differences.

So Microsoft is technically POSIX compliant; just like they're technically ODF compliant too, but they ignore do everything they can to make incompatibilities to be dependent on their stuff.

All-in-all, we can write and maintain layers, but it's probably counter-productive to our goal. Using a widely available and widely tested library like Boost::FileSystem would be a better way to go and alleviate us from having to maintain the detailed stuff that doesn't really matter to us.

Also, why have two (or more) code-paths when you can have one?

NOTE: I'm not saying we have to specifically use Boost::FileSystem. If there's another library that solves the issue that's fine too. However, as we already use Boost it makes sense that we'd just expand to use other Boost libraries too.

[stephengtuggy]

It doesn't sound like we'll be going this route, so I'll close this ticket in favor of the other one.

[royfalk]

I think I have something in the works that used boost for some file operation. Let's move this to a gitter room?

Get Outlook for Androidhttps://aka.ms/ghei36

---

From: Benjamen Meyer [e-mail]
Sent: Thursday, July 23, 2020 5:56:12 AM
To: vegastrike/Vega-Strike-Engine-Source [e-mail]
Cc: Subscribed [e-mail]
Subject: Re: [vegastrike/Vega-Strike-Engine-Source] Use POSIX-standard code to determine the maximum path length, on each OS except Windows (#189)

I agree that we should move away from using platform specific stuff as much as we can - boost::filesystem is great for doing that.

The big differences between POSIX and Windows is:

• Microsoft has their own "safe" versions for many thing and generates warnings if you use the actual POSIX standard calls.
• The POSIX specification leaves a lot open to interpretation; most Unix and Linux generally agree on how stuff works; Microsoft took all the liberty they could to make things incompatible and it shows, enough so that you have to write layers to manage the differences.

So Microsoft is technically POSIX compliant; just like they're technically ODF compliant too, but they ignore do everything they can to make incompatibilities to be dependent on their stuff.

All-in-all, we can write and maintain layers, but it's probably counter-productive to our goal. Using a widely available and widely tested library like Boost::FileSystem would be a better way to go and alleviate us from having to maintain the detailed stuff that doesn't really matter to us.

NOTE: I'm not saying we have to specifically use Boost::FileSystem. If there's another library that solves the issue that's fine too. However, as we already use Boost it makes sense that we'd just expand to use other Boost libraries too.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/vegastrike/Vega-Strike-Engine-Source/issues/189#issuecomment-662795075, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACQWBEBPB5RMF3XB54OTUYLR46REZANCNFSM4PFGUHZQ.

[BenjamenMeyer]

@royfalk certainly if we need a gitter room to discuss live more than let's do it!