[Freeassociation-devel] Commit R981 / R903

[Allen Winter]

On Monday 08 March 2010 9:43:12 am w.goesgens wrote:
> Allen,  
> 
> Since that code clearly introduced bugs internaly I'd be willing to increase
> the library version if thats needed to indicate a client needs a recompile.  
> 
> could you name a place where unsigned char* is depended on?  

Sure, the kcal library in KDE.

Currently it contains code like this:
  attach = icalattach_new_from_data ( ( unsigned char * )att->data(), 0, 0 );

which no longer compiles against libical trunk.

The source compatibility can be handled like so:
#if ( LIBICAL_MAJOR_VERSION == 0 ) && ( LIBICAL_MINOR_VERSION < 45 )
    attach = icalattach_new_from_data ( ( unsigned char * )att->data(), 0, 0 );
#else
    attach = icalattach_new_from_data ( att->data(), 0, 0 );
#endif

But I am very concerned about binary compatibility; so increasing
the soversion might be a good solution.


> >  Sa Mär 06 2010 00:24:45 CET von  "Allen Winter" <winter at kde.org> 
> >Betreff: Re: [Freeassociation-devel] Commit R981 / R903
> >
> >  On Tuesday 22 December 2009 7:34:29 am dothebart wrote:
> >  
> >>libical/src/libical/ (icalattach.c icalattach.h): 
> >> 13:25  CIA-14: libical: * unsigned char* why?
> >> 13:25  CIA-14: libical: * remove const casts; this is a place where
> >>casting away const definitely gave us a bug, as fixed by Allen earlier.
> >> Allen, since you've fixed a crash in R903 and the experiences we've
> >>collected with libicals code so far...
> >> Its probably always a good idea to question the surrounding code and have
> >>a look the place where they're called.
> >> The caller of icalattach_new_from_data() casted away a const char* which
> >>most probably was the reason for this crash?
> >> so, having a look at the bigger picture around a bug often shows more
> >>places for code cleanup, or even possible removal for now abandoned code;
> >> maybe somewhen in the future libical will have clean code ;-)
> >> 
> >>
> 
> >  Unfortunately, doing this changes the source and binary compatibility.
> > Assuming our next release is 0.45 (i.e. a point release), I don't think 
> > this is a good idea.
> > 
> > If this was C++ we could add a new overload; since it's C we need another
> >idea.
> > 
> > I suggest putting back the old icalattach_new_from_data() and make a new
> > function called icalattach_new_from_udata().  Put a big comment in the
> >header
> > that icalattach_new_from_data() is deprecated and to please use
> > icalattach_new_from_udata() instead.
> > 
> > or some-such.
> > 
> > comments on this?
> > 
> >
> >------------------------------------------------------------------------------
> >
> > Download Intel174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Freeassociation-devel mailing list
> > Freeassociation-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freeassociation-devel
> > 
> >
> >
> >  
> 
>   
> 
>  

-- 
Allen Winter | allen at kdab.net | Software Engineer
KDAB (USA), LLC, a KDAB Group company
Tel. USA +1-866-777-KDAB(5322), Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions