Anton Khirnov: > Quoting Andreas Rheinhardt (2024-03-12 10:21:52) >> Anton Khirnov: >>> Quoting Andreas Rheinhardt (2024-03-12 09:56:46) >>>> Anton Khirnov: >>>>> Otherwise it might conflict with caller-defined identifiers. >>>>> >>>>> ff because it is not supposed to be used by external callers. >>>>> --- >>>> >>>> This is public, so it should be av_attribute_deprecated. >>> >>> As the commit message says, this is not supposed to be used by external >>> callers. Or do you see any reason why it should be public? >>> >> >> It is public given that it is declared in a public header. That is what >> matters. > > I agree that it is (implicitly) public now, but the question is whether > it should be. IMO it should not. Do you disagree? >
It needs to be available in a public header given that deprecations are supposed to convey information to the public. If you are asking whether we should add a note like the one for the FF_API_ defines: I don't have formed an opinion on that yet. >> Furthermore, we have used the FF_ and AV_ prefixes for public macros and >> the av_ prefix for public symbols, but IIRC we do not use the ff_ prefix >> for public symbols at all, therefore I'd like us not to reserve another >> namespace. > > We do reserve the ff namespace for private identifiers that need to be > exposed, e.g. in public headers or when linking statically. > We reserve the FF_ namespace in public headers, not the ff_ namespace. If I am not mistaken we never use the latter namespace in public for stuff without linkage (i.e. a project could use the ff_ namespace for macros/enums without conflicting with FFmpeg). - Andreas _______________________________________________ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
