Hi Alex, On 12/1/20 10:35 PM, Alejandro Colomar (man-pages) wrote: > Hi Michael, > > On 12/1/20 9:20 PM, Michael Kerrisk (man-pages) wrote: >>>>>>> +.SS Security >>>>>>> +Encoded I/O creates the potential for some security issues: >>>>>>> +.IP * 3 >>>>>>> +Encoded writes allow writing arbitrary data which the kernel will decode on >>>>>>> +a subsequent read. Decompression algorithms are complex and may have bugs >>>>>>> +which can be exploited by maliciously crafted data. >>>>>>> +.IP * >>>>>>> +Encoded reads may return data which is not logically present in the file >>>>>>> +(see the discussion of >>>>>>> +.I len >>>>>>> +vs. >>>>>> >>>>>> Please, s/vs./vs/ >>>>>> See the reasons below: >>>>>> >>>>>> Michael (mtk), >>>>>> >>>>>> Here the renderer outputs a double space >>>>>> (as for separating two sentences). >>>>>> >>>>>> Are you okay with that? >>> >>> Yes, that should probably be avoided. I'm not sure what the >>> correct way is to prevent that in groff though. I mean, one >>> could write >>> >>> .RI "vs.\ " unencoded_len >>> >>> but I think that simply creates a nonbreaking space, >>> which is not exactly what is desired. >> >> Ahh -- found it. From https://groff.ffii.org/groff/groff-1.21.pdf, >> we can write: >> >> vs.\& >> >> to prevent the double space. > > Nice to see it's possible. > However, I would argue for simplicity, > and use a simple 'vs', > which is already in use. Indeed better. Thanks for noticing that. Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
