| Message ID | HE1PR0301MB2154B6FDB5321698FA3F70BB8F789@HE1PR0301MB2154.eurprd03.prod.outlook.com |
|---|---|
| State | Accepted |
| Commit | 0617e578a3ebd22ccc2ec136d65b529ca60fd5b9 |
| Headers | show |
| Series | [FFmpeg-devel] avfilter/vf_find_rect: Use correct format specifier | expand |
| Context | Check | Description |
|---|---|---|
| andriy/x86_make | success | Make finished |
| andriy/x86_make_fate | success | Make fate finished |
| andriy/PPC64_make | success | Make finished |
| andriy/PPC64_make_fate | success | Make fate finished |
On 2021-04-04 15:01, Andreas Rheinhardt wrote: > Fixes the following GCC warning: > warning: format ‘%lld’ expects argument of type ‘long long int’, > but argument 4 has type ‘int64_t’ {aka ‘long int’} [-Wformat=] Weird. I switched to lld because gcc (10.2) recommended it. In fact, I just looked through the build log for my Windows build compiled minutes ago, and there's no warning. Regards, Gyan
Gyan Doshi (12021-04-04): > > Fixes the following GCC warning: > > warning: format ‘%lld’ expects argument of type ‘long long int’, > > but argument 4 has type ‘int64_t’ {aka ‘long int’} [-Wformat=] > > Weird. I switched to lld because gcc (10.2) recommended it. > > In fact, I just looked through the build log for my Windows build compiled > minutes ago, and there's no warning. There is nothing weird about it: the int64_t type and its type specifiers exist specifically because long and long long have different meanings on different compilers. If you are writing new C code with explicit references to long or short, you are almost certainly doing it wrong. Regards,
Gyan Doshi: > > > On 2021-04-04 15:01, Andreas Rheinhardt wrote: >> Fixes the following GCC warning: >> warning: format ‘%lld’ expects argument of type ‘long long int’, >> but argument 4 has type ‘int64_t’ {aka ‘long int’} [-Wformat=] > > Weird. I switched to lld because gcc (10.2) recommended it. > > In fact, I just looked through the build log for my Windows build > compiled minutes ago, and there's no warning. > long int is 32bit on Windows, so int64_t can't be a typedef for long int on said plattform; instead it is a typedef for long long int. That's why one should use these PRIdx macros, because they will automatically be converted to the correct system-dependent format specifier. - Andreas
On 2021-04-04 15:29, Andreas Rheinhardt wrote: > Gyan Doshi: >> >> On 2021-04-04 15:01, Andreas Rheinhardt wrote: >>> Fixes the following GCC warning: >>> warning: format ‘%lld’ expects argument of type ‘long long int’, >>> but argument 4 has type ‘int64_t’ {aka ‘long int’} [-Wformat=] >> Weird. I switched to lld because gcc (10.2) recommended it. >> >> In fact, I just looked through the build log for my Windows build >> compiled minutes ago, and there's no warning. >> > long int is 32bit on Windows, so int64_t can't be a typedef for long int > on said plattform; instead it is a typedef for long long int. That's why > one should use these PRIdx macros, because they will automatically be > converted to the correct system-dependent format specifier. Ok. LGTM. Regards, Gyan
diff --git a/libavfilter/vf_find_rect.c b/libavfilter/vf_find_rect.c index b6f5a1be29..5f3abf66c6 100644 --- a/libavfilter/vf_find_rect.c +++ b/libavfilter/vf_find_rect.c @@ -217,7 +217,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in) } } - av_log(ctx, AV_LOG_INFO, "Found at n=%lld pts_time=%f x=%d y=%d with score=%f\n", + av_log(ctx, AV_LOG_INFO, "Found at n=%"PRId64" pts_time=%f x=%d y=%d with score=%f\n", inlink->frame_count_out, TS2D(in->pts) * av_q2d(inlink->time_base), best_x, best_y, best_score); foc->last_x = best_x;
Fixes the following GCC warning: warning: format ‘%lld’ expects argument of type ‘long long int’, but argument 4 has type ‘int64_t’ {aka ‘long int’} [-Wformat=] Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com> --- Will apply soon. libavfilter/vf_find_rect.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)