Right now the structure int_remap_color_info_s has a fixed size for the number of colorants that can be handled. This number is specified by MAX_COMPONENTS_IN_DEVN. If a document has more than this number of colorants in a DeviceN color space we will have all sort of ugly things occur since the interpreter has no knowledge of the size limit of this structure. Either the interpreter needs to know the size or better yet, the structure should be dynamically allocated to the number ov colorants needed.
Assigning to Ray who wanted to take care of this one
I investigated and psi/zcolor.c has a check: if (r_size(&namesarray) > GS_CLIENT_COLOR_MAX_COMPONENTS) return_error(e_limitcheck); If we change this to MAX_COMPONENTS_IN_DEVN then any overflow in icremap.c due to access outside the array bounds, however, I still think that we should have MAX_COMPONENTS_IN_DEVN set to GS_CLIENT_COLOR_MAX_COMPONENTS. Why it should ever be less is not clear to me.
I think MAX_COMPONENTS_IN_DEVN should be replaced with a dynamic allocation but I dont have a problem with going to GS_CLIENT_COLOR_MAX_COMPONENTS if it doesn't effect performance
'Fixed' in commit 7a8e8f962f45f6f05c34e8ac2626f9caa8fe8460 Replaces MAX_COMPONENTS_IN_DEVN with GS_CLIENT_COLOR_MAX_COMPONENTS.