On 09/19/2014 02:11 PM, David Herrmann wrote:
Hi
On Fri, Sep 19, 2014 at 10:39 AM, Alexander E. Patrakov
<patra...@gmail.com> wrote:
19.09.2014 14:35, Susant Sahani wrote:
On 09/19/2014 02:00 PM, David Herrmann wrote:
Hi
On Fri, Sep 19, 2014 at 10:28 AM, Susant Sahani <sus...@redhat.com>
wrote:
On 09/19/2014 01:35 PM, David Herrmann wrote:
I don't think that's right. Ignoring the return value of that fcntl is
just fine. We read the buffer-size afterwards, so if it failed, we
still continue properly. See fcntl(2) for a bunch of errors that might
Well I think set and get are two operations. for example let's say set
failed but get success.
setting BUFFER_SIZE failed and in this case buf size is remained as
default
pipe size.
..exactly! And the default buffer size is just fine. We'd prefer if we
could set it to BUFFER_SIZE, but if we're not allowed to do that, we
still continue running with the already set buffer size.
yes but how about giving a log for coverity and we ignore the error ?
How would an admin react to that log message? I'm fine with it being at the
debug priority, but I am not the person who makes decisions here.
Exactly! There is little point in generating those messages.
Lets fix tools, not work around their bugs. Coverity should understand
that ignoring ioctl() return codes is sometimes exactly what we want.
So I'd prefer if we mark it as "false positive".
Well In this exact scenario this makes sense .
Susant
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
