Bug 145093 - NULL used in place where non-NULL required
NULL used in place where non-NULL required
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: vsftpd (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vokal
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-14 06:02 EST by David Binderman
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-17 08:42:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Binderman 2005-01-14 06:02:33 EST
Description of problem:

I just tried to compile package vsftpd-2.0.1-8 from 
Redhat Fedora development tree.

The compiler said

sysdeputil.c:640: warning: null argument where non-null required (arg 3)

The source code is

        retval = sendfile(out_fd, in_fd, NULL, num_send);

Acording to the man page for sendfile, the third parameter must be a valid
pointer. Suggest code re-work.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Radek Vokal 2005-02-17 06:53:07 EST
Which gcc are you using? Did you changed any flags because my output seems to be
clear and I don't have any warnings on my system.
Comment 2 David Binderman 2005-02-17 07:28:14 EST
>Which gcc are you using?

Not sure, judging by the date, a recent gcc snapshot.

>Did you changed any flags because my output seems to be
>clear and I don't have any warnings on my system

I used flags -g -O2 -Wall.

The code stills seems to be wrong, even if you can't reproduce it.
Comment 3 Radek Vokal 2005-02-17 08:42:53 EST
Well, reading a man page, I can't say that this is wrong. The offset doesn't
change so I don't see any need to have a valid pointer there. Anyway it might be
better to report this to upstream with suggestion for rework while it doesn't
produce any bug.

Note You need to log in before you can comment on or make changes to this bug.