The attached patch from ESP GS embeds C strings and not an array of character
values in src/geninit.c, as the HP-UX C compiler can't handle such a large array
without running out of memory.
Note that the Microsoft compilers limit the length of C strings and do not limit
array sizes. So for correctly fixing this bug there must be both ways
implemented in the source code, but with conditionals which depend on the
Created attachment 3159 [details]
Fix array size limit problem under HP UX.
While this patch won't hurt, it doesn't change anything since it affects only
deprecated use of geninit.
Note that the 'C' emitter of geninit.c is no longer used by COMPILE_INITS=1.
Instead it is only used to make the merged/stripped gsinit.ps which is used
as (one of) the input files for mkromfs.
The data for mkromfs is put into 'nodes', with the (compressed) data written
as 32-bit hex initializers. Very large files in the %rom% device may require
us to restructure things to allow one initializer per compressed block.
Please test COMPILE_INITS=1 on the HP-UX C compiler and look at the log
file where obj/gsromfs.c is compiled to see if warnings or errors are generated.
Assigning back to submitter for re-testing.
Unfortunately, I cannot do any testing here, as I have neither an HP UX nor a
So if the patch only affects obsolete code, simply close the bug.
I confirm that aC++ compiler on HP-UX B.11.31 U 9000/800 has no
problem compiling %romfs device.
There are many other issues detected by aC++ compiler but they are unrelated to
this problem and will be tracked separately.