Almost all numeric COMPlus_/DOTNET_ environment variables are treated as hexadecimal, because CLRConfig::GetConfigValue has always worked that way:

runtime/src/coreclr/pal/src/init/pal.cpp

Lines 413 to 415 in 01b7e73

    
           // Like all numeric values specific by the COMPlus_xxx variables, it is a 
        
           // hexadecimal string without any prefix. 
        
           long int flag = strtol(useDefaultBaseAddr, NULL, 16);

runtime/src/coreclr/utilcode/clrconfig.cpp

Line 241 in 01b7e73

DWORD configMaybe = wcstoul(val, &endPtr, 16); // treat it has hex

We have this behavior documented for GC configuration settings (COMPlus_GCHeapCount, COMPlus_GCHeapHardLimit,
COMPlus_GCHeapHardLimitPercent, COMPlus_GCHighMemPercent, etc.):

For number values, use decimal notation for settings in the runtimeconfig.json file and hexadecimal notation for environment variable settings. For hexadecimal values, you can specify them with or without the "0x" prefix.

For a couple of other numeric options we have added custom processing to treat them as decimal.

I do not have a strong opinion here, but I do not see why it could be unexpected for the PROCESSOR_COUNT to be treated as hexadecimal given that GCHeapCount and other options have been treated as hexadecimal for a number of .NET releases.

especially if it is going to be used frequently like DOTNET_PROCESSOR_COUNT

I consider using this setting rather an advance scenario.

	// Like all numeric values specific by the COMPlus_xxx variables, it is a
	// hexadecimal string without any prefix.
	long int flag = strtol(useDefaultBaseAddr, NULL, 16);

DOTNET_PROCESSOR_COUNT is a hex value -- should be decimal #53150

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`DOTNET_PROCESSOR_COUNT` is a hex value -- should be decimal #53150