Talk:OS2 API:Unicode: Difference between revisions
Appearance
API language specific items |
No edit summary |
||
Line 2: | Line 2: | ||
What I'd like to know is if what I'm referencing is really using c parameters/returns versus the OS/2 declared ones like ULONG, etc. For example, [[OS2 API:UniStrToUcs|UniStrToUcs]] returns an int according to the docs I'm reading. Ought this be APIRET? [[User:Prokushev|Prokushev]], I think this API will be problematic with keeping language specific features out. How shall I handle void**? - [[User:Daniel.lee.kruse|Daniel]] | What I'd like to know is if what I'm referencing is really using c parameters/returns versus the OS/2 declared ones like ULONG, etc. For example, [[OS2 API:UniStrToUcs|UniStrToUcs]] returns an int according to the docs I'm reading. Ought this be APIRET? [[User:Prokushev|Prokushev]], I think this API will be problematic with keeping language specific features out. How shall I handle void**? - [[User:Daniel.lee.kruse|Daniel]] | ||
I think we should just describe such types like we does for, for example, ULONG. Like integer is signed 32-bit integer in range -xxxx..+xxxx. | |||
void** is pointer to pointer on undefined type. For example, in Pascal we have ^Pointer for this construction. | |||
So, actually, no many problems here, I think. | |||
---[[User:Prokushev|Prokushev]] |
Revision as of 08:37, 19 March 2006
Anyone know of good documentation for the Unicode API?
What I'd like to know is if what I'm referencing is really using c parameters/returns versus the OS/2 declared ones like ULONG, etc. For example, UniStrToUcs returns an int according to the docs I'm reading. Ought this be APIRET? Prokushev, I think this API will be problematic with keeping language specific features out. How shall I handle void**? - Daniel
I think we should just describe such types like we does for, for example, ULONG. Like integer is signed 32-bit integer in range -xxxx..+xxxx.
void** is pointer to pointer on undefined type. For example, in Pascal we have ^Pointer for this construction.
So, actually, no many problems here, I think.
---Prokushev