And it's still the iceberg that doesn't float like that.
Has anyone ever drawn anything on that page that wasn't a dong?
Looking up some of this stuff has given me temporary psychosomatic paralysis. But I have to admit, some of it is really fun gossip
You know, people complain about alloca() and yet they don't think twice about doing:
foo (int somecount)
Which is basically the same goddamn thing. This atrocity started out life as a GCC extension, and then so many people used it that they made it part of the C standard.
I mean, it's not like anyone needs yet another reason to dislike Richard Stallman, but there you go.
I would have assumed that he had little to nothing to do with gcc's technical design since the mid 90s.
Recent gcc has gotten waaaay more aggressive about optimizing out-of-scope things: apparently this results in a free memory reference now:
const char *host = "???";
struct utsname uts;
if (! uname (&uts))
host = uts.nodename;
I think variable sized arrays were introduced with the C99 standard, and I remember seeing GCC doing it long before that.
Regarding your example, your code may actually be violating some obscure scoping rule in the C standard which now been exposed by the more aggressive optimizations in newer versions of GCC, rather than GCC doing something wrong. (If possible, see what Clang/LLVM does.)
I do know that one of the worst places where optimization can bite you is with strict aliasing violations, but I don't think that applies here.
host points to a member of uts, and uts is destroyed when the braced block returns. Anything that uses host after that will be a UAF bug, since it's pointing into freed stack memory. struct uts is pretty big so it'll probably work, but it's not correct.
A correct function would use something like host = strdup(uts.hostname) to make sure the thing host points to survives past the end of the brace block. In this case we could instead make uts static, since the hostname isn't likely to change between calls to this function, but that wouldn't work for all portability cases (e.g. something that changes often, like clock_gettime). Can't remove the braces without offending old compilers. Putting uts up with the other variables in its own #ifdef block would work (there are no braces, so nothing goes out of scope), but is uglier.
It is kind of cool that gcc can detect things like this now. It's a bit more annoying when gcc tells you that "*(foo.bar+8)" isn't initialized--you have to figure out which line of a thousand-line function is doing the equivalent of that pointer math, because gcc won't tell you anything more than the function name it found the error in. You also have to figure out which variable *(foo.bar+8) points to (hint: it's not foo.bar).
I love doing that! :'D
Having automatic arrays with dynamic size actually mirrors what's in Fortran 77 and therefore part of the lower layers of any modern compiler anyway. Lots of good reasons to make it available to C programmers together with the more flexible array bounds in C99. Not having this feature only eliminates one of a myriad opportunities to write exploitable programs in C. I don't understand why it was made optional in C11 and why some people are so vehemently against it in a language where pointer arithmetic exists.
I recognize that Windows serial... why god, why?!
The script won't get run if the SVG is rendered as the src of an .
1. In Firefox and Chromium, when the user right-clicks "View Image" on an svg , the script will get run as a side-effect of rendering the SVG in its own tab. You can't successfully call prompt() in Chromium because the tab isn't visible by default, but the script will get run in both cases.
Just imagining an svg img with a script payload that draws the Gmail login screen over the original image. Or, more likely, Indonesian casino spam.
(Sorry, I screwed up the formatting above and didn't look at the preview.)
The script won't get run if the SVG is rendered as the src of an img tag. However...
1. In Firefox and Chromium, when the user right-clicks "View Image" on an svg rendered as an img, the script will get run as a side-effect of rendering the SVG in its own tab. You can't successfully call prompt() in Chromium because the tab isn't visible by default, but the script will get run in both cases.
I'm proud (?) to have made the chart. Slightly disappointed to be in the same stratum as trigraphs, but excited to be next to Hoare.
Scary Devil Monastery... that's a name I haven't heard in years.
I finally got through all the ones i didn't know offhand, and some of the ones i did but from different sources.
I hope there is more curated (i guess?) stuff like this? I find dan luu's stuff interesting, in the same way. There were a few other bloggers in the same vein that i lost the bookmarks to over the years.
My brain hurts from all of the "computers are actually kind of awful, if you squint just right" on that page, though.