On 2024-06-02 13:30 +0300, Rémi Denis-Courmont wrote: > Le sunnuntaina 2. kesäkuuta 2024, 13.04.05 EEST Alexander Strasser via ffmpeg- > devel a écrit : > > On 2024-05-29 18:51 +0300, Rémi Denis-Courmont wrote: > > > Le keskiviikkona 29. toukokuuta 2024, 18.44.13 EEST Andreas Rheinhardt a > > > écrit> > > > > > +static double ff_scalarproduct_double_c(const double *v1, > > > > > > > > Don't use an ff_ prefix for a static function. > > > > > > I can see over 300 such identifiers in the code base (many but not all > > > inline), and I don't see why that would be a problem. > > > > I agree that it's not a problem regarding on the functional side, > > OTOH regarding coding conventions we try to consistently follow it's > > misleading as the ff_ prefix indicates a bigger scope of sharing. > > Anybody can see the 'static' qualifier literally in front to see the function > is not in a bigger scope of sharing. And if you do somehow miss and try to use > the function, you will get a linker error. > > The only case where this *actually* matters is in debugging. And exactly then > it is much better to use the ff_ prefix *because* all symbols, including local > ones like this, end up sharing the namespace.
But not at the call site? > > I think Andreas remark is correct and it would be better to not use ff_ > > prefix wrongly when adding new code. > > IMO, it is worse. I tend to disagree here as it makes the meaning of the ff_ prefix arbitrary. Anyway if you want to challenge this convention we are using since many years in this code base, I suggest to do it in a separate discussion thread. Alexander _______________________________________________ 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".
