On 24 November 2017 at 12:23, Roland Knall <[email protected]> wrote: > Not necessarily, in certain variations building WinXP and Win7 can lead to > size_t being 4 byte, but the pointer PVOID either 8 byte or 4 byte > depending on the target compile environment. > > This is incorrect, as noted earlier in the thread by Helge, size_t varies by the cpu target, x86 or x64, not by the OS target.
On x64 size_t is an unsigned __int64 which is self-evidently 64 bits, on x86 it's an unsigned int which is 32 bits. On Windows this causes issues when assigning a size_t value into an int, which on x64 is a narrowing and will require a cast (if you're absolutely positive the value won't be bigger than an int). If you use size_t everywhere it should all just work. > I would stick with a definition of size_t, because others will have to > handle the right size, not us. > > cheers > > On Fri, Nov 24, 2017 at 11:56 AM, Dario Lombardo < > [email protected]> wrote: > >> Couldn't it be replaced by guint32 then, and the guard removed? >> >> On Fri, Nov 24, 2017 at 10:45 AM, Helge Kruse <[email protected]> >> wrote: >> >>> DWORD is a 32 bit unsigned integer. >>> size_t is platform dependent, 32 bits in 32 bit Windows and 64 bits in >>> 64 bit Windows. I assume this is similar in other OS like Linux. >>> Therfore you can't replace DWORD by size_t without checking the impact. >>> >>> Further there is an additional member cap_pipe_buf in the #ifdef(_WIN32) >>> branch. >>> >>> Regards >>> Helge >>> >>> -- Graham Bloice
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
