Increase buffer size from 200 to 32767

[RebeccaBecky]

To fully support lsi records

[RebeccaBecky]

Increasing the buffer size works for my use case but I don't know if this could have any unintended consequences.

[kasemir]

Just recently ran into this long string autosave limitation, thank you for fixing it!

From a brief glance at the code, your fix should be fine.
The larger buffer is used in the methods that read or write the files.
No matter if you have 1 or 10000 channels handled by autosave, there's just one BUF_SIZE buffer.
I would worry if each tracked channel holds something of BUF_SIZE, so a setup with 10000 channels would now explode, but that doesn't seem to be the case.
That BUF_SIZE buffer, however, is on the stack, as in

write_it(char *filename, ...
{...
   char value_string[BUF_SIZE];
...

This could be a problem for embedded system that don't have much stack space

[RebeccaBecky]

Thanks for having a look!

That's a very good point about the stack usage.

Would it be preferable to try and use a dynamic array?

[kasemir]

dynamic array

Well, especially on embedded systems you'd like to avoid malloc and free at runtime because that can result in memory fragmentation. Reserve memory at startup and then just keep re-using it.
Keeping the temporary buffer on the stack seems fundamentally the right approach.

Not sure about the best answer.

Keep a fixed BUF_SIZE but define it somewhat like this?

#ifdef RTEMS
#define BUF_SIZE ..smaller..
#else
.. larger..

Maybe define BUF_SIZE based on the existing EPICS stack size variables which already vary with the OS?

Or just prominently mention the BUF_SIZE in a README file: "You have to adjust BUF_SIZE for your local needs..."?

[MarkRivers]

Note that calloc() is already being used for long strings in 2 places:

autosave/asApp/src/save_restore.c

Line 1338 in 5e5957b

pchannel->pArray = calloc(BUF_SIZE, sizeof(char));

autosave/asApp/src/save_restore.c

Line 1523 in 5e5957b

pchannel->pArray = calloc(BUF_SIZE, sizeof(char));

BUF_SIZE is being used for different kinds of buffers, some of which are not used for long strings. We could create a new LONG_STRING_BUFF_SIZE which is used only for long strings.

One possibility might be to allocate the buffer as part of the chlist structure:

autosave/asApp/src/save_restore.c

Line 216 in 5e5957b

struct chlist { /* save set list element */

The would result in one large buffer per save set. But there are typically only a few save sets open, so the total memory impact would be small, and it is not on the stack.

One would need to look at the threading to make sure the list is not being used by multiple threads, but if it is it should already be protected by a mutex.