On Thu, Aug 11, 2022 at 3:21 PM NRK <nrk_AT_disroot.org> 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!
Received on Thu Aug 11 2022 - 18:28:47 CEST