Limits on 4.2BSD lseek(2)?

[der Mouse]

In article <717 at smeagol.UUCP>, earle at smeagol.UUCP (Greg Earle) writes:
> In the Netnews 2.10.3 4.3bsd-beta 6/6/85 distibution, there is a
> program called article (written by Peter Honeyman, down!honey)
> [which] will take an article message ID, look it up in the dbm
> version of the news history file, and [...]
>
> The problem I have found, is that more often than not, the program will
> blow up on a Bus Error.  [...] The cause of this Bus Error is an
> execution of lseek(2).  [...]
>
> Here is a snatch of the code (from ./misc/article.c in the distribution):
>
> 		...
>                 content = dofetch(*argv);
>                 if (content.dptr == 0) {
>                         printf("%s: No such key\n", *argv);
>                         continue;
>                 }
>                 if (lseek(fd, *(long *) content.dptr, 0) < 0)
>                         continue;
>
> I am finding that it retrieves some articles with no problem, but most of
> them are gagging with the accompaning Bus Error.
> 
> Anyhow, this begs the basic question :
> What are the limits on positioning in an lseek(2) under 4.2BSD?
> What conditions are there, that allow successful completion of the call 
> in some circumstances, and Bus Errors in (most) others?

     I suspect that the problem has nothing to do with lseek().  Why are
you sure  it does?   Merely because article died  on that line?  I would
suspect that content.dptr contains trash, so of course  when  it is cast
to  pointer  to long  it will  *still* be  trash, and we all  know  what
dereferencing  trash does.   According to the  man page  here, lseek can
return the following errors:

	EBADF	if the fd argument is bad
	ESPIPE	trying to seek on a socket
	EINVAL	bad value for whence (the third argument)
	   or	the resulting position is before the beginning
		  of the file.

     I cannot think of any other reason lseek() could fail;  and indeed,
checking  our  source reveals  that indeed, lseek()  cannot generate any
error  except those  listed  above  (VAX 4.2BSD,  Sun  source should  be
similar).  In fact, the second reason  for giving EINVAL is not  checked
by lseek(); presumably it is permissible  for the pointer to go negative
provided  no  read()/write()  operations  are   attempted  while  it  is
negative.

inews: Article rejected - more included text than new text  <	T
inews: Article rejected - more included text than new text	o
inews: Article rejected - more included text than new text
inews: Article rejected - more included text than new text	k
inews: Article rejected - more included text than new text	e
inews: Article rejected - more included text than new text	e
inews: Article rejected - more included text than new text	p
inews: Article rejected - more included text than new text
inews: Article rejected - more included text than new text	i
inews: Article rejected - more included text than new text	n
inews: Article rejected - more included text than new text	e
inews: Article rejected - more included text than new text	w
inews: Article rejected - more included text than new text	s
inews: Article rejected - more included text than new text
inews: Article rejected - more included text than new text	h
inews: Article rejected - more included text than new text	a
inews: Article rejected - more included text than new text	p
inews: Article rejected - more included text than new text	p
inews: Article rejected - more included text than new text  <	y
Now,  netnews  authors,  ask  yourselves:     Isn't  that   kind  of   a
counterproductive thing to have put into inews?
-- 
					der Mouse

USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse
     philabs!micomvax!musocs!mcgill-vision!mouse
Europe: mcvax!decvax!utcsri!mcgill-vision!mouse
        mcvax!seismo!cmcl2!philabs!micomvax!musocs!mcgill-vision!mouse
ARPAnet: utcsri!mcgill-vision!mouse at uw-beaver.arpa

"Come with me a few minutes, mortal, and we shall talk."