if you are casting it to a size_t, that just lost the benefit of handling the case when this returns -1. we haven't seen this read -1, but then again, we didn't know sysconf could return -1 either. I thought you wanted to handle that scenario?

The function cannot set the cache_size_from_sys_file to -1 and still return true. The only theoretical case when it could happen would be if the file contained literally -1. The file is generated by the kernel and it either has a value or it doesn't exist if the corresponding cache level information is not available. The sysconf case was different, it is documented to return -1 in error cases like the case when we ask it for a value that it cannot provide.

doesn't seem worth it to me to depend on theoretical case not happening when you can so trivially handle it and make it consistent from what it's done so far in this function.

make it consistent from what it's done so far in this function.

It is done in one place in this function that needs it. It is not consistently done in this function.

For example,

If you would like to protect against bogus cache sizes, it would be best to do it at the very end of the function or even in the calling code in the GC. For example, ignore the cache size if it is more than 1GB.

The point is that theoretically, that function could return any value if the kernel generated wrong contents of those virtual files due to some bug. So it doesn't seem to be useful to handle one specific case explicitly. If there was a bug, it can as well contain -2 or 1234567890 or whatever random number. As I've said, it is very different from the sysconf where the -1 is valid and documented return value that we've just forgotten about.