Re: C90 penetration

kerravon wrote:
On Mar 26, 10:52 pm, Tristan Miller <psychon...@xxxxxxxxxxxxxxxxx>
wrote:
I doubt that there's a GCC cross-compiler for the 6502, though there is a
Free cross-compiler specifically written for that processor; namely, cc65.

Thanks for the pointer!

http://www.cc65.org/

It describes itself as "almost ISO C compatible", though that might be a
bit generous: among the ISO/ANSI C features it does not support include
the float and double datatypes,

Would it be legal for a C90 compiler to define both of
these as a long, and just specify that the "precision"
is such that it "rounds" at 1?

That's inconsistent with (among many other things) the maximum values for FLT_EPSILON and DBL_EPSILON specified in 5.2.4.2.2p11.

....
The other thing is bitfields. I wonder if those can
be legally represented at chars.

Any platform which allows implementation of the bitwise operators will also allow implementation of bit-fields.
A bit-field whose size is CHAR_BIT, can certainly be represented by a char; bit fields of a larger size clearly cannot be represented as a single char. Bit fields of a smaller size must behave as if they only had the specified number of bits: for instance, storing a -1 in an unsigned bit-field with a width of 3 has to produce a result of 7, not UCHAR_MAX. This would require bit-wise manipulation just as complicated as that required to implement bit-field that only take up the specified number of bits, so there doesn't seem much point to it.

Also, the standard requires that if a bit field with a width of (for instance) 3 is followed by a bit field with a width of 4, then if there's enough room in the allocation unit (which is guaranteed to be the case for those two numbers), they must be allocated in adjacent bits within that allocation unit; that's pretty hard to do if you implement them as chars.

Though it's primarily intended for cross-compiling to
1980s microcomputers and game consoles, the author claims that the runtime
library and standard C library are sufficiently portable that they should
work with any 6502 system (presumably including modern-day embedded
systems).

Except for the file I/O of course. Which is the biggest thing.

A conforming implementation of C can have file I/O that always fails: nothing is the standard requires that any I/O function call must succeed. Of course, the simplest approach is to conform only to the requirements for a freestanding implementation, in which case the <stdio.h> portion of the standard library need not be implemented at all.
.

Relevant Pages

  • Re: AfxMessageBox?
    ... this new option "treat chars as wide" would be the same situation. ... The standard does not specify if the chars are signed or ... YCHAR is the opposite of XCHAR, at least I think that's how it ...
    (microsoft.public.vc.mfc)
  • Re: Buffer overflows and asctime()
    ... struct tm members to be within their valid ranges is up to an user of ... There is no valid range for the year as specified in the standard. ... I wouldn't call it a defect, because the existence of a limit beyond which asctime() cannot be safely used is inferable from the description of asctime. ... I would consider it a substantial improvement for the standard to explicitly specify the limit. ...
    (comp.std.c)
  • Re: RfD: c-addr/len
    ... Then I wonder why you are asking us to get rid of CHARS ... encodings and MIME, when common practice is using MIME. ... Thus what we see for now, you design standard, you make another series ...
    (comp.lang.forth)
  • Re: What Is Wrong With Newswatcher?
    ... chars that demands the client to hard wrap the lines either ... don't recall brackets being a standard in the rfc to enclose wrapped ...    A multi-line data block is used in certain commands and responses. ...
    (comp.sys.mac.advocacy)
  • Re: [fitsbits] Comments on image distortion conventions
    ... The document should specify default values for any coefficients that are absent from the header, but might be expected based upon the value of A_ORDER or B_ORDER. ... Presumably either the values would be taken to be zero or the convention should require that all keywords be present. ... The convention would appear to mis-use the CTYPEi reserved keyword in a way that at least technically violates the FITS standard. ... of including distortion in the pixel world coordinate transformation directly. ...
    (sci.astro.fits)