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

2024-02-18 Thread Even Rouault via gdal-dev 


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::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@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

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

2024-02-14 Thread Laurențiu Nicola via gdal-dev 
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.

> 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.

Laurentiu
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

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

2024-02-14 Thread Abel Pau via gdal-dev 
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.

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. If not, I will proceed with casting the 
variable in all instances. Nonetheless, I would appreciate knowing if there is 
a cleaner solution available.

Thank you for your assistance.

//
/* CPLCalloc()  */
//

/**
* Safe version of calloc().
*
* This function is like the C library calloc(), but raises a CE_Fatal
* error with CPLError() if it fails to allocate the desired memory.  It
* should be used for small memory allocations that are unlikely to fail
* and for which the application is unwilling to test for out of memory
* conditions.  It uses VSICalloc() to get the memory, so any hooking of
* VSICalloc() will apply to CPLCalloc() as well.  CPLFree() or VSIFree()
* can be used free memory allocated by CPLCalloc().
*
* @param nCount number of objects to allocate.
* @param nSize size (in bytes) of object to allocate.
* @return pointer to newly allocated memory, only NULL if nSize * nCount is
* NULL.
*/

Abel Pau Garcia
GIS developer
[https://www.creaf.cat/sites/default/files/creaf-signature.png]
a@creaf.uab.cat
Let's chat on 
Teams!
Tel. +34 934814277
[https://www.creaf.cat/sites/default/files/so-en-signature.png]
[https://www.creaf.cat/sites/default/files/twitter-icon-signature.png][https://www.creaf.cat/sites/default/files/linkedin-icon-signature.png][https://www.creaf.cat/sites/default/files/youtube-icon-signature.png][https://www.creaf.cat/sites/default/files/instagram-icon-signature.png]
www.creaf.cat | http://blog.creaf.cat
[https://www.creaf.cat/sites/default/files/uab_logo_signatura.png]
CREAF. Campus UAB. Edifici C. 08193 Bellaterra (Barcelona)

Before printing this electronic message, think about the environment.



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev