[gdal-dev] CPLCalloc() used for small memory allocations. And for big ones?

[Even Rouault]

Le 14/02/2024 à 10:00, Laurențiu Nicola via gdal-dev a écrit :
> Hi,
>
> On Wed, Feb 14, 2024, at 10:53, Abel Pau via gdal-dev wrote:
>>
>> Hi,
>>
>> I am currently working on a driver and have been utilizing 
>> CPL_calloc(). However, when attempting to pass the Actions, I 
>> encounter errors such as:
>>
>> warning C4244: 'function': conversion from 'MM_INTERNAL_FID' to 
>> 'size_t', possible loss of data
>>
>> This issue can be addressed by casting 'MM_INTERNAL_FID' (which is a 
>> GUInt64, essentially an unsigned long long) to 'size_t' (also 
>> essentially an unsigned long long). So, utilizing a cast is not 
>> problematic in this context.
>>
> The warning makes sense on 32-bit platforms, where that cast will be 
> problematic.
>
> However, while I didn't check what MM_INTERNAL_FID is, it doesn't 
> sound like something calloc() would take.
Agreed: if a cast to size_t is done, a range check should be done first 
if the value might be larger than std::numeric_limits<size_t>::max(), 
which might be true on 32-bit builds
>
>> However, I noticed in the function description it states "used for 
>> small memory allocations," which prompts me to inquire if there is an 
>> alternative calloc function for larger memory allocations
>>
> "Small" probably means "infallible" here. If you want a fallible 
> allocation (which you're supposed to handle), you can use VSICalloc(), 
> VSIMalloc() etc.
Agreed
>
> Laurentiu
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240218/cf462540/attachment-0001.htm>