pcap_dump should return -1 on fwrite error

[rigtorp]

Currently it's cumbersome to detect if there was an error when writing to a dump file. You need to use pcap_dump_fopen(stream) and then check ferror(stream) after each call to pcap_dump. A better solution would be to return -1 from pcap_dump on any error. Given the C ABI on x32 and x64 it's safe to modify this call to return an int, maybe not on all platforms? Safest solution would be to add a int pcap_dump2(...). What do you think?

[mcr]

We could do that, but it's not enough in the end. That's because some errors (like NFS ones, and other clustering systems) aren't returned until you fclose() the file. The dump API needs a major overhaul, but I don't object to either solution.

[rigtorp]

Yeah I do pcap_dump_flush before closing, but there's no way to get the return value from fclose.

I'll open a MR to make these minimal changes.

Any new API should not use FILE*. Instead opting for a custom callback interface. Supporting using writev with iovec of pkthdr and payload would be nice. Also async writing with iouring, but that would need changes to capture API too: something like pcap_free_packet().

On Wed, Aug 25, 2021, 03:48 Michael Richardson @.***> wrote:

We could do that, but it's not enough in the end. That's because some errors (like NFS ones, and other clustering systems) aren't returned until you fclose() the file. The dump API needs a major overhaul, but I don't object to either solution.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/the-tcpdump-group/libpcap/issues/1047#issuecomment-905104201, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABLO26SFFYB4ROGCFBJIXDT6RDWDANCNFSM5CXZMKPQ .