RE: Sync(2): oleaut32 I1 funcs

[Robert Shearman]

> -----Original Message-----
> Message: 1
> Date: Thu, 17 Jul 2003 08:37:08 -0700 (PDT)
> From: Jon Griffiths 
> Subject: Sync(2): oleaut32 I1 funcs
> To: [e-mail], [e-mail]
> Reply-To: [e-mail]
> -HRESULT WINAPI SetErrorInfo(ULONG dwReserved, IErrorInfo *perrinfo);
> -HRESULT WINAPI GetErrorInfo(ULONG dwReserved, IErrorInfo **pperrinfo);
> -HRESULT WINAPI CreateErrorInfo(ICreateErrorInfo **pperrinfo);
> +HRESULT WINAPI SetErrorInfo(ULONG,IErrorInfo*);
> +HRESULT WINAPI GetErrorInfo(ULONG,IErrorInfo**);
> +HRESULT WINAPI CreateErrorInfo(ICreateErrorInfo**);

Is there any reason for stripping out the parameter names from this file?
They can be quite useful as a reminder for what each parameter is.

P.S. In other parts of your patch you replaced char with signed char. Is
signed char != char?

Rob

Sync(2): oleaut32 I1 funcs

[Jon Griffiths]

Hiya,
> Is there any reason for stripping out the parameter names from this

file?
> They can be quite useful as a reminder for what each parameter is.

Consistency and ease of reading, mostly. Before the patch only some
of the calls have parameter names, and (e.g.) the variant calls
aren't consistent in their use of the names anyway. Compilers just
ignore the names, and for humans, we (should) have documentation that
tells us what functions are supposed to do.

I don't think that, for example:
HRESULT WINAPI VarUI2FromDisp(IDispatch* pdispIn, LCID lcid, USHORT*
puiOut);

Tells you anything more than:

HRESULT WINAPI VarUI2FromDisp(IDispatch*,LCID,USHORT*);

If you wan't to know what the parameters of the calls in this header
mean and really can't remember, you'll be able to 'man funcname' when
I finish syncing my tree in any case - I've documented them all in
c2man extractable form.
> P.S. In other parts of your patch you replaced char with signed
> char. Is signed char != char?

They aren't the same. 'man gcc' and look for "-funsigned-char".

I actually wanted to use char and not signed char, but Alexandre
expressed a preference for doing it this way. My rationale is that if
I build an app under windows using msvcs "-funsigned-char"
equivalent, my app get prototypes from the native headers using
unsigned chars, whereas using "-funsigned-char" and building under
winelib will give me signed chars. However, the chances of this
making a difference in the real world are slight.

Cheers,
Jon

=====
"Don't wait for the seas to part, or messiahs to come;
 Don't you sit around and waste this chance..." - Live

[e-mail]

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Sync(2): oleaut32 I1 funcs

[David Laight]

> Is there any reason for stripping out the parameter names from this file?
> They can be quite useful as a reminder for what each parameter is.

They can cause serious grief if for example:
1) they happen to match the name of a #define
2) they match the name of a global item and you have enough warnings
   enabled.
> P.S. In other parts of your patch you replaced char with signed char. Is
> signed char != char?

There are systems where char == unsigned char.
If you want an 8 bit integer, you probably ought to be using int8_t
or uint8_t which a system ought to be supplying (real soon now)
in <inttypes.h>.

David