On Sun, 6 Feb 2022, lance.lmw...@gmail.com wrote:
On Sat, Feb 05, 2022 at 01:26:18PM -0800, Chad Fraleigh wrote:
Since any [valid] value over 255 is impossible in the IPv4 protocol (the TTL
field is only 8-bits), it should always be capped at 255 (for consistency) or
return an invalid value error (the one I would suggest).
zhilizhao have submit a patch to limit the range of ttl from option. Do you want
to return an invalid error here still?
I have applied the patch, so capping is no longer needed.
Despite VLC's reversed comment, using an int seems to be the exception
to the rule (i.e. only linux and windows seem to use it
[as-documented]), perhaps doing the unsigned char first and using the
int as the fallback would be better? It's not really just a BSD thing,
unless you also count LWIP and Solaris as BSD. Unless VLC's code
history shows them doing it this way at one time and swapping it (but
forgetting the comment) to fix a known bug?
I have blamed vlc code and sure the code doing it this way at one
time(104938796a3).
For the mismatch of code and comments, I prefer to code always as code were
build
and used by all kinds of system which vlc is supported already.
Yeah, I agree, if we are copying VLC approach then probably it makes more
sense to use the same order as they do in their code.
Thanks,
Marton
_______________________________________________
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".
