I have found include for inttypes.h and typedefs for almost every type in V except int. Am I right to suspect int it therefore an ordinary C int type and only u32 is properly defined as an unsigned int always with size of 32 bits?
If that's the case, I've read about int not always being 32-bit which brings a question - shouldn't we use typedef int32_t i32 or typedef int32_t int instead? See khrplatform.h for ensuring always having 32-bit int size.
I just tried it:
V-code
fn main() {
a := 539
print(a.str())
}
C-code
void main__main() {
int a= 539 ;
print ( int_str( a ) ) ;
}
I also noticed a lot of boilerplate code in the c tmp output (like the source file has 79K)...
The C source file is indeed huge and we are aware of that. It is on our roadmap to fix that soon.
As @KeyWeeUsr points out, int is indeed just int and therefore we can't guarantee the size of that data type. This should be fixed.
@gslicer there are 2.5k lines of vlib in that C file, that's not a lot. It will be cached anyway.
@KeyWeeUsr indeed, int32_t should be used.
Same applies for bool using plain int and other int derived types imho otherwise it might kick back hard. However once we are limiting the design to fixed sizes instead of relative/range sizes we're lowering the portability of the language.
for bool 'int' is overkill (even the samallest) 'byte' (u8) should be sufficient
@gslicer while I agree totally, it'll break the compatibility for all previous versions in case someone played with the container in an unsafe manner. It might also kill off the compiler since a brief github search shows just bool and not C.bool everywhere.
So to ensure having the interface with C there'd either need to be C.bool and other C.<type> alternatives or keeping bool at the max and stable size of all implementations available by default if we want to go the way of having fixed-size types instead of C-like range types.
Indirectly related to this are #2684 #2876 as they deal with what integer size to associate with integer literals.
Most helpful comment
The C source file is indeed huge and we are aware of that. It is on our roadmap to fix that soon.
As @KeyWeeUsr points out,
intis indeed justintand therefore we can't guarantee the size of that data type. This should be fixed.