Found the answer to my question. ssize_t is defined to LONG_PTR on Windows. For 32bit compiles, this gets defined as a "long", which would not be compatible with int32_t (int).
If this is a big issue, it should be pretty easy to add the additional conversions functions. This was not intended to be an exhaustive for all the types, but just widely used ones. If a particular type is hard to work with using the existing functions, then that would be a good one to consider adding support for. Rick On Fri, Apr 16, 2021 at 3:08 PM Rick McGuire <object.r...@gmail.com> wrote: > > > On Fri, Apr 16, 2021 at 12:27 PM Erich Steinböck < > erich.steinbo...@gmail.com> wrote: > >> I think our API doesn't provide conversion functions for the types size_t >> and ssize_t, so we have to use either (Unsigned)Int32 or (Unsigned)Int64 to >> convert. >> >> I still want to use size_t and ssize_t and would have expected this to >> work. >> >> 64-bit conversions and 32-bit size_t conversion works as expected, but on >> Windows 32 bit the ssize_t conversion compiles with error C2664: 'logical_t >> RexxCallContext_::Int32(RexxObjectPtr,int32_t *)': cannot convert argument >> 2 from 'ssize_t *' to 'int32_t *' >> >> ~~~ >> RexxObjectPtr o; >> size_t s; >> ssize_t ss; >> context->UnsignedInt32(o, &s); >> context->Int32 (o, &ss); >> ~~~ >> >> Why is that? >> > The Windows support for the ANSI portable types have always been a > nightmare. It appears that however they have defined ssize_t is not > compatible with the definition of int32_t. This article > > > https://stackoverflow.com/questions/22265610/why-ssize-t-in-visual-studio-2010-is-defined-as-unsigned#:~:text=ssize_t%20is%20not%20standard%20C%2C%20it%20is%20a%20typedef%20from%20Posix.&text=These%20typedefs%20insulate%20the%20operating,to%2032%20to%2064%2Dbit > . > > suggests that ssize_t is defined as LONG_PTR. I'm not sure how that is > defined. I see that our Windows rexxapitypes.h still has typedefs for > int32_t and others, but that is conditional based on the existence of > inttypes.h. For my build, at least, things are configured to use the > Microsoft-defined versions. > > Rick > > > >> _______________________________________________ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
