Le mer 28/04/2004 à 16:38, Wililam a écrit :
>       I have implemented the SetCalendarInfoA and SetCalendarInfoW API
> functions in dlls/kernel/time.c. I am aware that you generally do not like it
> when more than 1 thing is changed, but SetCalendarInfoA is not much more than 
> a
> call to SetCalendarInfoW. I am also curious as to why both functions were 
> listed
> as stdcalls rather than stubs when they were both stubs in the source file.

There are two levels of stubs: "real stubs", and dummy functions.

stub is used in a spec file when there's no implementation whatsoever of
a given function, not even a dummy one. If an app tries to use that
function, it results in a segmentation fault (and usually a crash to the
debugger).

In the case of SetCalendarInfo{A,W}, some dummy function existed, so
they were callable by an app without it crashing (hence the stdcall
declaration). Of course it wouldn't actually do much, that's what your
implementation is for. The "stub" in the FIXME is to remind people that
some function is not really there, although it's been called.

The line is difficult to draw between the two types of stub: some apps
will crash with a real stub and need a dummy one, some other ones will
crash with a dummy one and will route around real stubs. Usually it's
done on a case by case basis.

> 
> I have enclosed the patch for the file against the latest source package.
> 
> Here is the ChangeLog entry (I didn't patch the ChangeLog file):

Alexandre commits all the changelog entries to the ChangeLog file when
there's a release. Your way to specify the changelog is the correct one.

Vincent




Reply via email to