James Almer (12021-06-27): > You asked No, I did not ASK: I told what needs to be present in the documentation.
> I know well strings are your field of expertise and hardly mine. Don't > wrongly assume the other person has ill intentions. I am not assuming any ill intent from you. Why would you think that? This is the second time in a few days that you accuse me of personal stuff like that. Please re-calibrate your opinion of me. > It's literally having a list of raw filenames in a file, where the delimiter > character can be part of the filename and as such needs to be handled. I'm > not writing a new language, or new escaping rules. I don't see how it's so > unacceptable. What you just described IS precisely a new set of escaping rules. It is very very simple, but it is a set of rules. A new one, while we already have one. And of course, you are re-implementing it, which in itself cannot be accepted. > Can you point me in the right direction then? What functions should i use? I already pointed you in the right direction: read the whole file, and then use the standard parsing and de-escaping functions. Your use of av_get_token() in the first patches was good. The flaw was using them on separate lines instead of the whole file: you ended up with both ff_read_line_to_bprint_overwrite() and av_get_token() handling the new line characters, in a subtly different way. You needed to get rid of one of them, the one that does only a small part of the work, to keep the one that can do the whole work. 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".
