Date: Tue, 11 Nov 1997 01:25:54 -0500 From: Jerry Hicks <wghhicks@ix.netcom.com> To: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org> Cc: freebsd-chat@freebsd.org Subject: Re: Possible Kernel Bug? Message-ID: <3467FA72.2536360D@ix.netcom.com> References: <Pine.BSF.3.96.971110194629.1253A-100000@trojanhorse.ml.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[moved to -chat] Jamil J. Weatherbee wrote: > > I may be dead wrong about this but it is worth a try: > > void *data; > void *data_end; > > lets say you are passed a struct buf with a data buffer bp->b_data > and bp->b_bcount = 1000; > > if you say data = bp->b_data /* this is fine */ > what about data_end = bp->b_data + bp->b_bcount /* this pointer could > point to something nonexistent??? */ Uh-uh... that ain't legal. (How wide is a void?) This works tho... data_end = &((caddr_t) bp->b_data)[bp->b_count]; or data_end = ((caddr_t) bp->b_data) + bp->b_count; (apologies (for (my (lisp-ish (tendencies] > > so dereferencing it is definetly a no no (and that is not being done) but > I see places where data compared to data_end , now since caddr_t is > defined as , such as while (data < data_end) > > typedef char *caddr_t; > which i assume is represented as a 32 bit unsigned integer void pointers can be compared against each other, no prob. It's an address that gets compared, remember. One can't dereference void pointers for comparison as you correctly indicated. What *does* a void point to? (I just checked my inbox and saw Chuck's reply. Gotta dig out the reference but I do believe that comparisons of void pointers are legal. Math isn't. There used to be some concerns about portability but these are probably of little concern with modern processors. For instance, DG Eclipse processors had different representations of pointers for integers and characters residing at the same physical location in memory). Now where is my Harbison & Steele... > > are you guaranteed that the byte 0xffffffff is never allocated? In theory it's a problem. In practice I don't think it's gonna happen. > this should be true in addition to 0x00000000 never being allocated. Cheers, Jerry Hicks jerry_hicks@bigfoot.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3467FA72.2536360D>