pogma

Due to some recent bus errors, I have been thinking a bit about alignment lately.

When the compiler lays out a struct it will generally ensure that the members of the struct are aligned on the required boundaries for the target architecture. For example, given:

struct foo {
int32_t a;
int16_t b;
};
A compiler may lay it out something like this:

The entire struct will likely be placed at an address aligned on a 4 byte boundary because the largest struct member is 4 bytes long, and the int16 type will be followed by a 2 byte pad. Why? So that an array of structs will have the ‘a’ member for all array elements aligned on a 4 byte boundary. All is good, right?

If we add a char to the struct:

struct foo {
int32_t a;
char c;
int16_t b;
};

Changing our char type to a 64 bit type may result in something like this:

struct foo {
int32_t a;
int64_t c;
int16_t b;
};

In this case (for this imaginary compiler) the entire struct is aligned on an 8 byte boundary, with the 8 byte member also aligned on an 8 byte boundary. So we can still create an array of struct foo, and things will be properly aligned. Of course, even though the individual members of the structure are 4, 8 and 2 bytes long, the entire structure with padding is 24 bytes long, so 10 bytes are “wasted”, it is best to design structs with this in mind, so that my imaginary compiler does not waste space. In the above case, changing the order of the elements is helpful:

struct foo {
int32_t a;
int16_t b;
int64_t c;
};

Now, on some systems a program will run faster if types are aligned “properly”, on others a bus error will occur for misaligned access. Misaligned access will often occur in cases like this:
char array[1024];
…
struct foo * bar = (struct foo *)array;
bar->c = 1;


In the above case, although the array certainly is large enough to hold a foo structure, there is no guarantee that a char will be aligned on an 8 byte boundary, it is a 1 byte type, so there is no need for the compiler to align it. Because of this bar->c = 1; could cause a bus error. Other  bus errors can occur casting structs of the same size, but with different alignment requirements, etc.

At least firefox works for us on HP-UX now

Shantonu noted that for gcc, using -Wcast-align will at least warn about this issue.

I was the Technical Reviewer for the book Mac for Linux Geeks, from Apress, Inc. by Tony Steidler-Dennison. It was my first time to be a Technical Reviewer, it was interesting, but not something I plan on repeating, it simply took up too much time, with not enough pay. Getting paid by the page is not a good thing.

This is not a book review, I don’t think that I would be a good reviewer, being biased, as I am. Please find reviews elsewhere - although a quick look at amazon shows none there yet, unfortunately.

[EDIT June 22nd 2009] Found a review here http://hants.lug.org.uk/cgi-bin/wiki.pl?BookReviews/MacForLinuxGeeks. It’s the only one I could find.

Well, at the end of a week in Disney we got tired of hearing “Have a magical day”, had very sore feet and legs, and were sunburned. We did have fun though, despite the heat and all the happy helpful people that we encountered.

When we lived in Japan we went to Tokyo Disney once, and to Universal Studios Japan several times. At Tokyo Disney, even though we went in the off-season on a school day, the wait times for most rides were over 60 minutes. At Universal Studios Japan (unless you purchase their “Express Pass Booklet” which allows you to go into a faster queue) we have seen wait times of 180 minutes for popular rides. We also went to Disney Paris a couple of times in January, snow and freezing rain tend to keep the visitor numbers down, so we did not have to wait at all for most rides. My expectations for Florida’s Disney world were wait times similar to Japan. I was very pleasantly surprised. The longest wait times we saw were 60 minutes, and for those rides that did have longer wait times, we got the “Fast Pass” and went back to them.

The flights were fine and we were able to get to the “All Star Music Resort” on the Disney coach fairly easily. Little did we realize that escape from Disney would be impossible for the next 7 days. This had us paying $14 for a six-pack of beer, and $2 for a bottle of water for the week. The $10 a day extra for a fridge in the room and $9.95 a day for internet access also made me feel that we were being gouged.

The food was better than I had expected. I had thought that we would be eating burgers and fries for a week, but there were delicious alternatives - the kids meals all came with a choice of 2 sides, Jessica usually chose carrot sticks to go along with her fries, and there were delicious salads available too.

Jessica loved the rides, especially the scarier, faster ones. Space Mountain 5 times, Thunder Mountain 4 times, Splash Mountain 3 times, Everest adventure 3 times, Tower of Terror 4 times, Fast Track twice and Mission: Space. Unfortunately she did not quite make the 48 inch height requirement for some of the water slides at Typhoon Lagoon.

I am glad to be back at work - now I do not have to walk miles every day in 90+ F temperatures Hopefully we can avoid theme parks for a couple of years.

I love this picture. We have to slick back her hair and put it into a bun for her ballet class. Of course, I have no experience in putting hair into a bun, so we decided to practice the other night. There were tears as I pulled at her hair, but afterwards she said “It’s ok, I have stopped crying now, and I really like my hair!”.

Hmm.

I got a commit bit for the gcc subversion repository yesterday, and exercised it for the first time today with this commit. Even though the number of patches that we have for gcc is very small, doing the commit beats heck out of begging on the mailing list for someone to commit for us

Only a little late - it has been promised to arrive in the next couple of weeks for 4 years now, Gary released libtool-2.2 today. Thanks Gary!

One of the changes that we made in libtool-1.5.26 and cvs HEAD was to change the archive_expsym_cmds on darwin. With leopard the older method of creating the output and then using nmedit to reduce the exported symbols seems to work, but the dynamic linker then sometimes fails to load the resulting object. Both this apache bug and this gnome bug are fixed by using ld’s -exported_symbols_list flag instead. I am glad the change made it into 1.5.26

Of course the reason that libtool did not use -exported_symbols_list in the first place is that Mac OS X 10.0 and 10.1 do not support it, and nmedit did the job just fine up to 10.5. Apple seems to have allowed nmedit to bitrot, it no longer does the same job that it did in 10.4. Filing a bug that you know in advance is just going to be closed with “use ld’s -exported_symbols_list flag” seems kind of pointless, but I guess I should do it anyway.