ScarletDME 64bit observations / Questions for C gurus

52 views
Skip to first unread message

Nextjob

unread,
Mar 10, 2024, 2:45:58 PMMar 10
to ScarletDME
Please forgive my ignorance here, I am relatively new to c programming.

During conversion of the qmclient api to something MSVC will compile, I ran into this issue (along with others*):
 "warning C4267: '=': conversion from 'size_t' to 'int32_t', possible loss of data"
This is a result of using the strlen function which returns type size_t (now 64 bit) and assigning it to an int (32 bit).
Interesting thing is, GCC does not seem to complain about this (unless I am missing the correct -W setting).

I would think the area of concern would be with data coming from outside the ScarletDME environment (the client api, reading data from a directory file and so on).

So what is the appropriate course of action?
Declaring the variable receiving the strlen return value to type size_t is simple enough, but what about when the value is stored into ScarletDME's variable space (DESCRIPTOR structures)?

Is it enough to validate that the string length conforms to the maximum record size (around 2Gb?) then type cast the size_t to int prior to assignment into a DESCRIPTOR (just removes the warning)?

I also have questions about the use of strcpy.  From what I have read, use of strcpy is strongly discouraged, however there seems to be a wide range of opinions on what to use in its place (strncpy, strlcpy and now strscpy, which is not available in glibc).

I found an interesting comparison of the above in the following reddit post about "Git's list of banned C functions"  

https://www.reddit.com/r/C_Programming/comments/ly0ydt/gits_list_of_banned_c_functions/

I would guess there are alternate views on the subject. Regardless, what are the project maintainers' view on the subject?

Thanks.

* there are also issues with pointer math assigning the result to type int, usually when moving character data around.
Reply all
Reply to author
Forward
0 new messages