begin quoting James G. Sack (jim) as of Sat, Sep 30, 2006 at 01:43:51AM -0700: [snip] > Hmmm, your code is storing pointers to the data, which I _don't think_ > is the usual need (especially for interrupt server routines, for example).
For interrupt server routines, you'd rewrite the code for your particular data type anyway. For a reusable routine, void * is the way to go, as you can then handle *any* sort of data. > It's interesting, I think that we both implemented a required-hole > method for keeping full and empty from being confused, and incidentally > avoid any critical section worries. Yup. It seemed more elegant to do that than to allocate another element in the structure to keep track of empty/non-empty status, and then to have the additional overhead of checking such things. > Other than the data vs pointer thing, you expressed in indices what I > did with pointers, and I choose a slightly roundabout pointer > initialization (using pLastPut instead of pNextPut). It seemed a clearer way to express what I was doing. To me, at least. :) > Your code & coding style is definitely more polished and finished. The > encapsulation as an object gets extra-credit pizzas! Heh. Thanks. "I are a programmer^UI am a porgarmmar^UI isa prorgamamr^UI write code." > It seems to me that you might have freed the cbuf if the data malloc > failed. Oops, need one more unit test for memory leak, eh? I didn't > take the time to review your tests, so I can offer no feedback there, sorry. Yeah, I caught that after posting. :) I've forgotton how to remap a system call. The unit test will need to replace malloc() with it's own version, that will check a global variable that would limit the size of a malloc request, and then if the requested amount of space is less than the limit, pass on the call to malloc. I know *how* to test it... But it's that first trick I don't remember how to do. Wanna pick this up in LPSG? > I might explain my choice of interface returning true/false and > requiring a buffer on the get. NULL on failure is certainly a time > honored tradition, but I believe one can argue against it. No so much > here as in things like getc() where the return type has to be butchered > to be able to indicate failure. But anyway, I kind of like making the > user pass his own buffer which I fill. It perhaps calls attention to the > need to test the return value. I picked up a dislike of "allocate your own buffer" some time ago; I like my modules being responsible for creating and destroying the data structures, and the code that uses it treating it as an opaque type. I had pondered making the functions take void* instead of CircBuf*, and hiding the structure in the .c file to enforce that, but that wasn't the point of the exercise. :) > PS, how did you find my code? Bicarb-time? I had to puzzle it out a bit. The intialization macros took some effort to see how they worked. But you wrote a lot less code than I did, so your code does more in less space than mine. Plus, you store actual data, so it's better for things like storing characters. -- _ |\_ \| -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
