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

Reply via email to