[RFC] Change sendfile header

[RFC] Change sendfile header

[Bill Davidsen]

I suggest that the header holding the prototype for sendfile should not be
in unistd.h because:

1 - sendfile is not in SuS, an is extremely non-standard
2 - there is a sendfile in BSD and it's totally different
3 - there is no man page for sendfile in Solaris, but there is a
    definition in one of the libraries which is not Linux compatible
4 - just putting the "not portable" warning in the man page to counteract
    the impression given by the <unistd.h> is not enough, programmers
    usually only read the man page  to get the args right.

Since Linux sendfile is totally applicable only to Linux, it would seem
that a better name for the header file, like linux/sendfile.h, would be
better. This has the advantage of not breaking executables, and requiring
use of a header file which makes it much harder to overlook the
portability issue.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [RFC] Change sendfile header

[Ulrich Drepper]

Bill Davidsen wrote:
> I suggest that the header holding the prototype for sendfile should not be
> in unistd.h because:

Why do you complain?  And why here?

The sendfile prototype is in <sys/sendfile.h> and not in <unistd.h>.
So, what do you want?  sys/ is the directory for system-specific headers
so this is exactly the place to put this header.  And as for the rest:
apparently people already had ideas like this just much earlier and you
didn't even bother to check.

-- 
--------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------

Re: [RFC] Change sendfile header

[Christoph Hellwig]

On Wed, Jan 29, 2003 at 10:03:04PM -0500, Bill Davidsen wrote:
> I suggest that the header holding the prototype for sendfile should not be
> in unistd.h because:
> 
> 1 - sendfile is not in SuS, an is extremely non-standard
> 2 - there is a sendfile in BSD and it's totally different
> 3 - there is no man page for sendfile in Solaris, but there is a
>     definition in one of the libraries which is not Linux compatible
> 4 - just putting the "not portable" warning in the man page to counteract
>     the impression given by the <unistd.h> is not enough, programmers
>     usually only read the man page  to get the args right.
> 
> Since Linux sendfile is totally applicable only to Linux, it would seem
> that a better name for the header file, like linux/sendfile.h, would be
> better. This has the advantage of not breaking executables, and requiring
> use of a header file which makes it much harder to overlook the
> portability issue.

You're rant is totally inappropinquate because:

 1 - this is a glibc issue, applications should not include kernel
     headers
 2 - there is no sendfile declaration in glibc's <unistd.h>
 3 - there _is_ a <sys/sendfile.h> for sendfile(64) in glibc
 4 - solaris _does_ have a linux-compatible sendfile now

Re: [RFC] Change sendfile header

[Bill Davidsen]

On Thu, 30 Jan 2003, Christoph Hellwig wrote:

> You're rant is totally inappropinquate because:
> 
>  1 - this is a glibc issue, applications should not include kernel
>      headers

Since it's a system call I felt it was at least worth mentioning.

>  2 - there is no sendfile declaration in glibc's <unistd.h>

This is most odd, the system on which I discovered the problem most
definitely says in the man page that it's <unistd.h> Quite honestly it
didn't occur to me to check other systems... And sendfile is defined on
that system in unistd, and works.

>  3 - there _is_ a <sys/sendfile.h> for sendfile(64) in glibc

See above, I just converted an app to use sendfile, that's how this
discussion came up.

>  4 - solaris _does_ have a linux-compatible sendfile now

The only sendfile I found was in libucb and is BSD compatible, there is no
man page. The two Solaris machines are less than a year old, so I'm not
sure what release you mean by "now" and can't check before Monday, as I
have no Solaris machines here.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.