Comments (4)
Where can I find such allocator override in STB project? I have glimpsed
stb_image.h
but allocators used there is macro-based approach(STB_MALLOC, STB_FREE, ...).
You're right, it's not consistent in all the STB libs. I saw this in stb_image_resize2.h:
https://github.com/nothings/stb/blob/ae721c50eaf761660b4f90cc590453cdb0c2acd0/stb_image_resize2.h#L69
So we'd be better to introduce callback functions for memory allocations, something like...
That's definitely the cleanest approach! realloc
isn't used in TinyEXR though, correct? I'd be careful about adding it as a required part of the callback since some custom allocators don't support it, and in my experience there are subtleties to how realloc is expected to behave in various cases. But it could be optional, ie. if it's not supplied emulate it using malloc -> memcpy -> free. As long as you don't see a need for it though, maybe just stick to malloc and free?
from tinyexr.
Hi, I'm currently looking into adding custom allocator support to TinyEXR. I started by simply replacing malloc/free with TINYEXR_MALLOC / TINYEXR_FREE macros that I can define within the cpp implementation file, to route allocations to a custom global allocator. This is a rather unintrusive change, easy to whip up a small PR for.
However, the STB libraries implement allocator overrides with a user-supplied context void *
, which allows to use a different allocator depending on use case / thread index / etc. That would be my preferred way to handle it in TinyEXR. Doing that would mean passing down the pointer to all functions that allocate memory. Would you agree that it would be worthwhile? Maybe this is something you thought about doing anyway for this particular issue?
Since I don't want to maintain my own fork, I'd rather not do this work without a chance that it can be contributed back.
Looking forward to hearing your thoughts, and thanks for your work on the library!
from tinyexr.
👍 > I'm currently looking into adding custom allocator support to TinyEXR
the STB libraries implement allocator overrides with a user-supplied context void *
Where can I find such allocator override in STB project?
I have glimpsed stb_image.h
but allocators used there is macro-based approach(STB_MALLOC, STB_FREE, ...).
https://github.com/nothings/stb/blob/master/stb_image.h
Anyway, yes, having userdata pointer is the preferred approach.
So we'd be better to introduce callback functions for memory allocations, something like...
struct EXRMemoryAllocatorCallback
{
void* (*malloc)(size_t n, void *userdata);
void* (*realloc)(void *p, size_t newn, void *userdata);
void (*free)(void *ptr, void *userdata);
};
(FYI stb_image uses this approach in io callback https://github.com/nothings/stb/blob/ae721c50eaf761660b4f90cc590453cdb0c2acd0/stb_image.h#L410 )
We'll then need to introduce new API which takes this callback in its argument
bool load_exr(..., EXRMemoryAllocatorCallback *cb, void *userdata);
void exr_free_image(..., EXRMemoryAllocatorCallback *cb, void *userdata);
For backward compatibility, existing API uses default allocator.
from tinyexr.
Oh, Thanks! > I saw this in stb_image_resize2.h
realloc isn't used in TinyEXR though, correct?
Yes, realloc is not used in TinyEXR, so we can omit it. just malloc
and free
!
from tinyexr.
Related Issues (20)
- Warnings when compiling with VS2019 and W3 (32 bit) HOT 5
- Windows install HOT 1
- Heap-buffer-overflow exists in the DecompressPiz HOT 2
- Heap-buffer-overflow exists in the DecodePixelData HOT 2
- [TODO] Support nested layer name
- Got "-Wreserved-identifier" compiler warning when compiling with Clang-13.0.1 HOT 4
- Use wuffs for fast & secure ZIP/LZW decoding/encoding HOT 3
- UBSan issue when loading an .exr HOT 2
- compilation error on 1.0.1 with ZFP HOT 2
- "Failed to read attribute" error message on Big Endian platform? HOT 2
- [TODO] Setup Github Actions CI build
- memory error in tinyexr::InitSingleResolutionOffsets HOT 3
- [TODO] [Improve Security] Remove assert HOT 1
- PIZ decompression error with tinyexr 1.0.2 HOT 5
- Three Bugs in tinyexr.h HOT 2
- SEGV on unknown address in tinyexr.h:5779 HOT 2
- allocator is out of memory HOT 1
- Problems decoding several OpenEXR reference files HOT 2
- The vulnerability is a memory leak bug located at line 9291 of the file /tinyexr/tinyexr.h
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tinyexr.