>> - uiopeek leaves uio itself untouched ([...]). > Hmâ?? Iâ??m having second thoughts about uiopeek(), as well. It implies a d$
That is a good point. But would it be a problem to have uiopeek (works only to move from uio to buffer) and uiopoke (the other way)? I've never liked the way uiomove can move data one direction or the other depending on how the uio is set up. (I'd rather have uioread and uiowrite except that I'd be constantly trying to remember whether uioread reads from the uio or moves data in the direction a read() operation does.) Maybe uioget and uioput? Is there any significant amount of code that calls uiomove without knowing which direction the bits are moving? As for uiocopy versus uiomove, those are similar enough to memcpy and memmove that the implication feels to me more like "buffers can overlap" (for all that that is a highly unlikely use case) or some such. Finding good names is a mess. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
