Re: C and Java, was Compilers :)

On Fri, 13 Jan 2023 12:39:41 -0800 (PST), gah4 <gah4@u.washington.edu>
wrote:


> On Friday, January 13, 2023 at 11:10:37 AM UTC-8, gah4 wrote:
>
> (snip)
>
> > Some time ago, I was trying to figure out if you could make a C compiler
> > that generated JVM code. I would run much closer to the C standard
> > than much C code does, especially regarding casting of pointers.
>
> > [So what did you conclude? I'd think C type casts would be hard to
> > turn into Java unless you made all of storage an opaque block. -John]
>
> Someone else might have thought about the "opaque block" method.
> But that wouldn't work if you wanted to call between Java and C.
>
> As well as I know it, C only requires assignment to work for
> pointers cast to (unsigned char *). And once they are cast,
> usually (though I suppose not always), it is done with memcpy(),
> or compared with memcmp().


Only unsigned char is 100% guaranteed, but on all known systems today
signed char has no trap rep and also works and so does plain char.


> So, all the complication of figuring out what is actually being
> done, can be done inside one of those.
>
> C pointers, then, are an object with a reference to the actual
> array, and current offset within the array, and bounds for
> the array. Pointer arithmetic only changes the offset.
>
> Scalar variables that can be pointed to, compile as arrays
> dimensioned [1].
>
> I didn't get as far as figuring out varargs functions, but someone
> must have done that, as System.out.format() works.
> You can call it with the usual different argument types,
> and it figures out everything.


Java's System.out.format -- and Java's varargs in general -- works
differently than C (at least C as practiced; the standard imposes
enough restrictions you probably _could_ implement it differently).


When Java calls a varargs method, the _caller_ silently creates an
array and fills it with the argument values, alll converted to the one
type specified in the definition (or compiled equivalent), and that
_array_ is actually passed along with the fixed args, in this case the
format string and possibly locale. For this case the one type is
java.lang.Object, which is the top-type for all class _and_ array(1)
instances in Java so they pass unchanged; any primitive value (int,
float, etc) is siliently converted to an instance of a builtin class
(java.lang.Integer, java.lang.Float, etc) by 'autoboxing'. As a result
the format method(2) just matches format specifiers to elements of
that array (remember each Java array instance knows its own length so
subscripting out of bounds traps).


Or more simply, Java varargs is sugar for a homogenous array.


(1) although you can pass an array (as one of the elements of the
silently-created array), the only format specifiers that work on an
item that is an array are %h which prints the hashcode and %s which
prints toString() which is also the hashcode, so not very useful


(2) the PrintStream (and PrintWriter) methods don't do this directly,
they delegate to java.util.Formatter, but same result.

Return to the comp.compilers page.
Search the comp.compilers archives again.