Re: [Libcdio-devel] read.h needs unistd.h

[R. Bernstein]

Steven M. Schultz writes:
 >      Hmmm, I hope it's not fseek when dealing with DVDs.  fseek() is
 >      limited to 'long' for the offset and that could have problems
 >      with DVDs  (definitely so with double layer DVD media which can be
 >      ~7.95GB).

Right now libcdio handled CD's, CD and ISO images and "long int"
should cover that. When libcdio deals with UDF images and DVD's, then
fseek will have to change. Thanks for pointing that out.

 > > responsibility for making sure that's okay. But not for precognition
 > > of what an application might be doing and including other headers on
 > > its behalf.
 > 
 >      The thought was just that off_t and seeking do tend to be used
 >      together  

That's your judgement call. MPlayer's very limited use however seems
not to do seeking and doesn't probably doesn't need unistd.h. More
importantly, we're striving for precision here.  Otherwise I would
have just applied the patch.

 >  - that's my guess why adding <unistd.h> "solved" the
 >      problem. 

It "solved" this problem by adding stuff not needed which then pulls
in the thing that *is* needed. But the additional overhead may cause
breakage somewhere else on some other platform or in some other
context. Adding stuff that isn't needed adds unnecessary dependencies
and increases likelihood of breakage. On the GNU Make source code, I
have had breakage due just because of the *order* of the way various
headers were included.