This is a common mirror - Donnelly 012017 - electrochromic, very nice, used on a variety of cars. For google search results, this is likely found on Buick Regal and Century models from 1997 ('97) to 2004 ('04). Possibly on others - Park Avenue, maybe some Chrysler models, who knows.

So there are two types of mirror mounts - the ones that clip on, and the ones that have a screw. Dismounting the kind with a screw is trivial. Dismounting the kind with a clip is annoying, mostly because of the incredibly vague instructions: "The rearview mirror is removed from the support by prying with a small flat-bladed tool." The shop manual is similarly vague: use a small flat-bladed tool to remove the mirror. Awesome. Useful! No, just kidding, not useful.

So here's what you're looking at. There's an oval-shaped mount attached to the mirror; the mount is clipped onto the rearview mirror support. The support is nice and metal, which is important because of how we need to remove it. At the bottom of the mount, next to the glass, there's a nice opening. Grab yourself a sturdy flat-bladed screwdriver - preferably 4mm, so on the large side of precision screwdriver. Stick it in the opening, all the way until it doesn't go farther, and pry down, and up. You should see the entire mirror move a bit. You're prying against metal, not your windshield. Keep prying until the entire mount pops off. You don't need to pull the mirror, just pry until it pops. It feels a bit like things are going to break, but it's the only way to do it. Once it pops, you're done! There're some more details after the jump, if you care.

On Mac OS X, and on Ubuntu, and probably on others:

I admit, my first years of programming, I was coddled by fairly standard definitions for variable sizes. A byte was a byte, a short was two, an int was four, a long was eight; a float was four, a double was eight. But then I bumped into the wonderful, terrible thing that is compiler-, platform-, and architecture-dependent variable sizes. An int of 16 bits, a long of 32, a double that was the same as a float, long longs being needed to specify 64, blah blah blah. This only progressed as I started working on yet-unreleased processor architectures (such as AVX512), tiny microcontrollers (ints being 16 bits, and occasionally no support for anything bigger), and as I started looking into implementation specifics (intermediate values held as 80-bit floats).

Thankfully, we have to save the day. The link has more, and features our lovely int8_t, uint32_t, and so on. Until I learned about this, I satisfied myself with declaring my own typedefs to do this; it's much nicer when someone else does it for you.

They also do things I hadn't before, like defining int_leastX_t - for example, an int_least32_t will be at least 32 bits though it may be more. Then there's int_fastX_t, which is like leastX in that it specifies the minimum width, but it also chooses a type that should be fastest to operate on/with for that minimum width. And then there's intptr_t and uintptr_t, which is an integer capable of holding the signed/unsigned version of a pointer (defined by casting the Xptr_t to void *, then back to Xptr_t, and being equal on comparison.)

To follow up on my previous post, here are some more cool things I learned about sizeof and classes in C++. I've been doing a lot of fun stuff with serializing and de-serializing classes with c-style casts to and from byte pointers, because it works fantastically well and very quickly and lends itself well to storage. Of course there are safer ways to do it, but that's the beauty of the things I'm doing - overhead is cut out whenever possible. So, fun learnings. A small overview first, and the rest after the jump.

Let's use well-recognizable types, defined in . (See my previous article about sizes.) Let's assume we're on a 32-bit system and pointers are 32 bits in size.

What do we get from ? It's fairly simple, by inspection, to count the bytes: 1 + 2 + 4 + 4 (because we assumed 32-bit system, 32-bit pointers) = 11 B. But now let's check out the more interesting cases after the jump.

From bash.org, and meant to be run by bash, coincidentally enough:

If you haven't seen Dredd yet, watch it on Netflix or Amazon Prime. It's excellent.

Today is the "Day of Dredd," where everyone involved (except the people with moneybags) are trying to get a sequel made. The movie did poorly in theaters - probably due to terrible advertising - then very quickly became a cult classic.