On Mon, Apr 13, 2026 at 02:29:35PM +0200, Michael Niedermayer via ffmpeg-devel wrote: > Hi > > On Sun, Apr 12, 2026 at 06:41:39PM +0200, Michael Niedermayer via > ffmpeg-devel wrote: > [...] > > Examples: > > https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20005#issuecomment-36271 > > https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20059#issuecomment-36273 > > She found her first out of array write yesterday > https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20627#issuecomment-36294 > > Also she almost made 2 mistakes, and decided to think harder from now on > Her markdown skills should have improved and she is now using 2 vector > stores > she will probably soon attempt for the first time search the web while > thinking > (we need that because with external libs their APIs and also whats supported > in what version can matter) > > she also will try to refer to patches by their hash instead of calling them > "patch 1" > (which confused me)
More news * Ive rewritten teh prompt * references she uses now should be presented as clean file pathes * she can recognize if someone adds a bug and then fixes it in a separate patch (example below) * she should now also suggest using existing helper functions * she now can search the web if she wants more that i probably forgot https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21291 Thanks for looking into this. I do not think 87c6b4ab8a is ready yet. The main problem is that this changes the MinGW call site from snprintf to __mingw_snprintf, but it does not actually make the formatted output size provably safe. The code still reserves a fixed 19-byte payload via DURATION_STRING_LENGTH, formats with %02d:%02d:%012.9f, and then writes exactly DURATION_STRING_LENGTH bytes into the Matroska tag. %02d is only a minimum width, so once the duration exceeds 99 hours the hours field grows and the string can still be truncated logically. In other words, this hides the warning on one toolchain instead of fixing the underlying formatting issue. Please fix the formatting itself, or explicitly constrain the values so the reserved 19-byte tag is always valid. Related to that, using __mingw_snprintf directly looks like an ad-hoc CRT-specific workaround. FFmpeg already has compat wrappers for snprintf/vsnprintf; if a Windows-specific workaround is really needed, it should go through the existing compat layer instead of introducing a one-off MinGW call here. Minor points: cafb3e1880 is just a fixup for the previous patch, so please squash the series before merge, and the final commit message should describe the actual bug and the chosen fix rather than just repeating the compiler warning text. Sources: libavformat/matroskaenc.c compat/msvcrt/snprintf.h compat/msvcrt/snprintf.c [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
