Bug in PDF

[jnferguson]

SORRY FOR THE SPAM; I keep noting stuff and when you make text super dense people dont read it

Just so you know, in the section about the MSVC sealed modifier you show a class being derived from another class that does not have a virtual destructor; which if you're unaware of can cause some oddities during destruction.

Also, the keyword 'final' is now part of the C++ standard and has the precise effect as sealed. Also, this
causes static binding as opposed to the dynamic binding with a vtable. Meaning you could also could avoid the vtable by simply not marking any methods in the class as being virtual.

Finally, a person could make a relatively sane argument that due to features like libvtv and other related vtable verification implementations that the vtable creates some amount of extra security. The crux of the argument is that one has no vftable verification and makes available a wide range of places to return into whereas the other checks that youre supposed to be calling to that particular call site.

[jnferguson]

On the 'runtime awareness' slide, it is stated that .bss and .data are both zero initialized, however the .data segment is for global variables/initialized static values that are initialized with a value at compile time, whereas . .bbs will be initialized at run-time with zeros.

[jnferguson]

In thee slide pertaining to double free's; yes if the allocator hands the pointer back out you can potentially race to the double free and create a use-after-free. That said, I believe the major rationale for the history of exploiting double frees more or less abuses the unlink() macro.

Last time I checked, glibc had code paths through fastbins that will allow you to put a block of memory on the free list twice; jemalloc and tcmalloc also exhibit this functionality.

[jnferguson]

As a general rule of thumb, I always try to initialize local variables when declared because it largely eliminates unitialized memory bugs. That said, I just spent an hour or two looking through my things for an old bug example that you might want to include; basically it was akin to this:

BSTR str;
[...]
return str ? str : "";
[...]

I cannot recall off-hand what the examples return value was, at any rate, something long those lines will generate a temporary object to coalesce the types in the ternary operator-- which would be constructed and then destructed returning a dangling pointer.

Any ways, neat stuff, keep up the good work.

[struct]

Thanks for the feedback @jnferguson - I will revisit some of these when I get time and make some adjustments.