Jump to content

Talk:OS2 API:Unicode: Difference between revisions

From EDM2
API language specific items
 
Prokushev (talk | contribs)
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