Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: dave_thompson_2@comcast.net Newsgroups: comp.compilers Subject: Re: C and Java, was Compilers :) Date: Sat, 28 Jan 2023 10:37:32 -0500 Organization: A noiseless patient Spider Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <23-01-077@comp.compilers> References: <23-01-001@comp.compilers> <23-01-007@comp.compilers> <23-01-051@comp.compilers> <23-01-053@comp.compilers> <23-01-054@comp.compilers> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="12334"; mail-complaints-to="abuse@iecc.com" Keywords: C, Java Posted-Date: 29 Jan 2023 11:57:48 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:3345 On Fri, 13 Jan 2023 12:39:41 -0800 (PST), gah4 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.