Testing and VarBstrFromDate (was Re: OLE2A)

[Bill Medland]

On Thu, 2007-03-05 at 07:29 -0700, Bill Medland wrote:
> On Thu, 2007-03-05 at 07:49 +0200, Marcus Meissner wrote:
> > On Wed, May 02, 2007 at 03:32:59PM -0700, Bill Medland wrote:
> > > Does anyone know where a call to OLE2A is going to enter wine?
> > > Presumably OLE2A returning null means that the thread ran out of stack
> > > space?
> >
> > What is OLE2A? I do not see it mentioned anyewhere in the Wine source.
> >
> > Any more debugging output?
> >
> > Ciao, Marcus
>
> Hi Marcus, thanks for taking interest.
>
> A little late now, I think.  The problem is not where I thought it was.
>
> OLE2A is a Microsoft macro used to convert e.g. a BSTR to a char *,
> allocating memory on the stack and calling one of the wide-to-narrow
> conversions.
>
> Our program was behaving quite strangely, throwing an exception from
> some code that should not throw an exception.
>
> I traced it down to some code that did an OLE2A on a BSTR, called strlen
> on the return and then passed the same narrow string to a function.
> The problem occurred when the OLE2A returned a null pointer.  Due to an
> oversight I thought the BSTR was non-null and assumed that somehow the
> underlying alloca must be returning null (i.e. was detecting out-of-
> stack-space).
>
> Now I discover that the BSTR itself was also NULL so that makes sense.
>
> I presume what happens is all that magic that traps the segment
> violation on strlen(0) didn't quite handle whatever optimised code was
> being generated for our case.
>
> However what I am also investigating is where the original NULL BSTR
> came from; possibly a defect in VariantChangeTypeEx.

Actually VariantChangeType was returning E_INVALIDPARAM and a VT_EMPTY
and the caller wasn't checking the result.

However I think VariantChangeType was wrong in this case.
> Bill

So.

1. Am I misunderstanding something about the tests these days?

(I am about to add two edge tests on SystemTimeToFileTime in time.c and
GetDateFormatW in locale.c)

I go into dlls/kernel32/tests and make tests and it fails (change.c,
locale.c)

Should that disconcert me?

2. How to fix the VarBstrFromDate?

VarBstrFromDate(-657434.0 (DATE_MIN), 0x409, 0x80000000, wherever)
fails because VariantTimeToSystemTime successfully converts that to
1/1/100 but then VarBstrFromDate tries to format that using
GetDateFormat, which is not feasible because the SystemTime is out of
range.

Is there an existing low level routine that can handle the conversion
for such a small date?

Bill