First of all, don't worry about. It doesn't belong there, and will not
"fix" the real problem and will create new ones. You can see it as a
test for me to see how many more problems we run into after we "fix"
this problem. Evolution will run just fine if test == 0, calendar,
addressbook, creating mail all fine.
The OS will choke a little, but heh we are allowed to have some fun with
it.
Turns out it seems to be only this problem, which is good. That this
"test" can create new bugs doesn't matter here. It will be gone long
before we have found the real culprit.
_BUT_ you might look at my explanation of the code and look up
conditional operators in the "C programming Language", or I have to get
more sleep.
Have fun,
Ronald
On Wed, 2002-10-30 at 02:33, Michael Meeks wrote:
> Hi Ronald,
>
> I'm dead confused now; it seems in the plain (default) state, without
> poking 'test' at runtime we have:
>
> On Tue, 2002-10-29 at 15:28, Ronald Kuetemeier wrote:
> > > > int test = 0;
> ...
> > > > if(!strcmp(sockpath, tmp->u.usock.sun_path)) {
> > > > cnx = test ? tmp : NULL;
> > > > if(!test) continue;
> > > > break;
> > > > }
>
> which is:
>
> if (!strcmp (sockpath, tmp->u.usock.sun_path)) {
> cnx = NULL;
> continue;
> break;
> }
>
Ahm ..... NO. Remember I change test at will with the debugger while
running the app, even while in this code .....
You could write my code as:
if (!strcmp (sockpath, tmp->u.usock.sun_path))
if (test == 1 /* or not 0, if you want to be correct*/){
cnx = tmp; /* tmp is _not_ NULL, but doesn't matter I
"test" test
for this reason and maybe after this
line might change test with the debugger*/
}
else {
cnx = NULL; /* force NULL if test false */
}
if(test == 0 /*or test NOT TRUE, my convoluted coding, sorry */){
continue;
}
break;
}
> ie. this rather radically alters things from:
>
> if(!strcmp(sockpath, tmp->u.usock.sun_path)) {
> cnx = tmp;
> break;
> }
>
> > > So 'test' is always 0, and thus you always make a new Unix domain
> > > socket connection ? :-) wow - that's not going to be too efficient. I
> > > imagine you'll allocate 1-2 file descriptors per object and blow your fd
> > > limit pretty soon ;-) I'd be interested in the results of an:
> ...
> > Soorry should have explained, you read to much into the variable. It's just
> > for my debug, so I can set it from the debugger while in the function and get
> > a different behavior. It's not meant to fix anything, just gives another glue
> > in the behavior on what is going on.
>
> Presumably if you set test to non-zero you'll still get the bug, and
> will stop chewing file descriptors ? :-)
> Regards,
>
> Michael.
>
_______________________________________________
evolution-hackers maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/evolution-hackers
