Re: C and Java, was Compilers :)

On Sunday, January 29, 2023 at 8:57:52 AM UTC-8, dave_th...@comcast.net wrote:
> On Fri, 13 Jan 2023 12:39:41 -0800 (PST), gah4 <ga...@u.washington.edu>


(I wrote)
> > > 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.


But if the standard says (unsigned char *), and it failed with other types,
would it still be C?


In any case, I would put all the complications into memcpy() and memcmp().


Assignments cast to (unsigned char *) could call memcpy().
Otherwise, they would be assumed to work.


(snip)


> > 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).


But also, Java didn't always do that automatically.


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


I suppose, but it is a lot of sugar!
Having to do the array creating, and all the conversions to fill
the array is a lot of work! And a lot of cases to get wrong.


Some years ago, I was doing Practice it!, which requests you,
in many cases, to write a Java program. The system then compiles
and runs your program, and verifies the output. It mostly makes no
requirement on how you write it. At some point, I started
using System.out.format() for my output statements.


If you want to try it: https://practiceit.cs.washington.edu/


Anyway, yes, that is what I thought Java did with them.
Though some of my programs use arrays dimensioned [1]
instead of the usual wrapper classes.

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