THausherr commented on PR #6: URL: https://github.com/apache/pdfbox-jbig2/pull/6#issuecomment-6707036474
I asked copilot what was mean with the latest remark: ==== The check in HalftoneRegion rejects the grid whenever hGridWidth × hGridHeight exceeds Integer.MAX_VALUE. That prevents the product from exceeding a signed int, but the grid is later allocated as new int[hGridHeight][hGridWidth]—a two-dimensional array made of separate rows, not one flat array whose length is that product. So dimensions can have an int-representable width and height, and potentially be allocatable, even when their product exceeds Integer.MAX_VALUE. The concern is that this guard may impose a new maximum grid size, rather than only preventing arithmetic overflow. The PR says large-but-in-range allocations are intentionally left to the embedding application, so a human should decide whether this limit is intentional policy or should be removed/replaced with a deliberate resource cap. ==== sigh... copilot makes a good point. However I suspect that the initial commit was also AI based (please mention this in the future), so this is a case of an AI disagreeing with an AI, possibly the same AI. I couldn't find a clear answer whether there is a limit in java 2D arrays. An unlikely 10000 x 10000 array would have 0x5F5E100 entries, so I'd say we can live with that. I also tested the change with my rendering regression tests and it works. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
