variable

Jeff, my comments are not necessarily directed to you specifically. You just drew them out of me.

Reordering quotations...

"No doubt, it would be sweeter to write the whole thing in C, but depending on your desperation factor, you might stoop to my level."

Well Jeff, I would contend that your level is just fine.

"There are two obvious problems with this solution.
* First, you MUST include an assembly language file in the build. Most of us would like to avoid that because it is non-portable."

Maybe most of you would like to avoid assembly language because you don't know/like/whatever assembly language, but what is the "portable" way to do it? Certainly using an enhancement to a non-portable C language extension does not suddenly make it portable. If anything, the way you are doing it would be more familiar to those who have solved the same problem on other platforms, since it is the "conventional" way of going about it.

"* Second, it's a maintenance nightmare. If the data struct is very complicated, it is SO easy to get off by one byte. Then it could take forever to get back on track."

[rant]
If a configuration data structure is complex enough to be even remotely considered a maintenance nightmare, you should be using other tools to generate it anyway. Folks should take their blinders off and expand their software tools use beyond just the assembler, compiler, linker. Software tools that were created by software developers for software developers, have been around a long time. In these cases of complex configuration data structures (especially if they change from time to time), consider expressing the configuration in form easy and familiar to the configurer, and use Perl, awk, etc. to programmatically generate an assembly source file from the configuration file as one step in your build process.
[/rant]

Sigh. I'm going to go off and reread Jon Bentley's "Programming Pearls" and "More Programming Pearls" for my mental health ;-)

Jeff, my comments are not necessarily directed to you specifically. You just drew them out of me.

Reordering quotations...

"No doubt, it would be sweeter to write the whole thing in C, but depending on your desperation factor, you might stoop to my level."

Well Jeff, I would contend that your level is just fine.

"There are two obvious problems with this solution.
* First, you MUST include an assembly language file in the build. Most of us would like to avoid that because it is non-portable."

Maybe most of you would like to avoid assembly language because you don't know/like/whatever assembly language, but what is the "portable" way to do it? Certainly using an enhancement to a non-portable C language extension does not suddenly make it portable. If anything, the way you are doing it would be more familiar to those who have solved the same problem on other platforms, since it is the "conventional" way of going about it.

"* Second, it's a maintenance nightmare. If the data struct is very complicated, it is SO easy to get off by one byte. Then it could take forever to get back on track."

[rant]
If a configuration data structure is complex enough to be even remotely considered a maintenance nightmare, you should be using other tools to generate it anyway. Folks should take their blinders off and expand their software tools use beyond just the assembler, compiler, linker. Software tools that were created by software developers for software developers, have been around a long time. In these cases of complex configuration data structures (especially if they change from time to time), consider expressing the configuration in form easy and familiar to the configurer, and use Perl, awk, etc. to programmatically generate an assembly source file from the configuration file as one step in your build process.
[/rant]

Sigh. I'm going to go off and reread Jon Bentley's "Programming Pearls" and "More Programming Pearls" for my mental health ;-)

Sorry, I just have to share this because it is so relevant.

Just to illustrate the "maintenance nightmare" issue using an example, and this is literally an issue I was asked to help with today coincidentally...

A client of mine who will remain nameless, is a "device" manufacturer. Their high-end parts are big and complex, having embedded CPU(s) and BGA packages with pin (ball) counts as high as 1704. The databook for this device is around 2000 pages. The databook contains pinout tables for 256, 456, 672, 676, 896, 1148, 1152, 1517, 1696, and 1704 pins (some pins missing in an otherwise regular "row" by "column" pin array). Some poor documentation fellow has to take the "source" package/pinout text documents output early in the IC design and packaging engineering process and verify BY HAND/EYEBALL that the PDF databook pinout tables match. For the big packages, these tables are upwards of 48 pages! Well guess what? A pin got dropped somewhere along the way in the databook creation process and a customer caught it. Oops. There you go. Now that's and error-prone maintenance nightmare! The documentation fellow has a remarkable attention to detail and ability to focus, but he's only human after all. He also gets to recheck all the other tables to verify that nothing has changed if there's an edit performed to another table.

So what we do is use those marvelous text processing software tools my forefathers created for me, write a surprisingly simple script (program) to parse out the pins from the the engineering source document and the PDF (or from old PDF and new PDF), process one against the other looking for inconsistencies, and BAM! that poor fellow's hair starts growing back in.

The moral of the story is that there is usually a way to make a complex problem simpler using the right tools. Since you are not likely to be the first one to encounter your complex problem or something very similar to it, there's a good chance that a tool exists to help you.