In context of the CloudFare fiasco, the bug report[1] states this<p>>> My current theory is that they had some code in their "ScrapeShield" feature that did something like this:<p>>> int Length = ObfuscateEmailAddressesInHtml(&OutputBuffer, CachedPage);<p>>> write(fd, OutputBuffer, Length);<p>>> But they weren't checking if the obfuscation parsers returned a negative value because of malformed HTML. This would explain the data I'm seeing.<p>I haven't used C in my professional career (I mainly use Java), so the fact that this function allowed a negative value, for "num bytes to write", to be passed to it and then even went on to write data without throwing an error for passing a negative value baffles me. I'm genuinely curious why this function doesn't throw an error for negative "num bytes to write". Is there any use case which I'm missing where it would be valid to send a negative value and expect it to write negative number of bytes?<p>[1] https://bugs.chromium.org/p/project-zero/issues/detail?id=1139
I've written a gist that somewhat explains this:<p><a href="https://gist.github.com/technion/a16095fa6e3a027d6bc938ad6f9bdc50" rel="nofollow">https://gist.github.com/technion/a16095fa6e3a027d6bc938ad6f9...</a><p>write() doesn't "print a negative number", as per the man page, write(2) takes a size_t for an argument. And what that means is explained if you run that gist:<p><pre><code> We have a count of 18446744073709551611 and will write that many characters
</code></pre>
In short, you're looking at a signed, negative integer, cast to a very large positive integer. clang will only print a warning if you compile with -Wconversion and whilst I like to do that in my own code, most people find that too noisy.<p>Edit: Personally, I feel this "email obfuscation feature" should never have been written in the first place. There are a myriad of options for people to do this in their own website without something this obviously complex being built into an nginx module of a CDN.