Hi Chen,
Yes, we either need to convert or cast when dealing with the outside world.
Not just OS APIs,
but any 3rd party APIs.
This is what we do now, but in the future we can
add more built-in APIs for conversion, if our
internal representation becomes better defined
and/or more sophisticated.
Internal representation is one thing,
but what happen when you need to interact with OS API and CRT?
You need to cast our internal types into those used by the API or run-time?
(like the whole WIN API types change when use work in UNICODE)
Chen.___
Har
Hi Przemek,
Now I think I understand your concept, plus that your
main concern (for now) is that BYTE's signedness isn't
currently well defined. Of course I didn't want to change
anything that could break compatibility.
Here's my draft planned steps to switch to a properly typed
core; I've keyed t
On Sat, 07 Feb 2009, Szak�ts Viktor wrote:
Hi Viktor,
> > I suggest to change all 'BYTE *' used as file name in Harbour
> > FS API and similar functions to 'char *' type to not replicate
> > the problems which comes from Clipper, f.e. from CL53 header files:
> > typedef unsigned char BYTE;
> >
Hi Przemek,
> I suggest to change all 'BYTE *' used as file name in Harbour
> FS API and similar functions to 'char *' type to not replicate
> the problems which comes from Clipper, f.e. from CL53 header files:
> typedef unsigned char BYTE;
> typedef BYTE far * BYTEP;
> extern void _retc(BY
On Sat, 07 Feb 2009, Szak�ts Viktor wrote:
Hi Viktor,
> I've a patch ready to address BYTE to UCHAR conversion.
> Would you mind reviewing it, before committing?
> http://www.syenar.hu/harbour/byte_2_uchar_dif.zip
> (size: 26KB)
Yes, sure I've just seen it but it's not what I wanted to make.
The
