Journal Stephen Samuel's Journal: Is the SCO code even copyrightable? 2
static struct ( size_t m_size, char *m_addr } *chunk;
While(there are more chunks){
- if the current chunk is at least as big as we need,{
- take what we need out of the chunk
point the pool pointer to the rest of the chunk
adjust the size indicator.
if we're using the entire chunk,{- move this node to the end of the list.
# (so it doesn't block the search) #
} #endif
return the pointer - move this node to the end of the list.
}#endif
- take what we need out of the chunk
}#endwhile
# couldn't find a big enough chunk
return(NULL) # error
It would be pretty difficult to produce a tight version of this algorithm without a high degree of duplication. I'd say you might as well cut and paste, because about the only changes that I can see making in a tight implementation would be to change the variable names. You'd be lucky to find 4 meaningful permutations of this algorithim, once you tighten up the code for the kernel.
Try to implement the pseudo code above, and see just how far away you end up.
BTW, this is not part of a block of duplicate code.. This is pretty much the entire thing.
If that's the best that they can find, then they're SOL.
If you're not on somebody's shit list, you're not doing anything worthwhile.
Devil's advocate (Score:1)
Well, sure, given that pseudocode, which is a derivative work of SCO's valuable product! ;-) After McBride sweated and struggled for years to come up with the brilliant data structure of a sequential list of things for you to linear search until you find the one you want, then any code monkey can implement it! ;-)
A much better test would be to tell someone what malloc() is supposed to do, and see how they implement it. Then y
Too trivial to copyright (Score:1)
I posted this earlier to a thread at LWN and I'm too lazy to do anything but cut and paste:
Too trivail to copyright (pseudo code) (Posted Aug 19, 2003 22:17 UTC (Tue) by mammothrept) (Post reply)
>"It would be pretty difficult to produce a tight
>version of this algorithm without a high degree
>of duplication. I'd say you might as well cut and
>paste, because about the only changes that I can
>see making in a tight implementation would be to
>change the variable