[M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF?

[Jay]

I think it's a similar amount of code.
 
One is full of:
 
 
printf("CONST FOO := %u\n", FOO);
 
the other is:
extern const int Interface__Foo = FOO;
 
 
Both probably easily well factored with macros to like
X(int,Interface,FOO)
 
 
I don't know.
 
 
Would the generated files get commited, or regenerated in every build?
They'd need to be commited for cross builds.
  Or maybe fallback to a variable approach, with its source incompat.
They should be regenerated to make sure they are correct.
Maybe both? Regenerate them in native builds and compare for equality with the commited copy, and error if they vary?
 
 
But again, it is easier for constants.
You do need to devise a system to glean struct definitions.
 
Or to verify the correctness of ones that you have.
They don't have to be perfectly accurate. For example, you can use
arrays of bytes for padding for fields whose presence you didn't
anticipate.
 
 
It'd be good to get alignment correct.
That was sometimes wrong in the old system.
But for stuff individuall heap allocated, no matter.
 
 
It's probably not too difficult.
Something like store the size/offset of every known field of a struct.
Sort them by offset. Fill in padding when offset+size doesn't equal the next offset. In C you can pick integer types accurately enough by size and signedness, picking arbitrarily when any types are the "same". Using C++ overloading you can do better.
 
 
I put some experiments here in scripts/config, and if you look through some of the history in m3core/src/unix you can see other simpler examples.
 
 
It's a bit of a dilemna.
But I also really didn't like the way it is.
New platforms involved rewriting /usr/include, tedious, error prone, unsafe, and even mostly unused -- for all the parts I removed that people want back, there's probably a few times that much content I removed and nobody noticed.
 
 
Actually it's even a little worse than I said.
It isn't enough to get constants and structs.
There's a real larger generality of inlines and I think #pragmas.
Look at NetBSD. I think they use #pragmas to give everything an explicit and different name. stat is also notoriously complicated.
 
 
C headers seem to provide far more of a common "source interface" than a common "binary appearance" (I don't call it "interface" since for example there is endian, calling convention, processor architecture..)
 
 
 - Jay


----------------------------------------
> From: dragisha at m3w.org
> To: mika at async.caltech.edu
> Date: Wed, 20 May 2009 08:50:26 +0200
> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] ***SPAM*** Re: Probably missing too much of development sycle, but WTF?
>
> This is nice idea, but I think it means much more C code than current
> Uconstants...
>
> Actually, I like new approach. It's only it's (in)completeness that
> disturbs me :)
>
> On Tue, 2009-05-19 at 23:44 -0700, Mika Nystrom wrote:
>> These things are constant for a given binary distribution, aren't
>> they? Can they be left to some sort of bootstrapping step on the
>> target system, or at least (if cross-compiling) in an environment
>> where target C headers are available?
>>
>> I mean printing out an M3 interface based on the C header's defined
>> values.
>>
>> Mika
> --
> Dragiša Durić 
>