Hi Przemek and All,
> I think the first thing should be to define our existing "char" types:
>
> HB_UCHAR
> HB_SCHAR
> HB_WCHAR
> HB_BYTE / BYTE
> char
> USHORT
I'm having a try to collect what we know about char/byte types:
- HB_UCHAR: Similar to HB_BYTE. Was introduced to avoid signedness problems
when using legacy type BYTE.
- HB_SCHAR: Used in just a few places, signed HB_UCHAR.
- HB_WCHAR: 16-bit UNICODE char (this is the only one I'm certain of)
- HB_BYTE: Similar to HB_UCHAR, non-textual data streams, PCODEs, data stored
on disk.
- BYTE (deprecated): Similar to HB_BYTE but with non-guaranteed signedness.
- char: generic text, 8-bit or UTF-8, PCODEs (wrongly used). Signedness
non-guaranteed.
- unsigned char: Similar to HB_UCHAR
- HB_USHORT: Text character in GT API. Maybe used because low level
interface may accept 8-16 bit chars. But even then hbapigt.h
shouldn't use this type.
- HB_I8: I estimate this won't be used too often in practice.
- HB_U8: Seems to be interchangeable with HB_BYTE/HB_UCHAR, on
systems where char is 8 bit, but could be useful
for disk structures on systems where it's not.
This of course needs that we start using those f.e.
in RDD code.
Questions:
- Shouldn't we change HB_USHORT to something else in GT API?
- Now that we define our own HB_BYTE, and it's guaranteed to
be unsigned, isn't it equivalent to HB_UCHAR? (if not see next)
- What is the difference between HB_BYTE/HB_UCHAR?
Where should we use which? If they are equivalent, which
should be chosen as the "one"?
So far my conclusion is that HB_BYTE is superfluous and
could be replaced by HB_UCHAR everywhere in code, except
for disk structures where it should be replaced with HB_U8.
'unsigned char' should also be changed to HB_UCHAR.
Or perhaps the cleanest and simplest way would be to stick
to HB_BYTE and HB_CHAR (since signedness is now guaranteed)
for in-memory usage, and HB_U8 for externally stored data,
and drop HB_UCHAR, HB_SCHAR. BYTE/CHAR are much familiar
names, and most of or code uses these terms.
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
