On 7/4/2023 5:14 PM, Anton Khirnov wrote:
Quoting James Almer (2023-07-04 22:08:40)
On 7/4/2023 4:59 PM, Anton Khirnov wrote:
Not if any of the functions above were called but failed to fill the buffer.
I could add return AVERROR(ENOSYS) to the HAVE_UNISTD_H block, and
return AVERROR_INVALIDDATA outside.
AVERROR_INVALIDDATA is defined as 'Invalid data found when processing
input'.
This function does not process any input, so IMO that code never makes
sense for it.
I'd say make it ENOSYS, AVERROR_UNKNOWN, or keep around one of
individual method errors.
For the cases read() is used for /dev/random/, i can return
AVERROR(errno), given the doxy states read() returns -1 on error and
sets errno to some value. Although if it succeeds and returns a value
smaller than len i would need to return AVERROR_UNKNOWN like you suggested.
I wonder if we should be trying /dev/random at all. I cannot think of
any remotely sane configuration where /dev/urandom fails, but
/dev/random works. So it only makes sense to use /dev/urandom.
I think the problem is that one may not generate the requested amount of
bytes.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
