Kaffe runs(!) under VC++

[John D. Gwinner]

Michael:

> If you have a better explanation I'll be happy to hear.

Some babbling, and a few ideas.  I think byte ordering as Greg pointed
out, as well as union packing (if there is such a term) is part of the
problem, 

> javah uses a stack_item union to pass parameters in
> the stubs it generates. The union:
>  
> typedef union {
>      jint      i;
>      jlong     l;
>      jfloat    f;
>      jdouble   d;
>      jref      p;
> }stack_item;

My only thought, is that you've got to be carefull about assuming the
layout of the union; I don't think, for example, that passing a pointer to
stack_item is the same as passing a pointer to i (the first union item).

The reason I say this is that the double is obviously bigger than the int,
for example (I think, I forget what the size of an int is in Java, but we
are talking C code here, right?)

so there are two layouts of p:

xxxxpppp
or
ppppxxxx

right?  According to the doc, the second version is what VC++ uses, but
under structures, they note:

"In Microsoft C++, class-member data is stored at successively higher
memory addresses, even though the C++ language does not require it. Basing
assumptions on this ordering can lead to nonportable code."
(for classes (structures), but they don't note either way how unions
behave)

Hmm ... I talked about packing before but missed the blindingly obvious
note that it's a union, not a structure.  However, C++ seems to think of
them in the same 'class' so packing might help.  

In any event, I think byte ordering isn't really the problem here; that
effects the layout of p itself, but not the where the wasted space goes.


> In System.c where the some of the stubs are you can
> find:
> java_lang_System_setOut0(_P_[0].p){}
> 
> This is an attempt to pass a jref (void *) as a
> parameter. The value which was passed is 0 even though
> the pointer is there !!. 
> 
> I don't have a clear explanation but I know the 
> following:
> 
> I added a local
> 
> void *vp = _P_[0].p;

Hmm .. looks good to me, actually.

Try this:
java_lang_System_setOut0((void *) _P_[0].p){}

???

VC is more ANSI compliant than earlier versions, and I find sometimes
you've got to cast things before the compiler is really happy.  VC 4 had 5
have MUCH stronger type checking than earlier versions.  

Also, I've just recently been reminded the hard way about operator
overloading and pointer dereferencing evaluation order, so I've now got a
lot of stuff like

(*POS)->SomeFunc 

in my STL using code (STL iterators), so maybe theres a problem here also.

I avoid void *'s wherever possible, frankly; although the type checking is
a pain sometimes (the char * example), I feel a lot better if the compiler
knows what I'm passing. However, I bet the void * thing is all over,
making it much harder to eliminate (and maybe impossible)

		== John ==