fix rid processing on macOS

[wfurt]

#59066 made some changes how we calculate RID on macOS and it was not quite right.

The test was failing because there was embedded '\0'. So even if we add the architecture, that would be stripped with .c_str. It actually worked for 11.2.3 I started with but failed on 11.2 (no real ARM dependency IMHO)

There is still another problem. The way how the old code was written we would always return osx.11.0 from get_current_os_rid_platform even for 11.6. That does not break the test but then when we walk the graph we would end up with generic osx-arm64. So to maintain compatibility, I added special processing for 11.x (and verified with dotnet --info)

For 12.0+ the rid will be osx.12-arm64 and that match <Versions>10.10;10.11;10.12;10.13;10.14;10.15;10.16;11.0;12</Versions>

fixes#60341

[ghost]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

#59066 made some changes how we calculate RID on macOS and it was not quite right.

The test was failing because there was embedded '\0'. So even if we add the architecture, that would be stripped with .c_str. It actually worked for 11.2.3 I started with but failed on 11.2 (no real ARM dependency IMHO)

There is still another problem. The way how the old code was written we would always return osx.11.0 from get_current_os_rid_platform even for 11.6. That does not break the test but then when we walk the graph we would end up with generic osx-arm64. So to maintain compatibility, I added special processing for 11.x (and verified with dotnet --info)

For 12.0+ the rid will be osx.12-arm64 and that match <Versions>10.10;10.11;10.12;10.13;10.14;10.15;10.16;11.0;12</Versions>

fixes #60341

Author:	wfurt
Assignees:	wfurt
Labels:	area-Host
Milestone:	-

[vitek-karas]

Looks good.

[danmoseley]

Regression was after 6.0 fork right?

[agocke]

The test was failing because there was embedded '\0'.

I don't understand this -- where was the embedded '\0'?

[wfurt]

I don't understand this -- where was the embedded '\0'?

This comes from @agocke

runtime/src/native/corehost/hostmisc/pal.unix.cpp

Lines 592 to 595 in 1c949ac

	std::string release(str, size);
	ridOS.append(_X("osx."));
	ridOS.append(release);
	}

With the current code and 11.6 the size is 5 while strlen is 4.
And then later on

runtime/src/native/corehost/hostmisc/utils.cpp

Lines 211 to 221 in 1c949ac

	rid = pal::get_current_os_rid_platform();
	if (rid.empty() && use_fallback)
	rid = pal::get_current_os_fallback_rid();
	if (!rid.empty())
	{
	rid.append(_X("-"));
	rid.append(get_arch());
	}
	return rid;

So it seems like if we construct std::string that from more than we need to then we can sendup with osx.11.6 when consumed in C e.g. the -arm64 is effectively ignored.

[wfurt]

Regression was after 6.0 fork right?

yes. But we should take both to 6.0 - either now or via servicing as the original intent is to support macOS 12.

[wfurt]

LLVM AOT looks like infrastructure unrelated to the change.

[strager]

Shouldn't this read else if (major == 11)? I think line 594 will never execute because, if major==12, line 587 executes instead.

[AustinWise]

I was thinking that too. Here is a PR to fix: #60668

[wfurt]

yes, this should not be there. It somehow sneaked in when I was trying to remove the extra size calculation ;(