Right, they probably already mitigated this bug in their own usage. Which is exactly why reporting the bug is a FAVOR to ffmpeg. Would you rather they just quietly fix it on their own and not report it to the maintainers?
Or else what? They release the report? That's standard and ffmpeg is open source anyway, anybody can find the bug on their own. There's no threat here.
If you're mad about companies using your software, then don't release it with a license allowing them to use it. Simple as that. I don't understand how people can complain about companies doing exactly what you allowed them to do.
What does it matter if it's AI generated if it's a real bug? The problem with AI reports is usually that they're invalid; in this case it was an actual bug.
> currently have zero real-world impact
So better we not talk about them until someone bothers to write an exploit for it?
> the "researchers" didn't even bother to write a patch/fix
If it has no real-world impact and thus shouldn't even be reported, then why does it need to be fixed?
There's no law that you have to fix all bug reports. Isn't it better for users and developers alike that they can see the problems of the project. If they don't have resources that's fine, it's not like they are charging money for their product. But why not be honest and not request people sweep bugs under the rug for fear of looking bad?
Google found a vulnerability and reported it for free. Why do they need to do anything more? Give and inch and ffmpeg's twitter guy requests a mile. If you don't want people to use your software to make money, release it with a license that prohibits that.
Yeah, it's actually a great bug report. Reproducible and guaranteed to be an actual problem (regardless of how small the problem is considered by the devs). Just seems irresponsible to encourage people not to file bug reports if it's "insignificant". Why even accept reports then?
VLC is pretty popular on windows, but ffmpeg? Is there any commonly used windows app that relies on it? I doubt it'd be worth one's time to write exploits for desktop linux
Again, you're focusing on a pointless detail. Sure, I made a mistake in offhandedly using li as an example. Why do you choose to ignore the actually valid p example though? Seems like you're more interested in demonstrating your knowledge of HTML parsing (great job, proud of ya) than anything else. Either way, you've given zero examples of benefits of not doing things the sensible way that most people would expect.
That's exactly my point, people are clueless about the basics of nuclear power. Why would they know it? I mean, why would the average person know what a linear equation is or what year the first world war started?
> If there's a bit of water in your lungs, a surprisingly small amount, it causes massive inflammation and your lungs start to fill with fluid. It's called "secondary drowning", and it happens a couple of hours after.
> Secondary drowning, sometimes called delayed drowning, is another term that is not medically accepted. The historical use of this term reflects the reality that some patients may worsen due to pulmonary edema after aspirating small amounts of water.
> Drowning starts with aspiration, and few or only mild symptoms may be present as soon as the person is removed from the water. Either the small amount of water in the lungs is absorbed and causes no complications or, rarely, the patient’s condition becomes progressively worse over the next few hours as the alveoli become inflamed and the alveolar-capillary membrane is disrupted. But people do not unexpectedly die of drowning days or weeks later with no preceding symptoms. The lungs and heart do not “fill up with water,” and water does not need to be pumped out of the lungs.
> There has never been a case published in the medical literature of a patient who underwent clinical evaluation, was initially without symptoms, and later deteriorated and died more than 8 hours after the incident. People who have drowned and have minimal symptoms get better (usually) or worse (rarely) within 4 to 8 hours. In a study of more than 41,000 lifeguard rescues, only 0.5% of symptomatic patients died.
Maybe don't set too much store by what some random "water rescue course" instructor tells you, especially if it sounds like complete bovine excrement.
Well, just because something is allowed by the syntax does not mean it's a good idea, that's why pretty much every language has linters.
And I do think there's an evenly applied rule, namely: always explicitly close all non-void elements. There are only 14 void elements anyway, so it's not too much to expect readers to know them. In your own words "there's no substitute for actually knowing the real rules".
I mean, your approach requires memorizing for which 15 elements the closing tag can be omitted anyway (otherwise you'll mentally parse the document wrong (i.e. thinking a br tag needs to be closed is equally likely as thinking p tags can be nested)).
The risk that somebody might be expecting a closing tag for an hr element seems minuscule and is a small price to pay for conveniences such as (as I explained above) being able to find and replace a p tag or a li tag to a div tag.
Are you misunderstanding on purpose? I am aware they are optional. I am arguing that there is no reason to omit them from your HTML. Whitespace is (mostly) optional in C, does that mean it's a good idea to omit it from your programs? Of course a br tag needs no closing tag because there is no content inside it. How exactly is that an argument for omitting the closing p tag? The XML standard has no relevance to the current discussion because I'm not arguing for "starting to treat it like XML".
The merits and drawbacks of XHTML has already been discussed elsewhere in the thread and I am well aware of it.
> And at a time when there was legitimate browser competition, the one that made a "best effort" to render invalid content was the winner.
Yes, my point is that there is no reason to still write "invalid" code just because it's supported for backwards compatibility reasons. It sounds like you ignored 90% of my comment, or perhaps you replied to the wrong guy?
As the saying goes, "a little bit of knowledge is a dangerous thing". Your "water rescue course" taught you something that's clearly wrong, as we see with the sibling comment, while my common sense and just everyday life experience led me to the correct conclusion.
It's an analogy, there's no need to analyze it literally. And no, I've worked with some devs who don't understand git (thankfully I don't anymore) and it was quite a bit more than "five times" they got stuck or messed up the repo on the remote in an annoying way. Sure, if you regularly write code using a bunch of evals or gotos "nothing bad will happen" but it's a very suboptimal way of doing things.
"Intimately understand the VM" is not the same as knowing what data structure you're using. It'd be comparable to not knowing the difference between an array and a linked list. Sure you may call it gatekeeping but likewise I may call your style willful ignorance of the basics of the tools you're using. Have you never used rebase or cherry-pick?