3 ms·

The robustness principle applied to memory? Like when the browser adds the missing closing HTML tags instead of telling the dev to fix their code? We sure we wa

The robustness principle applied to memory? Like when the browser adds the missing closing HTML tags instead of telling the dev to fix their code? We sure we want that?

saghm 3y ago
I don't necessarily disagree, but...is this worse than what we already have? My argument against this sort of this for a language like C is that "do what you think I mean instead of what I say" might not actually result in what I _actually_ mean if the compiler guesses wrong, but undefined behavior isn't generally going to do what I want either, so I'm not sure this would be any worse.
- zdragnar 3y ago
  Some people depend on undefined behavior, but there's generally not much sympathy for it, because it is in the name. On the other hand, many people have depended on interpretations of intent. Changing the behavior of one is much easier for the community to swallow than the other. An easy example is how early versions of IE failed to correctly implement the box model for sizing elements. For backwards compatibility reasons, IE6 and on would revert to the old, incorrect behavior if parsing the html document put it into 'quirks mode', and later on this behavior was added as an optional CSS box-sizing property. https://wiki.edunitas.com/IT/en/114-10/Internet-Explorer-box-model-bug_19539_eduNitas.html https://wiki.edunitas.com/IT/en/114-10/Internet-Explorer-box...
olliej 3y ago
Not every html tag has a closing tag. " " parsing is supported in html5 as recognizing self closing xml tags is necessary due to people publishing xhtml with an html mime type. But to be clear it's incorrect: ... is incorrect as is a self closing tag, so the closing tag itself is erroneous. In terms of validation: html5 has a specified parsing algorithm, you can validate html against it. That validation is not xml validation. Again, because html is not xml. There is a very clear specification about how html tags are parsed, trying to reason about html as if it is xml is just as (if not more) incorrect than trying to reason about C as if it were C++. e.g. void f(); Is a different type in C than it is in C++, but if you do this you can't turn around and complain that C and C++ see it as having a different type when the syntax has different meanings.
- the_why_of_y 3y ago
 The reason why people served XHTML as text/html was that Microsoft Internet Explorer didn't recognize application/xhtml+xml. https://hixie.ch/advocacy/xhtml https://hixie.ch/advocacy/xhtml https://www.w3.org/2003/01/xhtml-mimetype/ https://www.w3.org/2003/01/xhtml-mimetype/
 - imtringued 3y ago
 I serve it because my PDF library only supports XHTML and I'm not going to have twice as much HTML just to add a / to br tags.
- sigsev_251 3y ago
 K&R functions were removed from the standard in C23. That function declaration means the same thing now in both languages.
 - teo_zero 3y ago
 You surely meant will be removed in C23?
imtringued 3y ago
You probably want it in your sanitizer.

The robustness principle applied to memory? Like when the browser adds the missing closing HTML tags instead of telling the dev to fix their code? We sure we want that?

saghm 3y ago

I don't necessarily disagree, but...is this worse than what we already have? My argument against this sort of this for a language like C is that "do what you think I mean instead of what I say" might not actually result in what I _actually_ mean if the compiler guesses wrong, but undefined behavior isn't generally going to do what I want either, so I'm not sure this would be any worse.

zdragnar 3y ago
Some people depend on undefined behavior, but there's generally not much sympathy for it, because it is in the name. On the other hand, many people have depended on interpretations of intent. Changing the behavior of one is much easier for the community to swallow than the other. An easy example is how early versions of IE failed to correctly implement the box model for sizing elements. For backwards compatibility reasons, IE6 and on would revert to the old, incorrect behavior if parsing the html document put it into 'quirks mode', and later on this behavior was added as an optional CSS box-sizing property. https://wiki.edunitas.com/IT/en/114-10/Internet-Explorer-box-model-bug_19539_eduNitas.html https://wiki.edunitas.com/IT/en/114-10/Internet-Explorer-box...

olliej 3y ago

Not every html tag has a closing tag. " " parsing is supported in html5 as recognizing self closing xml tags is necessary due to people publishing xhtml with an html mime type. But to be clear it's incorrect: ... is incorrect as is a self closing tag, so the closing tag itself is erroneous. In terms of validation: html5 has a specified parsing algorithm, you can validate html against it. That validation is not xml validation. Again, because html is not xml. There is a very clear specification about how html tags are parsed, trying to reason about html as if it is xml is just as (if not more) incorrect than trying to reason about C as if it were C++. e.g. void f(); Is a different type in C than it is in C++, but if you do this you can't turn around and complain that C and C++ see it as having a different type when the syntax has different meanings.

the_why_of_y 3y ago
The reason why people served XHTML as text/html was that Microsoft Internet Explorer didn't recognize application/xhtml+xml. https://hixie.ch/advocacy/xhtml https://hixie.ch/advocacy/xhtml https://www.w3.org/2003/01/xhtml-mimetype/ https://www.w3.org/2003/01/xhtml-mimetype/
- imtringued 3y ago
  I serve it because my PDF library only supports XHTML and I'm not going to have twice as much HTML just to add a / to br tags.
sigsev_251 3y ago
K&R functions were removed from the standard in C23. That function declaration means the same thing now in both languages.
- teo_zero 3y ago
  You surely meant will be removed in C23?

imtringued 3y ago

You probably want it in your sanitizer.