Handler data_size casting limits it to u16 precision per entity write about librg

[inlife]

I'll look for optimal ways of upgrading this capacity

[inlife]

Hey @trsh !

I've released a new version with an optional (at least for now) compile-time flag that extends the event limit from u16 to i32. I know it's not ideal size of u32, but should still be a viable option.

The flag is LIBRG_ENABLE_EXTENDED_EVENTBUFFER.. It needs to be defined for the source part in the following fashion:

#define LIBRG_ENABLE_EXTENDED_EVENTBUFFER
#define LIBRG_IMPL
#include "librg.h"

If the application is networked, both sides should have this defined.

I've also added runtime checks for the event buffer sizes, so at least the there will be some awareness about this issue, and updated the docs.

Let me know if that helps!

[inlife]

This works exactly as you've mentioned in your update part of the comment. The maximum data size in this context would be of u16 size. Since the negative value would be used to mark this update as rejected and to try again in the next method call.

But you've raised a good point; it seems like I forgot to add a notion somewhere that the size of this buffer is limited. Nor does it do any bound checking to prevent any bigger-sized data from being written.

[inlife]

Now I'm also wondering if u16 was too small for the job and u32 would be more beneficial in this specific case. Any thoughts on that?

[trsh]

Now I'm also wondering if u16 was too small for the job and u32 would be more beneficial in this specific case. Any thoughts on that?

Yes. I think, u16 is small. With u32 we could create bigger writes per entity and its up to the library user to lower/split it, if this creates other kind of problems.

[trsh]

Closing this, as it seems to work as expected after some quick tests with my project.

Thank you!

I will open a new issue, if I encounter any problems regarding this.