On Apr 14, 2011, at 5:36 AM, Andrew Haley wrote: > On 13/04/11 21:57, Patrick Rutkowski wrote: >> >> On Apr 13, 2011, at 3:26 PM, Andrew Bell wrote: >> >>> malloc() will return memory on a boundary suitable for any type. If >>> some types must be, say, 8-byte aligned, malloc will return memory >>> that is 8-byte aligned. This of course satisfies types that are >>> 4-byte, 2-byte and non-aligned. >>> >>> Your example code will end up breaking on some systems. >>> >>> This has nothing to do with specifically with GCC. >> >> Hmm, very interesting. Is it possible to determine what the memory >> alignment requirements are on a given implementation? Or at least >> with GCC in specific? It can be either a compile time or a runtime >> solution, either is good for my purposes. >> >> Or do you really have to go and manually look at the documentation >> for every system+arch you're releasing on, and manually keep track >> of alignment requirements? > > I can't quite tell what you're asking. C is designed so that you, > never have to know the alignment requirements: program in a > straightforward way and you'll be fine. Is it that you don't know > what the rules are for writing C? Or that you know the rules, but > for some special reason you want to violate them in non-portable > code? > > Andrew. Ah, yes, a well put question. As to the first part, I think that I'm now starting to understand why alignment issues exist. If I understand correctly, it's because compilers often choose to use aligned CPU op codes (though I can't say I know exactly why aligned op codes run faster in hardware). And I think I know how these alignment issues are dealt with, which would be via malloc() aligning and struct padding. Also, just a few minutes ago I read the page on the __alignof__ extension in GCC (thanks @Ian for that), and MSVC has one as well with its __alignof keyword. After some experimenting there, it seems that scalar values have __alignof__() values equivalent to their sizeof() values, presumably so contiguous arrays can work elegantly; while struct types have more complex alignment values depending on what their constituent parts are. Now, given that (presumably) I know the rules, why am I playing around with this stuff and trying to subvert the system? Well, I enjoy doing projects in C for various reasons, but I miss the polymorphic object systems in languages like C++, Java, or Objective-C. When I went about thinking on how to implement a polymorphic type system in C the first thing I looked at was how C++ lays out the memory for it's object types. What it seems to do is to take a class hierarchy like A->B->C, figure out how much contiguous space in memory is necessary to hold the data from all 3 classes, and then jams it all in there (with alignment issues taken into account). Looking at C++ set me out trying to implement a similar system, though now after this conversation it occurs to me that in C you might want to store the data for different related classes in separately malloc()'d regions, which you could then link together like a typical linked list or tree. I'm not sure which method I'll go with, but either way I'm glad to have learned about the basics of how and why alignment is done. So thanks a million for that so far. -Patrick
