Closed winspool closed 3 months ago
I don't understand what you are trying to fix. Many unrelated confusing info, but no core problem description. Why the array must be initialized? It looks like symptom of different problem, but without problem description I can not accept something strange what probably mask different problem.
I don't understand what you are trying to fix.
sysconf(_SC_NPROCESSORS_ONLN)
Many unrelated confusing info, but no core problem description.
The sysconf(_SC_NPROCESSORS_ONLN)
returns different broken results.
Examples: 175, 163, 177, 171, 180
(With my fix, 12 is returned every time)
Why the array must be initialized?
The number of "1" bits in the whole array are counted. The kernel syscall does not set the unused memory in the buffer to 0.
It looks like symptom of different problem,
You can see with this diff, how that function works: 0000_debug_sysconf_nprocessors.txt
Example output (I even tried with different optimization level): _out_nproc.txt
but without problem description
I named the broken funktion (sysconf(_SC_NPROCESSORS_ONLN)
) and added a simple testcase.
Unfortunately, i forgot the example output, but using the small testcase before and after my fix is easy.
but uninitialized array has nothing to do with problem. It is wrong implementation of __sysconf_nprocessors which not handle any error, cpu count etc. I suppose that array should be zeroed not fill by 1's.
If I read info about kernel call sched_getaffinity then it should return size of array which is setup by this call. That it should be checking only such range.
Thank you for your contribution.
Needed to fix sysconf(_SC_NPROCESSORS_ONLN)
Small testcase:
The initialization of the 128 byte array increases the resulting program by 512 byte, because OpenWatcom creates 128 mov instructions (even with owcc -Os`), but that is a different issue.
-- Regards ... Detlef