Fix checkptr in Mem.Get() on darwin

[jorbaum]

Lets the tests run through on MacOS ARM by properly using Sysctl.

Credit goes to
elastic@2c63039

[aramprice]

@jorbaum - thank you for taking a stab it getting this working on macOS!

Seems like the windows build is failing - I re-ran it just in case there was a flake and still got a failure.

It would be nice to enable macos-latest in the test workflow:

• https://github.com/cloudfoundry/gosigar/blob/master/.github/workflows/go.yml#L20

[jorbaum]

It would be nice to enable macos-latest in the test workflow:

Did so.

[jorbaum]

Regarding the failing windows build:

• The error is related to the wmic not being found.
• AFAICS wmic is deprecated and has been removed from newer versions of windows, see https://learn.microsoft.com/en-us/windows/whats-new/deprecated-features
• My best guess is that the newest windows images therefore do not come preinstalled with wmic and gosigar is failing due to that. Likely unit tests have not been run for a while on windows.
• The good news is that elastic/gosigar appears to have a solution implemented for that as well: Replace wmi queries with win32 api calls elastic/gosigar#116 .

However, I would not see this as part of this Pull Request. Also, it is difficult to test for me as I do not have a windows development machine.

[aramprice]

@jorbaum - it looks like the main branch is currently succeeding on Windows[1] so it seems like there is something in this PR which is causing the windows issue[2].

Perhaps you can use this PR (or another) to bring over the Win32 changes, and rely on the github worker tests to verify?

Thanks,

-aram

[1] https://github.com/cloudfoundry/gosigar/actions/runs/17929963955/job/50984988021
[2] It could also be the case that github workers have changed in the past five days.

[jorbaum]

@jorbaum - it looks like the main branch is currently succeeding on Windows[1] so it seems like there is something in this PR which is causing the windows issue[2].

Thx. I did not see that it worked two weeks ago. AFAICS:

• last time it worked OS version is reported as "Microsoft Windows Server 2022"
• In this PR action run OS version is reported as "Microsoft Windows Server 2025"

I guess that this is the issue. This PR should not change any windows-related code as it only changes the darwin file.

Perhaps you can use this PR (or another) to bring over the Win32 changes, and rely on the github worker tests to verify?

Looks like @rubionic is already taking on this task. Thanks!

@aramprice As a quick fix I could change windows-latest to windows-2022? What do you think?

[aramprice]

@jorbaum - I think switching to windows-2022 is ok if we're still blocked by Thursday (Foundation Infrastructure working group meeing).

I'm hoping that @rkoster / @rubionic will get the other PR fixed up in the next few days and we can keep the actions windows-latest.

[jorbaum]

@jorbaum - I think switching to windows-2022 is ok if we're still blocked by Thursday (Foundation Infrastructure working group meeing).

Did so.

[beyhan]

@jorbaum thank you for this contribution!