It's probably not really a compiler bug- somebody pointed out
that it was the kernel making strings readonly. But I do think it's
a bug. The actual code was really more like:
char *revname;
...
revname = "2X00";
...
revname[1] = '2'; <<<<<<<<< BOOOM
The variable revname is not a const. If I had said
const char *revname = "2X00"
...
revname[1] = '2';
that would indeed be breaking const rules.
char *foo = "XXXX";
...
foo[1] = 'Y';
blow up (in the kernel) with the 2nd assignment. Work around it here-
it's probably just as well- I was spending more in cpu instructions doing
the assignment than I was saving in string space (it would have been
cheap on a pdp11 or a 68k- but the address loads and assignments on something
like sparc or alpha way outweigh the savings in space. Tsk.).
> PCMCIAVERBOSE (commented out)
> isapnp at isa (commented out)
> midi at pcppi
> ep at isapnp (commented out)
> ix at isa (commented out)
> iy at isa (commented out)
> wdc at isapnp (commented out)
> wss at isapnp (commented out)
>
> The isapnp stuff is commented out because it may crash due to unimplemented
> alloc methods on some machines with some devices. This should really get
> fixed.
PCMCIAVERBOSE (commented out)
isapnp at isa (commented out)
midi at pcppi
ep at isapnp (commented out)
ix at isa (commented out)
iy at isa (commented out)
wdc at isapnp (commented out)
wss at isapnp (commented out)
The isapnp stuff is commented out because it may crash due to unimplemented
alloc methods on some machines with some devices. This should really get
fixed.
if it is 64k. TCL and TCM will be set properly if we just leave it alone.
Not only that, the ncr53c9x driver issues TRPAD or TRANS based on this
value. We do not want TRPAD in this case!
them.
These are identical to the current arm32 sources with the following exceptions:
- References to C labels are wrapped in _C_LABEL().
- Function returns have an alternate version inside #ifdef __APCS_26__.
ragge