Hi On Fri, Feb 10, 2023 at 2:21 PM Antonio Quartulli <a...@unstable.cc> wrote:
> Hi, > > On 10/02/2023 14:31, Lev Stipakov wrote: > > From: Lev Stipakov <l...@openvpn.net> > > > > Socket is a handle on Windows, which is usually logged in hex. > > Also an interesting value is INVALID_SOCKET, which is ~0. > > > > PRIuPTR prints decimals, and for INVALID_SOCKET it prints something like > > > > 2023-02-10 14:45:21 us=906000 write to TUN/TAP : Jrjestelmkutsulle > > annettu data-alue on liian pieni. (fd=18446744073709551615,code=122) > > > > PRIxPTR prints hex, and INVALID_SOCKET looks a bit nicer: > > > > 2023-02-10 15:17:11 us=828000 write to TUN/TAP : Jrjestelmkutsulle > > annettu data-alue on liian pieni. (fd=ffffffffffffffff,code=122) > > > > Reported-by: Selva Nair <selva.n...@gmail.com> > > Signed-off-by: Lev Stipakov <l...@openvpn.net> > > I also discussed this with Lev and, despite this being different from > what we do in the *nix world (where decimal representations make sense > for file descriptors), it seems to be the right hting to do on Windows > when using HANDLEs (shrug). > Windows kernel handles are very much "like" fds though the handle table also covers processes, threads, semaphores etc. They are not pointers, are generally smallish numbers or ~0 (== -1). But not as small as fds in the Unix/Linux world --- mainly because several objects share the name space and they have to be multiples of 4 for some arcane reason. The problem here was not printing as "decimal" but as "unsigned decimal". Use of the latter would have caused the same issue on Linux too. Using hex is a compromise here as handles are defined as "unsigned ints" of the same size as pointers. So PRIdPTR somehow looks improper though I would have chosen that. Selva
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
