C_Lib 32bit

One could envisage a simple star command to select the old version of scanf on the next SharedCLibrary_LibInit* call. Add that to the !Run of any offending application and hey presto.

Is this idea to be followed for every bug fix that may break programs that make assumptions based upon incorrect behaviour? Remember – not so long ago we were talking about the side effects of fixing a time bug.

There used to be such a thing as backwards compatibility.

There used to be such a thing as not depending upon behaviour either known to be incorrect or otherwise undocumented (as it’ll bite you in the end…).

Of course, given our unique situation of using old software; it may be worth making special provisions if circumstances demand it.
However there is only so far backwards compatibility works – when I moved from Win98SE to XP, I needed a bunch of device drivers for hardware. I think when my XP box gives up the ghost, I’ll no doubt run into this problem again – and it is more important given that I frequently use an analogue tuner for watching TV, and much of the hardware these days is for digital.

So… Where d’you draw the line?

One could envisage a simple star command to select the old version of scanf on the next SharedCLibrary_LibInit* call. Add that to the !Run of any offending application and hey presto.

I like the idea – fixes my problem without me having to get a swi chunk for my own personal use.

Hopefully clib is now completely bug free and we won’t have this problem again.

Why not just softload the 5.53 version and unplug the rom version?

Unplugging the ROM version could be a bad idea. I can’t remember if any ROM clients of the library are statically linked, or whether they register each time the machine boots, but unplugging the SCL could do bad things to your OS.

I think that the best solution is to remove the bug fix, create a version of the Shared C Library witout the bug fix. Then rename the shared C Library, add the bug fix and as more features are added programmes can RMEnsure a library with a different name, rather than specify just the version number.

Existing programme can then

RMEnsure SharedCLibrary 5.17 RMLoad System:Modules.clib

and new ones can

RMEnsure SharedCLib 5.60 RMLoad System:Modules.clib2

How would that work if I need the fixed version on RISC OS 4, 5 and 6 then?

Not many programmes seem to require the shared C library now – most !Run files indicate that it isn’t used.

Really? Anything in C that isn’t statically linked to UnixLib will use the SCL, and other things could too since the API is language-independent.

Presumably two C libraries can happlily co-exist, as programmes using them get a vector (I assume) so that they point to the right one.

Er, no. It doesn’t work like that. Apps which register with the SCL are given a jump table into routines contained in the module’s code space. That’s it.

While the ROM’s library is active, those jumps are into ROM. When you load your first copy of the library from disc into RAM, anything that’s registered with the ROM library up to that point is OK as the routines in ROM remain where they always were. Anything registering after that point gets pointers into the RAM copy of the SCL. Thus you can softload one copy OK.

If you softload another copy, it replaces the previous RAM copy and almost certainly moves in memory. Thus anything that has previously registered with the RAM copy now has a jump table into nowhere and things unravel quite quickly.

You could have two copies of the module with different names, but that sounds like a sledgehammer approach to the problem of some buggy software.

True but not everyone can afford or justify the expense of upgrading maintained programs and what of unmaintained programs? Most people have to be pragmatic.

…and…

There used to be such a thing as backwards compatibility.

The trouble is, this isn’t just a RISC OS library in isolation: it’s a standard C library that’s standard across platforms. Stuff ported from other platforms (which is becoming more common now as we find ways to do more with fewer people) expects the calls within it to work in a standard way.

The options seem to be to fix the SCL and fix buggy RISC OS software once, or not fix it and fix ported software every time the code it’s based on is updated.

Softloading C_Lib 5.75 loads ok — but when C Progs are run — I get the error ‘Unknown library chunk’

Just so that people are aware of all the pitfalls, note that newer libraries don’t just fix bugs: they also add new features.

The big one was C99 support; there might be others. New software is likely to expect that these facilities will be available from the default library that is loaded (and not one with a different name).