Thanks for the report Carlos.
A couple things:
1) the repo on sourceforge is dead. please refer to github.com/libical for the up-to-date code.
2) the mailing lists on sourceforge are dead.
please use mailing lists shown on our new web page at http://libical.github.io/libical/
look under the "Get Involved" section
3) If you are interested in more errors like the ones you reported, we also have a
Coverity Scan available for libical at https://scan.coverity.com/projects/2367
if you want to see the defects, go to that url and ask to become a member of the project
We're always looking for more people to help us, so thanks and if you
want to help even more we'd be happy to have you.
On Thursday, January 22, 2015 12:51:25 AM Carlos Olmedo Escobar wrote:
> Hi,
>
> I've just found some problems with the code (thanks to cppcheck):
>
> - [libical/src/libicalcap/icalcap_rr.c:512]: (error) Uninitialized variable: ret
> The variable ret is useless in icalcap_message_sync_send_rr(), but
> can cause problems.
>
> [libical/src/libicalss/icalbdbset.c:168] ->
> [libical/src/libicalss/icalbdbset.c:167]: (warning) Possible null
> pointer dereference: options - otherwise it is redundant to check it
> against null.
> This code makes no sense and should be removed:
> if (options == NULL)
> *options = icalbdbset_options_default;
>
> [libical/src/libicalss/icalcstpserver.c:230]: (error) Possible null
> pointer dereference: data
> The pointer 'data' in icalcstps_process_incoming() is being used but
> has no effect. Actually its value is always invalid.
>
> Regards.
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Freeassociation-devel mailing list
> Freeassociation-devel@...
> https://lists.sourceforge.net/lists/listinfo/freeassociation-devel

Hi,
I've just found some problems with the code (thanks to cppcheck):
- [libical/src/libicalcap/icalcap_rr.c:512]: (error) Uninitialized variable: ret
The variable ret is useless in icalcap_message_sync_send_rr(), but
can cause problems.
[libical/src/libicalss/icalbdbset.c:168] ->
[libical/src/libicalss/icalbdbset.c:167]: (warning) Possible null
pointer dereference: options - otherwise it is redundant to check it
against null.
This code makes no sense and should be removed:
if (options == NULL)
*options = icalbdbset_options_default;
[libical/src/libicalss/icalcstpserver.c:230]: (error) Possible null
pointer dereference: data
The pointer 'data' in icalcstps_process_incoming() is being used but
has no effect. Actually its value is always invalid.
Regards.

Looks like you have to sign in to view the report. Do you have an easy way to post a copy of the report somewhere?
On Jun 6, 2014, at 4:45 PM, Allen Winter <winter@...> wrote:
> You might be able to access the Outstanding Defects report at:
> https://scan8.coverity.com:8443/reports.htm#v16495/p10812
>
> On Friday, June 06, 2014 04:32:02 PM Allen Winter wrote:
>> The Coverity Scan for libical is now setup.
>>
>> If you want to be involved with helping to cleanup the Coverity errors in libical
>> please send me your email address and I will invite you.
>>
>> Kent: I already invited you
>>
>> All coverity fixes should be committed into the new coverity_scan branch.
>>
>> We only are permitted a small number of scans per day so the idea
>> is to batch up a few fix commits into the coverity_scan branch before pushing.
>>
>> Once we have a set of fixes we know work ok, we can cherry-pick them to master.
>>
>> PS. there are surprisingly few errors found by Coverity. many of them are in the
>> test programs where we leak memory with abandon. Some of the low-priority
>> warnings are not readily fixable since it would mean changing the API.
>>
>> Anyway, if you have any interest in helping out please let me know.
>>
>> -Allen
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Freeassociation-devel mailing list
>> Freeassociation-devel@...
>> https://lists.sourceforge.net/lists/listinfo/freeassociation-devel
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Freeassociation-devel mailing list
> Freeassociation-devel@...
> https://lists.sourceforge.net/lists/listinfo/freeassociation-devel

You might be able to access the Outstanding Defects report at:
https://scan8.coverity.com:8443/reports.htm#v16495/p10812
On Friday, June 06, 2014 04:32:02 PM Allen Winter wrote:
> The Coverity Scan for libical is now setup.
>
> If you want to be involved with helping to cleanup the Coverity errors in libical
> please send me your email address and I will invite you.
>
> Kent: I already invited you
>
> All coverity fixes should be committed into the new coverity_scan branch.
>
> We only are permitted a small number of scans per day so the idea
> is to batch up a few fix commits into the coverity_scan branch before pushing.
>
> Once we have a set of fixes we know work ok, we can cherry-pick them to master.
>
> PS. there are surprisingly few errors found by Coverity. many of them are in the
> test programs where we leak memory with abandon. Some of the low-priority
> warnings are not readily fixable since it would mean changing the API.
>
> Anyway, if you have any interest in helping out please let me know.
>
> -Allen
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Freeassociation-devel mailing list
> Freeassociation-devel@...
> https://lists.sourceforge.net/lists/listinfo/freeassociation-devel

The Coverity Scan for libical is now setup.
If you want to be involved with helping to cleanup the Coverity errors in libical
please send me your email address and I will invite you.
Kent: I already invited you
All coverity fixes should be committed into the new coverity_scan branch.
We only are permitted a small number of scans per day so the idea
is to batch up a few fix commits into the coverity_scan branch before pushing.
Once we have a set of fixes we know work ok, we can cherry-pick them to master.
PS. there are surprisingly few errors found by Coverity. many of them are in the
test programs where we leak memory with abandon. Some of the low-priority
warnings are not readily fixable since it would mean changing the API.
Anyway, if you have any interest in helping out please let me know.
-Allen

On Monday, June 02, 2014 08:45:58 AM Allen Winter wrote:
> https://travis-ci.org/libical/libical
>
> l think we can add a Mac platform to the CI builds. but no Windows, afaict
>
I added a Mac build yesterday. seems to work fine.
to bad travis-ci can't do Windows yet.
there are some pretty cool browser plugins for travis-ci that helps monitor build status.
I installed "My Travis" to monitor the libical/libcal builds.
Next I'm going to try and setup Coverity scans. that should show us a crapload of problems, I suspect.

On Sunday, June 01, 2014 10:10:55 PM David Woodhouse wrote:
> On Sat, 2014-05-31 at 18:08 -0400, Allen Winter wrote:
> > I don't think GitHub provides mailing lists, so I think we need to
> > keep SourceForge simply for mailing lists. unless someone has a better
> > idea.
>
> You're welcome to use lists.infradead.org if that's preferable to
> SourceForge.
>
Another possibility is to use google groups.
I see there is a libcal on google groups already, but it contains mostly spam.
and then there's the problem of what to do with the archives.
David, would it be possible to somehow transfer the archives from freeassociation to infradead?

So now I committed lots of extra compiler warnings (for gcc and clang).
I may have gone overboard; there are now almost 500 compiler warnings.
most of them are of the unsed variable or set-and-unused variable type.
but there are plenty of others that deserve a review and probably fixup.
if anyone feels like cleaning up this old code, please do. make a pull request on github.

On Saturday, May 31, 2014 07:14:33 PM Allen Winter wrote:
> On Saturday, May 31, 2014 06:08:28 PM Allen Winter wrote:
> > Howdy,
> >
> > The github import of the freeassociation code from SourceForge is done.
> > See https://github.com/libical
> >
> > I created an organization called "libical" (unfortunately "freeassociation" was already taken)
> > Inside the "libical" organization we have 2 repos: libical and vzic
> >
> > Lots of cleanup remains and I would like to transfer the bugs, patches and stuff to GitHub as well.
> >
> > If you want to become a member of the "libical" organization (team) please create an account
> > on GitHub (if needed) and send me your username.
> >
> > I don't think GitHub provides mailing lists, so I think we need to keep SourceForge simply
> > for mailing lists. unless someone has a better idea.
> >
> > If anyone wants to help with the transition please speak up. I can use all the help I can get.
> >
> > As far as I'm concerned, the SourceForge SVN repo is frozen, so please start using
> > the git repos. We can create feature branches now. yay! <- Kent let's do that for RSCALE stuff.
> >
> > Regards,
> > Allen
>
> We now have a github home page at http://libical.github.io/libical/
>
> Also I imported all the issues, bugs, feature requests, support requests and patches.
> You will find all those merged together in https://github.com/libical/libical/issues
> too bad they are all owned/submitted by me :)
>
Remember, if you want to monitor commits (I made a few so far today)
you'll need to follow the libical/libical project on github.
and you'll need to setup your notifications. make sure your notification email is verified.
if you join the team (send me your github username) then you should automatically be following.
The freeassociation commits mailing list still exists, but should be dead from here forward.

On Saturday, May 31, 2014 06:08:28 PM Allen Winter wrote:
> Howdy,
>
> The github import of the freeassociation code from SourceForge is done.
> See https://github.com/libical
>
> I created an organization called "libical" (unfortunately "freeassociation" was already taken)
> Inside the "libical" organization we have 2 repos: libical and vzic
>
> Lots of cleanup remains and I would like to transfer the bugs, patches and stuff to GitHub as well.
>
> If you want to become a member of the "libical" organization (team) please create an account
> on GitHub (if needed) and send me your username.
>
> I don't think GitHub provides mailing lists, so I think we need to keep SourceForge simply
> for mailing lists. unless someone has a better idea.
>
> If anyone wants to help with the transition please speak up. I can use all the help I can get.
>
> As far as I'm concerned, the SourceForge SVN repo is frozen, so please start using
> the git repos. We can create feature branches now. yay! <- Kent let's do that for RSCALE stuff.
>
> Regards,
> Allen
We now have a github home page at http://libical.github.io/libical/
Also I imported all the issues, bugs, feature requests, support requests and patches.
You will find all those merged together in https://github.com/libical/libical/issues
too bad they are all owned/submitted by me :)

Howdy,
The github import of the freeassociation code from SourceForge is done.
See https://github.com/libical
I created an organization called "libical" (unfortunately "freeassociation" was already taken)
Inside the "libical" organization we have 2 repos: libical and vzic
Lots of cleanup remains and I would like to transfer the bugs, patches and stuff to GitHub as well.
If you want to become a member of the "libical" organization (team) please create an account
on GitHub (if needed) and send me your username.
I don't think GitHub provides mailing lists, so I think we need to keep SourceForge simply
for mailing lists. unless someone has a better idea.
If anyone wants to help with the transition please speak up. I can use all the help I can get.
As far as I'm concerned, the SourceForge SVN repo is frozen, so please start using
the git repos. We can create feature branches now. yay! <- Kent let's do that for RSCALE stuff.
Regards,
Allen

On Thursday, May 08, 2014 06:25:12 PM Allen Winter wrote:
> Howdy,
>
> I'm thinking we should migrate from Subversion at SourceForge to Git at GitHub.
>
> I'd rather be using git than subversion.
> I'd like be able to have git feature branches where people can work on bigger features.
>
> And a really big thing I want is CI, and GitHub projects can leverage the travis-ci.org system.
> Maybe sourceforge has a free CI system, but I can't find such a thing.
>
> Comments about moving from SourceForget to GitHub?
>
Pull requests with code review too.
So since nobody objects I will plan to make this move happen.
-Allen

Hello,
I would like to ask, whether it would be acceptable by libical project
to provide also GObject introspactable interface for the library, as
part of the sources, with optional compilation, to not add a hard
dependency on GLib due to it.
The reason is that we've got a GSoC 2014 project to complete
introspection of calendar part of evolution-data-server, which is using
libical and exposes it in public API, but the libical as such is not
introspectable, thus we have basically bad luck. The current idea is,
instead of doing some ugly hacks on the evolution-data-server side,
define GObject-based interface for libical, which will be fully
introspectable. This interface would be nice to have as part of libical
sources, thus more people interested in it would be able to use it.
The tasks for the student will be:
- create GObject based interface for structures provided by libical
- properly annotate the interface, thus it'll be usable both by
the introspection interface generator and by the gtk-doc (thus a nice
developer help pages will be created from it too)
- provide python3 tests of the introspection interface, with as large
coverage as possible, which would be possible to run during 'make check'
There will be probably involved some scripts for build-time, for example
for enums, to generate them from libical sources, rather than hard-code
them and miss any future changes. A script which would check whether any
public API function is not missing in the GObject-interface would be
also nice. Who knows, if there will be some pattern found, then many of
the work would be semi-automated. That all is to be figured out. I do
not want to go too much into detail now, nothing is set in the stone.
So, would be libical developers willing to include GObject introspection
interface of libical in the sources?
Thanks and bye,
Milan
P.S.: I CC'ed also Miao Yu, whom is the student which will do the work.
P.P.S.: In case you are not sure, introspection interface allow running
the code in languages like python or javascript, which seem to be quite
popular, thus the interface may bring more interested users to libical.

>I'm thinking we should migrate from Subversion at SourceForge to Git at
GitHub.
>
>I'd rather be using git than subversion.
>I'd like be able to have git feature branches where people can work on bigger
features.
>
>And a really big thing I want is CI, and GitHub projects can leverage the
travis-ci.org system.
>Maybe sourceforge has a free CI system, but I can't find such a thing.
>
>Comments about moving from SourceForget to GitHub?
Works for me. I'd much rather see us on git than subversion.
Not a fan of SourceForge either.
-- Art

<html><body>
<p>Hi everyone...</p>
<p>I've migrated the repo from CVS to SVN way back then because of the first time I looked into 'cvs log' it made me barf.</p>
<p>About 15 months later we migrated citadel from SVN to GIT.</p>
<p>Clearly git is prefereable over SVN. Probably the sf.net git doesn't provide the neccesary infrastructure like the CI or bugtracker etc?</p>
<p>I'm all in for migrating.</p>
<p>Please make shure there is a last commit to SVN laying breadcrumbs to the new location.</p>
<p> </p>
<p>Cheers, Willi</p>
<blockquote>
<div class="message_header"><span>Fri May 09 2014 08:26:32 EDT</span> <span>from "Allen Winter" &lt;winter@...&gt; </span> <span class="message_subject">Subject: Re: [Freeassociation-devel] Move to GitHub</span></div>
<div class="message_content"><tt>On Thursday, May 08, 2014 10:48:29 PM Daniel Corbe wrote:</tt><br />
<blockquote><tt>Allen Winter &lt;winter@...&gt; writes:</tt><br /> <tt></tt><br />
<blockquote><tt>Howdy,</tt><br /> <tt></tt><br /> <tt>I'm thinking we should migrate from Subversion at SourceForge to Git at GitHub.</tt><br /> <tt></tt><br /> <tt>I'd rather be using git than subversion.</tt><br /> <tt>I'd like be able to have git feature branches where people can work on bigger features.</tt><br /> <tt></tt><br /> <tt>And a really big thing I want is CI, and GitHub projects can leverage the travis-ci.org system.</tt><br /> <tt>Maybe sourceforge has a free CI system, but I can't find such a thing.</tt><br /> <tt></tt><br /> <tt>Comments about moving from SourceForget to GitHub?</tt><br /> <tt></tt><br /> <tt></tt></blockquote>
<tt>You realize that git has an SVN module, right?</tt><br /> <tt></tt></blockquote>
<tt>Sure and I considered that. but only helps a little.</tt><br /> <tt>It's not just git I want (full featured git), but gitHub so I can use their CI.</tt><br /> </div>
</blockquote>
<p> </p>
</body></html>

On Thursday, May 08, 2014 10:48:29 PM Daniel Corbe wrote:
> Allen Winter <winter@...> writes:
>
> > Howdy,
> >
> > I'm thinking we should migrate from Subversion at SourceForge to Git at GitHub.
> >
> > I'd rather be using git than subversion.
> > I'd like be able to have git feature branches where people can work on bigger features.
> >
> > And a really big thing I want is CI, and GitHub projects can leverage the travis-ci.org system.
> > Maybe sourceforge has a free CI system, but I can't find such a thing.
> >
> > Comments about moving from SourceForget to GitHub?
> >
>
> You realize that git has an SVN module, right?
Sure and I considered that. but only helps a little.
It's not just git I want (full featured git), but gitHub so I can use their CI.

I'm all for this. I already use the project as a submodule through git-svn, so being native to git would make things easier for me. Branches and pull requests would make change tracking significantly easier as well. Having CI would also be very nice, as it'd encourage me to write tests directly for the project. I currently have a small set of tests that I run parallel in my own project.
GitHub also has that intangible friendlier feel than SourceForge.
Kent
On May 8, 2014, at 6:25 PM, Allen Winter <winter@...> wrote:
> Howdy,
>
> I'm thinking we should migrate from Subversion at SourceForge to Git at GitHub.
>
> I'd rather be using git than subversion.
> I'd like be able to have git feature branches where people can work on bigger features.
>
> And a really big thing I want is CI, and GitHub projects can leverage the travis-ci.org system.
> Maybe sourceforge has a free CI system, but I can't find such a thing.
>
> Comments about moving from SourceForget to GitHub?
>
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> &#149; 3 signs your SCM is hindering your productivity
> &#149; Requirements for releasing software faster
> &#149; Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> Freeassociation-devel mailing list
> Freeassociation-devel@...
> https://lists.sourceforge.net/lists/listinfo/freeassociation-devel

Allen Winter <winter@...> writes:
> Howdy,
>
> I'm thinking we should migrate from Subversion at SourceForge to Git at GitHub.
>
> I'd rather be using git than subversion.
> I'd like be able to have git feature branches where people can work on bigger features.
>
> And a really big thing I want is CI, and GitHub projects can leverage the travis-ci.org system.
> Maybe sourceforge has a free CI system, but I can't find such a thing.
>
> Comments about moving from SourceForget to GitHub?
>
You realize that git has an SVN module, right?

Howdy,
I'm thinking we should migrate from Subversion at SourceForge to Git at GitHub.
I'd rather be using git than subversion.
I'd like be able to have git feature branches where people can work on bigger features.
And a really big thing I want is CI, and GitHub projects can leverage the travis-ci.org system.
Maybe sourceforge has a free CI system, but I can't find such a thing.
Comments about moving from SourceForget to GitHub?

When running some tests on my server, I found that a VFREEBUSY component
with a DTSTAMP was incorrectly being rejected.
I audited restrictions.csv against RFCs 5545 and 5546 and came up with
the attached diff.
At some point, I will audit all of the components/methods, but I have
bigger fish to fry at the moment.
--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

On 1/22/14, 6:55 PM, Ken Murchison wrote:
> Is there a recipe for adding a new property to libical? I am trying to
> add the BUSYTYPE property as defined by
> http://tools.ietf.org/html/draft-daboo-calendar-availability I have
> already successfully added the VAVAILABILITY and VAVAILABLE components.
>
> I have added what I believe to be required in the design-data directory
> but I am getting undefined symbols for icalvalue_get_busytype and
> icalvalue_new_busytype
>
I found a quick solution to my problem, but I don't know if its the
correct solution. I had copied the CLASS property declaration as a
starting point for BUSYTYPE, which uses the (m) gen flag. By switching
to the (a) gen flag, the library builds.
I'm assuming that (a) means automatic and (m) means manual, but how does
one determine the correct gen flag, and what other code needs to be
written when using (m)?
--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University