What caused me some trouble though is some bug in either the documentation or that example code: It assumes there is an alpha channel, even though the only pixbuf type the library knows (according to docs) is GDK_COLORSPACE_RGB which does not have an alpha channel (at least not in my version 2.18). Accordingly the code, when painting the pixel at x,y, would also overwrite the red channel of pixel ((x+1) mod width), (y+x/width) with the passed value for the alpha channel.
Mysteriously the example code ASSERTs n_channel == 4, whereas a GdkPixbuf created with the parameter GDK_COLORSPACE_RGB has n_channel == 3 (causing the assertion to fail). This in fact seems to indicate that, instead of introducing a new type GDK_COLORSPACE_RGBA, the GDK maintainers just changed the operation mode of GDK_COLORSPACE_RGB, which - if true - I'd call a really stupid decision.
Whatever really happened, maybe some enlightened one can fix the docs or the example code, there is nothing worse than erroneous documentation.
I think gdk-pixbuf doesn't separate RGB and RGBA colorspaces. RGB is "3-channel RGB" and RGBA is "4-channel RGB" (this has been so from the start). Also, if you look at the docs for gdk_pixbuf_new(), you'll see that alpha channel creation is specified by additional parameter and is not part of colorspace definition. Example code explicitly states that is meant to be used on 4-channel RGB images (that is, RGBA), so nothing is wrong there. But I agree that things are a bit awkward when it comes to naming.