Re: Calling conventions

[Steven Sonntag <vtag@novell.com>]

I probably didn't make it clear what the real problem is.  The problem has
less to do with how the library is built, but with what happens when the
developer links with it.  Unless the header prototypes are coded with
the calling conventions, the application gets the calling conventions the app
writer chooses when setting compiler options, or if not set, the default
conventions.
These may be different from the conventions specified when the library was built

by the vendor. Thus the reason for putting on calling conventions
(where multiple conventions exist) is to ensure that whatever calling
conventions the application writer uses for the app the LDAP functions will get
compiled with vendor specified calling conventions, i.e. the ones that match the

library supplied, and thus the application can link.

Steve Sonntag

Howard Chu wrote:

> > At 01:35 PM 1/7/00 -0700, Steve Sonntag wrote:
> > >Has anyone given thought to specifying calling conventions in the header
> > >files.  There ought to be a way to specify whether a library is built
> > >with __stdcall or __cdecl calling conventions.  That way when an
> > >application is built, the header files will specify the correct calling
> > >convention and it will not get left up to default compiler options.
> >
> > This likely should be added to ldap_cdefs.h...
> >
> > >In looking at ldap_cdefs.h I was confused by LIBXXX_F defines.
> > >It is obvious they control all external stuff, but I couldn't figure out
> > >what F might mean.  I at first thought "Function", but they are
> > >used also for variables.
> >
> > It means "Function" and it's also used for variables.  We
> > likely should have an LDAP_E (extern) which is used by both
> > LDAP_F and LDAP_V macros.
> >
> > >If the original intent was function,
> > >then perhaps there should be two defines: LIBXXX_V for variables
> > >and LIBXXX_F for functions.  Then the calling conention could be
> > >put on the Function define.  The define LIBXXX_F would have to also be
> > >put in the code where the function is coded so it would match
> > the prototype.
> >
> > At the same time, s/LIBXXX/LDAP_LIBXXX/ to place defines within
> > the required namespace.
> >
> > >Does this make sense.  Any better ideas.  Does anyone else need
> > >something like this?
> >
> > Sounds reasonable to me...  Gary? Howard?
>
> I don't see much benefit to offering the choice between __cdecl and
> __stdcall, why not just build the libraries one particular way and leave it
> at that? I worked on Win3 and Win32 Kerberos4&5 DLLs and it was a royal pain
> coordinating these differences, all for the sake of compatibility with
> someone else (Kclient) who decided they liked Pascal calling convention
> better than C calling convention. That's just idiocy. This is a C
> development environment, stick to the standard C calling convention.
> Introducing any kind of divergent configuration is just making unnecessary
> work for yourself and god knows how many other people. (In My Arrogant
> Opinion; obviously you're free to disagree.)
>
> Admittedly the LIBXXX_F macros are somewhat confusing, but that's only
> because Microsoft's dynamic linking implementation is so braindead. Yes,
> originally the macros were only meant for function declarations, but as it
> turns out:
>   there are also global variable dependencies between various modules when
> built dynamically, and they must be declared properly
>   function references generally work regardless of whether they are declared
> "properly" or not
>
>   -- Howard Chu
>   Chief Architect, Symas Corp.       Director, Highland Sun
>   http://www.symas.com               http://highlandsun.com/hyc