>> Ah, I missed that it would use it - then I guess it's not a memory leak, >> but it just seems strange, since I've never seen that done in any of the >> other code that uses getpeerucred(). > >And I've been corrected again to point out that I was half right - because the >application explicitly mallocs the memory, it's leaked in the failure case, >since it does a "goto failed" right over the ucred_free(), where I believe no >memory would be allocated if you just left the allocation up to >getpeerucred(). Also, you should probably use free() if you're going to use >malloc(), to avoid mixing and matching memory allocators there (not likely, >but possible), though dropping the malloc() and keeping the ucred_free() seems >cleaner to me.
Right; you will need to initialize the ucred to NULL in that case. (The original idea was to be able to use the interface to also store the data in other structure rather than requiring it to be separate.) One more NIT with the original code: you should not cast the return value of malloc(). It hides bugs. Casper
