On 2012-04-23 23:03, Guillem Jover wrote:
> 
> Hi!
> 
> While rebuilding packages for the new libbsd 0.4.0 upload, this package
> fails to build consistently on at least my system, and it might seem
> like on at least the mips buildd too, I've not investigated in detail
> what exactly is triggering this only on these systems and not others,
> but I think it's due to me having 3 network interfaces (lo, eth0, wlan0),
> in any case there's a bogus fflush() on an input stream which is causing
> wrong subsequent fseek()s. The behaviour of fflush() in input streams is
> not usually well defined and in this case is not really needed, fseek()
> should just do fine.
> 
> Attached a patch fixing this. And here's the failure mode:
> 
> [...]
> 
> thanks,
> guillem

Hi,

Thanks for the report.

I must admit I am a bit confused.  The fflush code is in the src/Linux
part and according to [1] fflush should be well defined on Linux.  So I
do not immediately see why the fflush should be removed from there.

Also, libbsd is only used when building on (k)FreeBSD, in that case
src/FreeBSD will be used as I understand the makefile[2] (and its
network.c does not have the fflush call).  So I do not see how removing
the fflush call in src/Linux will help in this case either.

Then there is the test error. "Cannot allocate memory" suggests a ENOMEM
or so is returned, but I do not see a code path in
sa_reset__netinterfaces() for Linux that could return ENOMEM.  On the
other hand sa_reset_net_interfaces on (k)FreeBSD has such a return (line
76).


My primary concern here is that I will be unable to convince upstream
why this patch is correct/needed.

~Niels

[1] http://linux.die.net/man/3/fflush

"""
For input streams, fflush() discards any buffered data that has been
fetched from the underlying file, but has not been consumed by the
application. [...]

The standards do not specify the behavior for input streams. Most other
implementations behave the same as Linux.
"""

[2] src/CMakeLists.txt




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to