Fix NetBSD executable path

[time-killer-games]

No description provided.

[Riteo]

The branch looks sound but I wonder whether it'd make more sense to avoid duplicating the exact same code twice with something like this:

#elif defined(__NetBSD__) || defined(__FreeBSD__)
#if defined (__NetBSD__)
	int mib[4] = { CTL_KERN, KERN_PROC_ARGS, -1, KERN_PROC_PATHNAME };
#elif
	int mib[4] = { CTL_KERN, KERN_PROC, KERN_PROC_PATHNAME, -1 };
#endif // defined(__NetBSD__)
	char buf[MAXPATHLEN];
	size_t len = sizeof(buf);
	if (sysctl(mib, 4, buf, &len, nullptr, 0) != 0) {
		WARN_PRINT("Couldn't get executable path from sysctl");
		return OS::get_executable_path();
	}
	String b;
	b.parse_utf8(buf);
	return b;

It's a bit uglier as I don't think that we can indent defines according to our style guide but I suppose it's going to be always the same basic structure across BSDs?

[time-killer-games]

Yeah I was wondering how you felt about that. I reviewed former code and it appeared you guys preferred having separate copies of code for each platform, but I am more than happy to remove the redundancy. I wanted to do that initially as my personal preference, but I wasn't sure what everyone else's thought was on the matter.

Thank you for the code review. I will make that change now.

[time-killer-games]

In regards to structure, DragonFly BSD uses the exact same code as as FreeBSD 1:1 without a single line touched. OpenBSD doesn't even have this feature implemented OS-level by contrast.

[time-killer-games]

I can revert my commit I just made if everyone decides to stick with my original code change that kept the duplicate code, though, I wouldn't recommend it. I prefer what you suggested.

[time-killer-games]

Additionally, there is a bug with NetBSD that if argv[0] is a relative path (for example: ./a.out) it will return an absolute path by KERN_PROC_PATHNAME sysctl(), though in my experience, it keeps the "relative dots" in the string. For example, if argv[0] is ./a.out, KERN_PROC_PATHNAME will give you a path looking like /home/netbsd/./a.out for example, when we would want /home/netbsd/a.out instead. So, my proposal is to clean up after this NetBSD bug and normalize the pathname with a call to realpath. Just my thought on this. There are other cases where it keeps the relative dots iirc, I just can't recall when. realpath would fix it. FreeBSD doesn't have this bug, so that would be a strenuous call to realpath for no reason, meaning we would have to make the code even more difficult to read by adding an additional #if defined(...) to address this.

[Riteo]

Additionally, there is a bug with NetBSD that if argv[0] is a relative path

Oh, I had no idea.

If that's the case then unfortunately I think it might make more sense to copy-paste two branches, one with realpath for NetBSD and one without it for FreeBSD 😅

Sorry for the backward and forwards and thanks for your patience :)

[time-killer-games]

No problem! Sure thing.

[time-killer-games]

I forgot to use a proper commit message for that last one. My bad.

[Riteo]

Great!

I forgot to use a proper commit message for that last one. My bad.

Note that we don't accept PRs with multiple commits (and we have disabled squash-merging for various reasons), so you'll have to squash them yourself, where you will also be able to rename the resulting commit.

You'll be rewriting history, so don't be afraid of force-pushing!

There's a guide in the documentation explaining the process: https://docs.godotengine.org/en/stable/contributing/workflow/pr_workflow.html#the-interactive-rebase

[time-killer-games]

I still only know the bare basics of git commands. This will be an interesting adventure. lol

[AThousandShips]

One final nitpick, please remove the remark in the commit message, no need to make such a comment

[time-killer-games]

Great!

I forgot to use a proper commit message for that last one. My bad.

Note that we don't accept PRs with multiple commits (and we have disabled squash-merging for various reasons), so you'll have to squash them yourself, where you will also be able to rename the resulting commit.

You'll be rewriting history, so don't be afraid of force-pushing!

There's a guide in the documentation explaining the process: https://docs.godotengine.org/en/stable/contributing/workflow/pr_workflow.html#the-interactive-rebase

I believe I did it right. Correct?

[time-killer-games]

One final nitpick, please remove the remark in the commit message, no need to make such a comment

I'll look up real quick how to remove that. Thanks for the info. Yeah, I should've thought of that.

[AThousandShips]

git commit --amend and update the message :)

[time-killer-games]

Thanks a ton!

[Riteo]

Looks fine! :)

[akien-mga]

Thanks! And congrats for your first merged Godot contribution 🎉

[YuriSizov]

Cherry-picked for 4.2.2.