Description
The definition and recommended use of the csize_t (is uint) type instead of the depreciated csize (is int) type has been only partially adapted to the current code base, leaving library code that cannot compile depending on the choice of compiler switches used...
Example
A blank "*.nim" file, compiled with the "--gc:regions" compiler switch, although this is just one of many possible compiler switch choices that may lead to a compiler error due to this change.
Current Output
...\lib\system\gc_regions.nim(381, 20) Error: type mismatch: got <Natural>
but expected one of:
proc c_malloc(size: csize_t): pointer
first type mismatch at position: 1
required type for size: csize_t
but expression 'size' is of type: Natural
expression: c_malloc(size)
Expected Output
Compiles successfully.
Possible Solution
The csize_t PR needs a complete code review and should have csize_t used instead of csize in every case with a view to an explicit conversion used where it is passed a value which could be int-derived such as Natural.
However, I see from the issue #12187 and its related commits that it is still not clear whether the definition of csize_t == uint is to be accepted or not. This needs to be decided and either csize_t kept and consistently used throughout with csize depreciated or csize_t completely obliterated from the devel code base and csize used as before.
Additional Information
It seems to me that there are several places where there are potential compiler errors caused in this way, as in anywhere c_malloc is called with a Natural argument; However, there also exists definitions of c_malloc with a csize argument, as in the change to csize_t has been inconsistently applied or reverted.
Tested on the latest devel branch as of 3-11-2019
$ nim -v
Nim Compiler Version 1.1.0 [Windows: amd64]
Compiled at 2019-11-03
Copyright (c) 2006-2019 by Andreas Rumpf
active boot switches: -d:release
Activity