Re: [reSIProcate] Conditional compile should not change object sizes
I went and fixed stuff so that the size do not change when turning V6 on or
off - however .... I highly caution people from expecting code compiled with
one set of options to work with code compiled with another set of options.
Few questions on this ....
Would anyone object if I switched the USE_IPV6 to reverse the locif and have
a DISABLE_IPV6 flag so that if you compiled with nothing, you got v6.
Could we make the build system not define the RESIP_DATA_LOCAL_SIZE - this
will cause you to get the default size in Data.hxx. If you defined
RESIP_DATA_LOCAL_SIZE on the compile, it would override it. I can't imagine
a problem with this but I don't know why the code is like it is.
What is the right default size for this - does anyone have stats on speed
and memory usage as you move this?
On 4/13/05 12:40 PM, "Dennis Dupont" <ddupont@xxxxxxxxxxxxxxx> wrote:
> I have been hit by this twice now:
>
> There are header files that define classes with different sizes based upon
> conditional compilation. The preprocessor macros are set by choices in
> build/Makefile.conf. In particular for today's svn version, these include
> USE_IPV6 and RESIP_DATA_LOCAL_SIZE.
>
> If application code uses the header files without defining the macros
> identically, then instances of the class (and any that are compositions with
> that class) can be of different sizes in the library and application. The net
> result of this size difference is that the application's calling code will
> have its
> memory corrupted since it is not allocating the size the library expects.
>
> An example:
>
> class TransportSelector
> {
> ...
>
> private:
> ...
>
> #ifdef USE_IPV6
> struct sockaddr_in6 mUnspecified6;
> #endif
> }
> So now if the application fails to define USE_IPV6, TransportSelector is 28
> bytes shorter from the application's perspective than the library's -- and so
> is
> TransportController and SipStack, etc.
>
> It appears somebody tried to address this with the ApiCheck and ApiCheckList
> classes. However, the only way to use them would be to pass each possibly
> affected class and its size to the ApiCheck class, something cumbersome and
> not very robust in terms of keeping up with library changes.
>
> I think a longer term solution would be to make TransportSelector an interface
> class (only pure virtual methods), and use a TransportSelectorFactory that
> could be conditionally compiled to instantiate the correct implementation
> class. This of course has the problem of breaking value semantics (sigh).
>
>
> Dennis Dupont
> Senior Systems Architect
> Intelemedia Communications, Inc.
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel