On Fri, 19 May 2023 15:43:30 GMT, Roger Riggs <rri...@openjdk.org> wrote:
>>> Sorry, but I don't understand this argument. If we do a short read we will >>> work with corrupted ChildStuff and SpawnInfo >>> structures. This can in the extreme case execute arbitrary code (e.g. if >>> ChildStuff.argv is not fully read from the parent). You are >>> basically saying it is better to work on corrupted data rather than >>> reporting an error. >> >> No I am simply pointing out that this has changed more than just the issue >> with close. And maybe a short-read does indicate data "corruption" and maybe >> it should be a fatal error. But I don't know exactly how this might manifest >> so perhaps there are benign short-reads that actually do happen. Regardless >> it might be better to split this part out and focus on the close issue here. > >> > Sorry, but I don't understand this argument. If we do a short read we will >> > work with corrupted ChildStuff and SpawnInfo >> > structures. This can in the extreme case execute arbitrary code (e.g. if >> > ChildStuff.argv is not fully read from the parent). You are >> > basically saying it is better to work on corrupted data rather than >> > reporting an error. >> >> No I am simply pointing out that this has changed more than just the issue >> with close. And maybe a short-read does indicate data "corruption" and maybe >> it should be a fatal error. But I don't know exactly how this might manifest >> so perhaps there are benign short-reads that actually do happen. Regardless >> it might be better to split this part out and focus on the close issue here. > > Given the purpose and implementation of the `readFully` function, I don't see > how it can return anything other than an error or the full requested read > length. @RogerRiggs , @tstuefe thanks for your reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1559423017
