Change variable type to accommodate large data storages in sequencer program

[zioven]

During development of sequencer with large amount of data, we have encountered a warning when size of allocated data structure went over the size of the varSize data type.

As this is only populated from the call to sizeof operator in the following location:

sequencer/src/snc/gen_tables.c

Line 290 in f313d4c

gen_code("\t/* user var size */ sizeof(struct %s),\n", NM_VARS);

we propose that data type from this variable is updated to reflect the return value of the sizeof operator.

[anjohnson]

Analyzing the current code…

The struct program_instance (also typedef'ed as PROG) defined in src/seq/seqPvt.h already uses size_t varSize. The change here is to an unsigned field with the same name in struct seqProgram as defined in the public header src/seq/seq_snc.h which provides the static data about a program and is used for registering it.

Currently the unsigned field value gets copied into the size_t field by init_sprog() (in src/seq/seq_main.c) and isn't used elsewhere. The 2010 commit 490b7f0 changed the data type in seqPvt.h, which was originally declared as long.

This change looks appropriate and correct to me, although writing a sequence program that needs more than 2**32 bytes of storage for state variables seems surprising. It might be using more RAM and program storage than allocating memory for the largest arrays at initialization time would.

This module is owned by @bfrk who doesn't use GitHub much, so a definitive response might not be quick.

[bfrk]

The change looks reasonable to me as well. BTW, nowadays hardware with a huge amount of physical memory can no longer assumed to be uncommon or unrealistic. That said, I am also surprised that someone seems to have actually hit the 4GiB limit with, of all things, a sequencer program.

BTW. It is true that I am not very active on github, but more to the point, I can't seem to find the energy to actively maintain the sequencer any longer. I am aware that it is an important part of the EPICS toolbox and still used by a lot of people, so if there is interest in maintaining it here on github as a community maintained project (and primarily maintained with git), I would not stand in the way of doing so. I'd still be interested to see what is going on and happy to answer questions and help with reviews.

[ralphlange]

2cts:
To me, personally, a sequencer program hitting the 4GB limit would be a red flag in any design. That just looks too much like using the wrong tool.

[ralphlange]

@bfrk:
Wow....

Thanks an awful lot for what you achieved with the sequencer in the last two decades. We owe you!
As I always say in the trainings: "It's one of the oldest tools in the EPICS shed. Be prepared for lots of 80s technology. But practically every installation uses it, and it is by far the best documented and best tested tool we have."
Kudos. Very well done!
Great to have you stay in the loop for reviews and consulting.