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 compiler used.
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 Windows box. 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.