misc/m3u: Split m3u metadata write so that newline is infallible

This basically fixes #28641, at least the part where user data is irreversibly lost.

Writing metadata to file may still fail, and it appears there is nothing VLC can do about that, but with this fix, all tracks will still be present in the resulting file, and will not be lost on m3u file read+write.

Thanks

Thanks for your contribution!

When all of the following conditions are fulfilled, your MergeRequest will be reviewed by the Team:

• the check pipeline passes
• the MR is considered as 'mergeable' by gitlab

You can find more details about the acceptance process here.

This message was automatically generated by homer-bot.

added MRStatus::Reviewable label

Nit: you could use fputs() for that and move it out of the if() block.

changed milestone to %4.0

added 1 commit

• 0c2812ee - Minor improvements

Compare with previous version

Also nitpicking: use descriptive description of your commit titles. For example "minor improvement" gives zero information about what is happening to the code.

You can also prefix the titles with the file(s) and or module(s) you're changing. See how we usually do it: https://code.videolan.org/videolan/vlc/-/commits/master/?ref_type=undefined

And finally, please put the description of why you're making this change in your first commit description.

changed title from Split m3u metadata write so that newline is infallible to misc/m3u: Split m3u metadata write so that newline is infallible

Also nitpicking: use descriptive description of your commit titles. For example "minor improvement" gives zero information about what is happening to the code.

I assume the commits will be squashed in the end, no?

And finally, please put the description of why you're making this change in your first commit description.

Is there any way to do that from the web IDE?

I assume the commits will be squashed in the end, no?

No, you're responsible for your commits.

Is there any way to do that from the web IDE?

AFAIK it's based on VSCode, by default I think it doesn't have "interactive rebase" to handle that. Maybe it can do git from the command line. So you can do something like git -i rebase origin/master.

This both misleading and wrong. If there is an I/O error, it will be detected upon the new line anyway, due to line buffering (C11 §7.23.1). So all this does is make the code more complicated and slower.

There are two ways to handle errors: abort the output and pass the error upward, or seek to a known good point and resume (which will clear the error flag on the FILE). This is doing neither.

It may be too early in the morning for me, but could you please explain why this is not doing the latter?

Because when you have I/O errors, here fputws seems to return EOF, on a FILE stream flags are set and your internal buffer is in a undefined state. It might be flushed, might be garbage, you just cannot know and it will depend on your CRT.

As Rémi said, if you want to handle the error internally you should probably call ftell() before trying to call, pf_fprintf then check its return. If it's EOF you should probably fseek back to the position (which will clear the flags and the internal buffer) that ftell gave you then only write the file MRL.

Edit: scratch the last part since the function is also used for m3u8 you need at least the #EXTINF:<duration>,\n

added MRStatus::InReview label and removed MRStatus::Reviewable label

added MRStatus::Stale label and removed MRStatus::InReview label