On Sun, Apr 14, 2002 at 06:45:29PM +0200, Wolfgang J?hrling wrote: > Wolfgang J?hrling <[EMAIL PROTECTED]> wrote: > > Wolfgang J?hrling <[EMAIL PROTECTED]> wrote: > > > Looking at what glibc/hurd/fd-read.c does, it seems to be a leak to not > > > check for equality and freeing the buffer. Does anyone agree/disagree? > > > > Well, I think I have to disagree with me here. :*) > > And I think that Wolfgang was right (Uh, I'm feeling a bit schizophrenic > today %-)), because the following program does not segfault:
I have no time to look into the various example code and tell which is right or not. But I can tell you some general rules: 1. When programming in C, all resources that are not released by someone else have to be released by yourself (well, obviously :) 2. Usually, nobody does it for you. In particular, there is no general garbage collector unless you use one. 3. Sometimes library functions consume a resource. In this case you should not free it. 4. Sometimes library functions allocate resources for you. In this case you have to free it yourself. Now specifically to the Hurd: io_read uses the Mach buffer return semantics. This means that you can provide a buffer, and it might be used and filled with the data. But you might also pass 0 if you don't allocate a buffer. In any case (regardless if you provide your own buffer or not, and regardless of its size), the caller might provide you with a different buffer, and fill that. In this case you will notice that the buffer pointer was changed. If you provided your own buffer, you have to free it yourself of course. If you got a different then your own buffer back, you have to free that one also after using the data. One important case where you might get a different buffer back is if your provided buffer was too small. However, even that is not definite, some kernel RPCs use the size of the buffer to switch compatibility modes. (eg the various _status RPCs). There is no definite rule for this, you always have to check the buffer pointer and return value to see what happened. In the Hurd, a different buffer is usually only allocated it the provided buffer was too small. This is the client side. Now the server side: For servers, the situation is very convenient, because mig does some of the work for you. If you allocate your own buffer, you can just return that and don't care about the buffer passed to you by mig. In this case, there are two options: You want mig to copy this data, or you want it to consume the data. Sometimes you want to make this decision at runtime. If you give the dealloc flag, then mig will consume the data, and the buffer will be freed when MiG has copied it to the client. Otherwise, MiG will assume that the server needs the data later on itself, and will not free it. you can even make mig to have another parameter in the server stub that allows you to specify if you want to have the data consumed or not by mig on a per-call basis, but I forgot how (hell, given my current state of memory it could even be that this is the default already ;) See the server writer manual for details on that. So, if you don't want to leak memory on the client side, always release any buffer you allocated or get from mig. If you don't want to leak memory on the server side, use dealloc for buffers you allocate when processing the RPC and are returned to the caller (realize that otherwise you can not garbage collect this data if you don't store away the information about it somewhere else), or if you return data buffers that are used longer than just for one RPC reply, you can leave dealloc out to avoid having MiG releasing it. (I think we do this in auth right, where I think we are still violating some rules of being sane, because we return non-page aligned buffers allocated with malloc). (I am also not sure if trailing data on the last page is visible to the caller under some circumstances, which would be a potential security problem). Thanks, Marcus _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd
