pcap_dump should return -1 on fwrite error #1047
Comments
|
We could do that, but it's not enough in the end. |
|
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
<#1047 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABLO26SFFYB4ROGCFBJIXDT6RDWDANCNFSM5CXZMKPQ>
.
|
5 tasks
|
This should be provided with any new file-writing APIs added for issue #1321. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 checkferror(stream)after each call topcap_dump. A better solution would be to return -1 frompcap_dumpon 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 aint pcap_dump2(...). What do you think?The text was updated successfully, but these errors were encountered: