The world has ended! openssl has this terrible bug which allows an attacker to receive a pot-luck of 64k portions of the memory address space of the SSL server. Thing that are up for grabs include usernames, passwords and SSL private keys; i.e. a veritable grab-bag of things that can be obtained from the server.
You should really change your password.

Actually, don’t bother; it’s not like it actually matters in the long run. You’re probably going to change your password from bunny2 to bunny3 anyway and it’s not like that was the most likely point of escape of your password in the first place. It’s probably that toolbar that installed when you installed that video player that was needed to watch that movie; you know the one? The one with the kittens? The one that you never got to see because you got distracted.

It’s been a really bad few months for security, and while people have been pointing fingers in various directions, deploying a Nelson-style ‘Ha Ha’, the only lesson that has been found in this case is that the bible has a great thing to say about this:

Do not gloat when your enemy falls; when they stumble, do not let your heart rejoice, or the Lord will see and disapprove and turn his wrath away from them.

… and then you’re in trouble.

As for me, I’m going to wait a few weeks and then change the passwords that are in any way connected to money. It would be nice if I could get some form of toolbar that would check sites as I go to them in a database and reveal if they were subject to the bug and prompt me to change the password once they’ve been declared clear. Someone get on that; it sounds like a fun project

.

In Linux, you can create a __assert_fail routine which will be triggered when an assert is encountered in code compiled with asserts enabled. Using some debugger detection, you can have the code behave differently in that situation. The code to accomplish detection at load-time looks like:

#include <assert.h>
#include <stdio.h>
#include <signal.h>
#include <stdlib.h>
#include <errno.h>
#include <sys/ptrace.h>

static int ptrace_failed;

static int
detect_ptrace(void)
{
    int status, waitrc;

    pid_t child = fork();
    if (child == -1) return -1;
    if (child == 0) {
        if (ptrace(PT_ATTACH, getppid(), 0, 0))
            exit(1);
        do {
            waitrc = waitpid(getppid(), &status, 0);
        } while (waitrc == -1 && errno == EINTR);
        ptrace(PT_DETACH, getppid(), (caddr_t)1, SIGCONT);
        exit(0);
    }
    do {
        waitrc = waitpid(child, &status, 0);
    } while (waitrc == -1 && errno == EINTR);
    return WEXITSTATUS(status);
}

__attribute__((constructor))
static void
detect_debugger(void)
{
    ptrace_failed = detect_ptrace();
}

void __assert_fail(const char * assertion, const char * file, unsigned int line, const char * function) {
    fprintf(stderr, "Assert: %s failed at %s:%d in function %s\n", assertion, file, line, function);
    if (ptrace_failed)
        raise(SIGTRAP);
    else
        abort();
}

This code, because it uses an __attribute__((constructor)) will detect a program being started under a debugger.

You could move the detect_debugger() call into the __assert_fail function, and this provides full run-time detection of the debugger and behaviour alteration. On the assumption that not a lot of asserts() get triggered, you have an effective behaviour alteration of your code when run under a debugger. In this case the __assert_fail looks like:

void __assert_fail(const char * assertion, const char * file, unsigned int line, const char * function) {
    fprintf(stderr, "Assert: %s failed at %s:%d in function %s\n", assertion, file, line, function);
    if (detect_ptrace())
        raise(SIGTRAP);
    else
        abort();
}

Sometimes you want to display a progress routine in C/C++, without resorting to termcap/curses. The simplest mechanism you can use is:

for (i = 0; i < 10000; i++){
    printf("\rIn Progress: %d", i/100);
}
printf("\n");

This yields flickering on the display as the cursor moves back and forth over the entire line reprinting it. This gets worse with larger amounts of display data. If your progress routine is simple like this, then you can use another mechanism – the backspace \b, rather than the reset \r. You take advantage of printf reporting the number of characters it displayed as a return code, and then only display the required number of backspace characters.

So for example:

printf("In Progress: ");
int lastprinted = 0;
for (i = 0; i < 10000; i++){
    while (lastprinted--) printf("\b");
    lastprinted = printf("%d", i/100);
}
printf("\n");

This way you get to only print a few characters every refresh, which minimizes the flicker.

I’d been playing around with starting up a JVM from C++ code on Windows. I was futzing around between MSVC and cygwin/mingw and it all worked well. Then I decided to do the same under Mac OS X.

Firstly, if you’re using the OS X VM, when you try to compile some simple code under clang, you’re going to see this awesome warning:

warning: 'JNI_CreateJavaVM' is deprecated [-Wdeprecated-declarations]

Apple really, really don’t want you using the JavaVM framework; in general if you want to use their framework, you have to ignore the warnings. and soldier on.

Secondly, if you want a GUI, you can’t instantiate the VM on the main thread. If you do that then your process will deadlock, and you won’t be able to see any of the GUI.

With that in mind, we hive-off the creation of the VM and main class to a separate thread. With some crufty code, we make a struct of the VM initialization arguments (this code is not clean it contains strdups and news and there’s no cleanup on free):

struct start_args {
    JavaVMInitArgs vm_args;
    const char *launch_class;

    start_args(const char **args, const char *classname) {
        vm_args.version = JNI_VERSION_1_6;
        vm_args.ignoreUnrecognized = JNI_TRUE;

        int arg_count = 0;
        const char **atarg = args;
        while (*atarg++) arg_count++;
        JavaVMOption *options = new JavaVMOption[arg_count];
        vm_args.nOptions = arg_count;
        vm_args.options = options;

        while (*args) {
            options->optionString = strdup(*args);
            options++;
            args++;
        }
        launch_class = strdup(classname);
    }
};

Next we have the thread function that launches the VM. This is a standard posix thread routine, so there’s no magic there.

void *
start_java(void *start_args)
{
    struct start_args *args = (struct start_args *)start_args;
    int res;
    JavaVM *jvm;
    JNIEnv *env;

    res = JNI_CreateJavaVM(&jvm, (void**)&env, &args->vm_args);
    if (res < 0) exit(1);
    /* load the launch class */
    jclass main_class;
    jmethodID main_method_id;
    main_class = env->FindClass(args->launch_class);
    if (main_class == NULL) {
        jvm->DestroyJavaVM();
        exit(1);
    }
    /* get main method */
    main_method_id = env->GetStaticMethodID(main_class, "main", "([Ljava/lang/String;)V");
    if (main_method_id == NULL) {
        jvm->DestroyJavaVM();
        exit(1);

    }
    /* make the initial argument */
    jobject empty_args = env->NewObjectArray(0, env->FindClass("java/lang/String"), NULL);
    /* call the method */
    env->CallStaticVoidMethod(main_class, main_method_id, empty_args);
    /* Don't forget to destroy the JVM at the end */
    jvm->DestroyJavaVM();
    return (0);
}

What this code does is Create the Java VM (short piece at the start). Then it finds and invokes the public static void main(String args[]) of the class that's passed in. At the end, it destroys that Java VM. You're supposed to do that; for memory allocation's sake.

Next we have the main routine, which creates the thread and invokes the run loop

int main(int argc, char **argv)
{
    const char *vm_arglist[] = { "-Djava.class.path=.", 0 };
    struct start_args args(vm_arglist, "launch");
    pthread_t thr;
    pthread_create(&thr, NULL, start_java, &args);
    CFRunLoopRun();
}

The trick is the CFRunLoopRun() at the end. What this does is triggers the CoreFoundation main application run-loop, which allows the application to pump messages for all the other run-loops that are created by the java UI framework.

The next thing is an example java file that creates a window.

public class launch extends JFrame {
    JLabel emptyLabel;

    public launch() {
        super("FrameDemo");
        emptyLabel = new JLabel("Hello World");

        setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        getContentPane().add(emptyLabel, BorderLayout.CENTER);
        pack();
    }

    public static void main(String args[]) {
        SwingUtilities.invokeLater(new Runnable() {
            public void run() {
                launch l = new launch();
                l.setVisible(true);
            }
        });
    }
}

Because it's got a EXIT_ON_CLOSE option, when you close the window the application will terminate.

Gluing this into a makefile involves the following; it's got conditional sections for building with either the 1.6 or 1.7 VM, and there are a couple of changes that are needed in the cpp code to get this to work:

JAVA_VERSION?=6

JHOME:=$(shell /usr/libexec/java_home -v 1.$(JAVA_VERSION))
SYSTEM:=$(shell uname -s)

CPPFLAGS += -DJAVA_VERSION=$(JAVA_VERSION)
CXXFLAGS += -g
ifeq ($(JAVA_VERSION),7)
VM_DIR=$(JHOME)/jre/lib
LDFLAGS += -L$(VM_DIR)/server -Wl,-rpath,$(VM_DIR) -Wl,-rpath,$(VM_DIR)/server
CXXFLAGS += -I$(JHOME)/include -I$(JHOME)/include/$(SYSTEM)
LDLIBS += -ljvm
else
CXXFLAGS += -framework JavaVM
endif

CXXFLAGS += -framework CoreFoundation

all: launch launch.class

launch.class: launch.java
	/usr/libexec/java_home -v 1.$(JAVA_VERSION) --exec javac launch.java

clean:
	rm -rf launch *.class *.dSYM

For the C++, you need to change the include path depending on whether you're building for the 1.6 or 1.7 VM.

#if JAVA_VERSION == 6
#include <JavaVM/jni.h>
#else
#include <jni.h>
#endif

.

You can't really use the code that was compiled against the 1.6 VM on the 1.7 environment, as it uses the JavaVM framework in 1.6, vs. the libjni.dylib on the 1.7 VM, but I would consider this a given across all JVM variants.

This source can be cloned from the Repository on BitBucket.

One of the most common idioms I see in a delphi program looks like the following:

foo := TObject.Create;
try
    // Do something with foo
finally
    FreeAndNil(foo);
end;

It’s primarily because you always create objects on the heap, and everything involving an object, essentially, is a pointer. This makes for a little bit of a memory management issue. You have to remember to destroy objects after you’ve created them, and because if something goes wrong, that destruction needs to take place in a finally block. Having it take place in a finally block keeps you safe from exceptions. If an exception is triggered it always passes through the finally block on it’s way back up the stack. This gives you the ability to cleanup temporary objects as needed

C++ uses the RAII idiom, which means that objects that are defined at a certain scope are always going to be destroyed once that scope is exited. What this means is that if you define an object X in a function Y, once Y is returned from then X will be destructed/destroyed. As an example:

std::stringstream streamer;
// do something with streamer

There’s no awkward streamer.create call, and once you return from the function streamer is appropriately tidied up

But wait, you say, they are not the same, what you are doing in Delphi is creating an object on the heap, while in C++ you are creating it on the stack, so of course during the process of unwinding said stack, you will destroy the object. The more equivalent code in C++ would have been:

std::stringstream *streamer = new std::stringstream();
// Do something with streamer
delete streamer;

Hah you say, no try finally means that if an exception is triggered in the ‘do something’ piece of code, you leak a streamer object on the heap.

To which I respond, silly rabbit, that’s why you didn’t create a pointer in the first place with the first piece of code. If you want to perform something like this, then you should use a smart pointer, which takes care of the destruction of the object once the smart pointer exits scope, like so:

std::unique_ptr&lt;std::stringstream&gt; streamer(new std::stringstream);
// Do something with streamer

But really, if you were just going to create an entity for the duration of a function, it’s far easier to just create it in-place without such complications

This leads to a little gotcha that regulary catches non C++ programmers when they are creating methods. As they typically come from a pointer-based economy (e.g. Delphi, Java), when they create a method:

function doSomething(object : TObject) : integer

What they’re doing is actually passing in a reference to TObject (as it’s just a pointer), and because it’s pass-by-value in this case, what they’re really just passing in is the value of the pointer. In C++ it’s a little bit different. When you pass in an object using the form:

int do_something(std::stringstream streamer)

What actually happens is a copy is made of the item being passed, and it’s that which ends up in the function; not the actual object that you’re passing in. If you want to pass in a reference to the object, then you need to use the reference passing semantic:

int do_something(std::stringstream &streamer)

You can use the const modifier if the method you’re invoking is not going to modify the passed in reference, which allows you to restrict the things you can do with the reference. In this form you don’t need to perform any indirection on the object (e.g. getting a pointer to it) in order to pass it in. This makes for slightly tidier code, which isn’t strewn with &’s on the way in, and var->’s in the method itself.

And for those Delphi haters out there; the reason I picked Delphi rather than Java is because Delphi is, unless you’re using the .NET variant, a non garbage collected language, and as such requires the free, otherwise you get memory leaks.

Objective C is another kettle of fish. Between the original model of retain/release, the GC model that was available on OS X from 10.5, and now the totally shiny ARC mechanism, it makes some people cry.

So I found this little security clanger in the manual page for dlopen on Mac OS X, where it states:

When path does not contain a slash character (i.e. it is just a leaf name), dlopen() searches the following until it finds a compatible Mach-O file: $LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, current working directory, $DYLD_FALLBACK_LIBRARY_PATH.

Yes, current working directory, one of the classic vulnerability injection mechanisms. This is as epically bad a security clanger as Microsoft Windows’s LoadLibrary call but, apparently, nobody cares! Linux, and Solaris have a far more sensible mechanism, where it actually enumerates the places that it looks for the library, but unless you really, horrendously eff it up, it won’t look in the current working directory.

I nearly did a spit-take when I saw this explicitly called out. In this day and age, it’s an embarassment.

I’m reading articles on new features in the CSS media queries level 4 spec. Items such as luminosity, which allow you to adjust the styling on your app depending on three grades of environmental brightness. This means you could adjust that bright white as it gets darker, so that it doesn’t blind someone who’s trying to read it in a darkened room (I had this experience this morning when the auto-brightness setting on my nexus decided that full-on-bright was what I needed while triaging my email at 6am, with the lights off).

It’s a pretty nifty feature, and once people start using it we’ll probably all reap the benefit.

The problem is that as of now, it’s pretty much only in a limited set of web browsers. Even though I have a laptop with an ambient lighting sensor, I’ll never see this work properly anytime in the near future.

The next thing I was reading was about making non-rectangular clipping areas for text so that it would flow around images. Looks pretty awesome, and makes things look more like a desktop publishing environment. Only available in Chrome Canary (which means, at the moment, the most bleeding-edge version of Chrome). Which makes it another feature that we have to wait for.

C++11 introduced some nice features such as Lambdas, which allow you to define the work to be done on something in the same place as the request to perform the work. It’s pretty nice as you can in-line work quite easily, whereas in previous languages you relied on an external function, typically with pointers to a data blob… the whole thing was quite tedious and leads to difficult to understand code. Again, you need a modern compiler that understands the C++11 syntax, but once you have it, it’s plain sailing. You ever tried to compile gcc… it’s fun times for all ;)

Again, a new feature, but it generally comes with a whole bunch of things that have to change to support it.

This is where the disappointment comes in. All these shiny features are available on the shiniest of newest systems. As developers, we like having the newest stuff – from operating systems to development environments, to programming languages. They all provide us with the ability to do our jobs better, and in a more efficient manner. It also allows us to royally screw things up much more rapidly, and then fix it so you almost don’t notice that it happened.

That’s not where most of the world lies. Most folks are living in the ‘it got installed, I’m not touching it’ world. It makes things difficult for us developers as we have to match up our work to what functions in their environment. That means we can’t use the newest version of X, because that’s not going to be present on the end-user’s system.

There is a sliver of bright light in the form of the automatic update. If you’re using Google Chrome, or any recent version of Firefox then unless you change something, it will always be silently updating to the newest version behind your back. This means that the next time you start it up, you’ve got the latest and greatest available. All the features are present. Unfortunately, this also means that the changes can trigger failures. This can be caused by a lack of testing, or a lack of backwards compatibility.

When it happens because of a lack of backwards compatibility, then people get genuinely angry – it used to work and now it simply doesn’t, and for no reason whatsoever. On Internet Explorer we have the ‘do the wrong thing’ switch, which causes the browser to act in the old, bad way, so that a user’s experience does not change when they install the newer browser.

I don’t think this is really going anywhere, so I’ll leave it as-is then.

Sorry Arun, they’re sexist pigs and I should have never introduced you because now I feel like crap for doing it.

I’ve been writing commercial software since 1996. Since then the Microsoft API for WIN32 has been extended to support the 64bit platform, but most of everything I learned while writing to that platform is just as applicable now as it was back then.

I’ve written apps for the JIRA SOAP API. They work well; as long as the soap interface doesn’t throw a wobbler. It throws a wobbler every effing day now. The SOAP API for Jira has been deprecated for the newer, shiner, REST API.

Fuck you.

Fuck you and your spurious deprecation of APIs because it’s not something that fits into your grand design.

This is not how you write an API.

Dave Winer had it right many years ago with the RSS API. It was really fucking simple, and I wrote a parser for it in ass-clown perl that worked well for everything I wanted it to do. Even when people started to put incorrect entities in their feeds I could deal with it. It still runs, and I’ve not changed it in over 7 years.

Oh no, they say, look at the major version they say, it keeps incrementing and they only have a limited obligation to support something once the major number increments.

Fuck you.

Version number increments are meaningless. When we have a Firefox 17 in January and a Firefox 23 in August, a Chrome 18 in January and a Chrome 28 in August I mean seriously, you’re making a fucking argument here? Every one of those goddamned browsers can still read HTML. They may not all *render* it the same way, but a <div> is a <div> is a fucking <div>.

One of the most stable APIs in computers is the concept of time(). Time is counted as the number of seconds since 12:00, Jan 1, 1970. Many have written alternative APIs for time, but all of them provide some call that allows you to translate that special structure into a number representing the number of seconds since that point in time. That is an API.

I’m full certain that somewhen in the 40th century, some piece of code will depend on a 64bit version of the time() call, and it will work.

You people have no fucking idea how to write an interface.

There is a reason why they call it an interface, it’s meant to be something you can program against for a reasonable amount of time.

Not like Facebook.

When I first played Leisure Suit Larry, I believe I was 13? It took some time to get the answers right so that the game could be played. Some of them were culturally difficult to get right – I mean from someone who was raised on 1 TV channel, how would we be expected to know who ‘Annette Funicello’ was? I was young and immature – this game informed me of things like condoms, which I didn’t actually know about until that time (wow! complete time-warp here). My father was a pharmacist. At the time this game was available, he did not sell condoms. There was a lawsuit pending in relation to the supply of condoms from a vending machine in, if I remember correctly, the student’s union in UCD (University College Dublin). This is the kind of country I live in.

Graphics were insanely different back then – most PCs had CGA graphics – that meant you had a choice of palettes of 4 colors. i.e. you could only pick the set of colors to use, not the actual colors themselves. Cyan hair. I remember the hair being cyan because there were no alternative colors available.

There was a VGA remake of the game. The graphics were updates, and the colors were changed; but the overall gameplay had never been altered from the original. I went back and played it. It was the same as the game of my youth. The problem was that it didn’t work for me anymore. The jokes were lame, the puns were terrible, most of the comedy was suitable for someone of a younger age than me. I never finished it because I didn’t care enough to finish it.

There was a recent kickstarter that created an ‘Leisure Suit Larry: Reloaded’. It tried to update and improve the original game. Characters were added, characters were removed; but ultimately it was trying to bring back the original game. The game has been released and the reviews have been generally negative. I’m one of those that fall onto the negative side. The reason I fall on the negative side is because the game has been lessened by the remake. It didn’t bring back the feelings from the original game (the prurience or the oooh, errr, madam bit of it), and added tat. Pointless rubbish has been added to the game to bring it ‘up to date’. The questions are actually difficult for someone of my age that doesn’t actually watch reality TV, or follow pop culture icons. Once I got past that; the game itself just didn’t feel right. The changes made the game less ‘silly fun’ and more ‘sexist crap’.

Maybe my tastes have changed (and that’s a good change), but I didn’t enjoy the remake anywhere as much as I remember enjoying the original game; which is sad.

A much more cogent analysis of the game can be Foubd on Gamasutra. It is far better at describing the poor decision to have a remake, and also to enunciate the ways it doesn’t work.

Next Page »