Thanks for the review.
If you would, kindly share a non-destructive patch for further
discussion.
P.
On Sep 18, 2008, at 17:05, Christian Theil Have wrote:
I've been testing the patch and it seems to work out allright :-)
A few notes;
#include <sys/stat.h>
must be outside #ifdef SunOS - other systems needs it too
in unlock_and_fclose(FILE *fp)
fclose is only called in #else, I suppose that should have been like
for unlock_and_close or we'll run out of filehandles ;-)
Best regards,
Christian
On Wed, Sep 10, 2008 at 10:05 PM, Jason Pollock <[EMAIL PROTECTED]
> wrote:
Christian Theil Have wrote:
Hi
I think it looks good :-) I was working on some similar code based
on a dict, which I was still testing out, but your patch is cleaner.
I look forward to trying it out, but I wont have the opportunity to
test it until Monday though.
About changing close and fclose everywhere in the codebase, you
could get around this without having to change the rest the of
codebase by using a few macros , eg.
#ifdef SunOS
#define close(fd) unlock_and_close(fd)
#endif
....
int unlock_and_close(fd) {
#ifdef close(fd)
#undef close(fd)
printf("unlock_and_close do the stuff..\n");
return close(fd);
#define close(fd) unlock_and_close(fd)
#endif
}
and similarly for fclose...
Christian.
That would work. I wasn't sure if the Mbuni team would want to go
that way, or the Kannel way:
#define close(x) you_should_not_call_close_directly(x)
I personally decided against the #define because I wanted to be able
to check that all instances of close/fclose had been modified in the
source I was working on. I did look at trying to figure out how to
wrap the libc call, but I thought that might be a bit too
destructive to my schedule. ;)
I'm still new to the gwlib code, I didn't realise it had a dict!
Too bad it uses octstr's as keys.
Let me know if you run into any problems. If I find any, I'll let
the list know.
Jason
_______________________________________________
Devel mailing list
Devel@mbuni.org
http://lists.mbuni.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel@mbuni.org
http://lists.mbuni.org/mailman/listinfo/devel
