James Almer (12021-03-24): > Because it's not even a pointer that's guaranteed to be valid or point to > valid data until the next call to one specific function or set of functions > (Your example is basically av_dict_get(), where only calls to av_dict_set*() > on a AVDictionary you own will make previously returned AVDictionaryEntry > invalid), and instead it's a pointer that may or may not be valid after the > next call to potentially *any* lavf function, because it could be modified > by reading the header, reading a packet, and maybe more cases, all depending > on demuxer, and after which it could still be pointing to the desired entry, > or to some other entry, or to freed memory.
What you say is true, but it is absolutely not a problem if the user access the pointer immediately, before calling any other function, just like it is supposed to do when derefencing ctx->streams. > In any case, would a > > int av_get_index_entry(AVStream *st, int idx, int64_t *pos, > int64_t *timestamp, int *size, > int *distance, int *flags); > > implementation, which is basically the inverse of av_add_index_entry(), be > ok instead? No AVIndexEntry usage, only the fields the caller cares about > can be returned, and no "This pointer will autodestruct in five seconds" > situation. I will not block it as I would block the version with dynamic allocation, but you will need a little more work to convince me that this is better than just returning the pointer. You make more work for yourself and more work for the user, you have to have a good reason for it. Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ 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".
