On Thu, Aug 11, 2022 at 3:21 PM NRK <[email protected]> wrote: > > On Thu, Aug 11, 2022 at 01:41:00PM +0200, Thomas Oltmann wrote: > > This concern is probably completely esoteric, but I can see > > how the pointer could theoretically overflow on some weird system > > where the kernel doesn't sit in the higher half of the address space ... > > I'm personally not too worried about overflow. The bigger worry would be > compiler's optimizer producing bad code. > > Gcc already does various "optimization" with the assumption that signed > overflow cannot occur [0]. Don't think they *currently* do anything like > that for pointer arithmetic (and probably unlikely they will, as it'd > break too much code). > > But this situation is easily avoided by subtracting the "current" > pointer from the "end" pointer and checking weather there's enough space > available or not; which is guaranteed to behave properly by the standard. > > Since the goal here can be achieved by a standard method without any > downside, makes sense to use that instead. > > [0] interesting thread on the matter: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 > > - NRK >
Allright, that clears it up for me. I'm generally aware of GCC's draconian interpretation of undefined behaviour, but I did not make the connection that this might extend to pointer overflows and the like. Also: I switched from read() over to mmap(), and went ahead and applied all of your patches, so thank you very much for that!
