The problem with StubsG

LOL Rick – exactly – when I read that description of strncpy back in the 90s, my immediate response was to write [for HTMLEdit] html_strncpy(). It’s crude, but does exactly what you say – ensures the resultant strings are null terminated.

Or stick it in a general library…

However, strncpy() isn’t completely pointless. Copying text into or out of a non-indirected icon block is one use-case: copying in, you don’t want a terminator if the string is 12 characters long – it must be left un-terminated, else you blat something that you didn’t want to. Reading out, where the terminator goes for a 12-character string will depend very much on how big the target buffer is (and yes, several CashBook users recently pointed out more politely than necessary that I’d also screwed this up for indirected icons).

I’ve left this thread alone for a while, but at some point I have to make the updated NewsHound binary available.

It’s been an interesting discussion, but I’m not certain of the conclusion.

Andrew (the only person still advocating StubsG), referring to StubsG, said:

The new version is somewhat larger than the old version, as it adds C99-compliant printf and derivatives, so that coupled with C18 are pracical reasons to still prefer Stubs32

Taking that at face value, that means I should not link with StubsG. Right?

I’ve been left with the impression that no-one who needs the updated NewsHound will be adversely affected by it. (If they aren’t updating their Shared C library, I doubt they’ll be updating their apps either.)

As for the sprintf family, I did notice that there were lots of instances of the non-safe versions in NH’s source, and if I were to do any further maintenance of NH, I’d want to replace them with safe versions.

Depends how you look at it.

Those who don’t like StubsG cite C99 compatibility and GCC compatibility as reasons not to use it. These are fixed in the current version. C18 compatibility isn’t, but that won’t affect Newshoud.

The logical thing would be to use the newer build, which with Charles’ permission, you can be furnished with, but in all honesty, the old version would be fine for Newshound.

Or, you could just do a build for me with StubsG for me, and release the 32bit Stubs generally, deciding you’re not fussed about anyone who might still be running a 26bit Clib.

All I’ll say is that as a commercial software vendor, I would like a StubsG version please, because my software needs to work on all currently available versions of the OS (inc VRPC), and happens to include Newshound.

Hope that’s fair. If you don’t wish to do it yourself, I’d be quite happy if you were to send me some object files to link together, I could do it myself.

Just to be crystal clear, I don’t see any reason not to use StubsG myself now that I have the updated version, but then I didn’t before. Now I can benefit from snprintf() too :)
I was trying to be charitable in the line you quoted. Those reasons wouldn’t be enough for me not to use it (the size difference is 16 KB or less, I think).

The reality is that most people here aren’t fussed about people outside of the OS5 space (who aren’t willing to jump on board and update). That’s absolutely fine, but there are enough old users still out there that I can’t ignore them. I think that is why I’m the only one standing up for it. No-one else feels a need to use it because they can justifiably wash their hands of anyone not using 32bit Clibs etc. For me, however, I would look at it differently and say “if my application could run on any of these clibs, why am I forcing anyone to do anything?”. It’s kind of like putting RMensure UtilityModule 5.00 in a !Run file for something that could work on 3.50 otherwise.

Andrew: I think a general release using Stubs, and a private version for you using StubsG, may be the best way forward.

It’s my understanding from this thread that an up-to-date version of the Shared C Library will work for everyone, right back to RISC OS 3.11; is that correct? The incompatibilities that showed up over the years (2 of them) have been corrected.

But if someone won’t upgrade, then you have a version in your back pocket to give out.

The other proviso is that future versions of NewsHound may actually require an up-to-date Shared C Library, StubsG not being an option.

What I’m still struggling to understand is what good StubsG does for software which uses C99 functions when it comes up against a version of the C library which doesn’t support those functions. The Acorn C/C++ manual states that the library which comes in RISC OS 4.29 or earlier does not support C99, so what happens when our hypothetical StubsG-linked application is run on RISC OS 4.02? Does it magically work? Or does it refuse to run? Or does it run, but then break in various undefined and interesting ways when C99 functions are called?

Or does the developer need to work out for themselves what version of SCL to RMEnsure?

A list of Progs that don’t work with the RO5
SharedCLib on a 26bit system would be Handy.

[Edit]
On a 26bit system – it would be useful to have the 32bit BASIC & 32bit SharedCLib in the Windows side – so it’s ready to use on RO startup.

Also being able to have a choice of RO on startup with VRPC – like Red Squirrel.

Would be nice if a High Vector RO could be made to run with the Emulators :-)

Steve F – you’re over-thinking/complicating things. StubsG includes versions of those functions for older machines, so snprintf() and other C99 stuff works on said library (hence the size differential). So yes, in your words, it “magically works”.

Steve F – you’re over-thinking/complicating things.

It might help if any of this was documented, or even publicly available…

StubsG includes versions of those functions for older machines, so snprintf() and other C99 stuff works on said library.

Presumably it will use the functions in the Shared C Library if they’re available, and only use its own versions if the SCL is too old?

I’m still slightly puzzled as to why we have an upgradable shared library, but so as to avoid users upgrading it we require software developers to statically link functions which it provides into each application “just in case”. What is the actual issue with upgrading the SCL on end-users’ machines? We’re not asking them to change OS, or go 32-bit, or anything like that — we’re just asking them to merge a new module into !Boot, exactly as they would for internet modules, or any other central resource. A module which will still work with their old applications, no less, and a module which will almost certainly be required by some other applications which they will want to use anyway.

Are we really still stoking the old “us v them” politics of the noughties nearly two decades on?

One final question. Back when StubsG came out, various people (ISTR Druck being one) seemed strongly opposed on technical grounds. C wasn’t really my thing back then (I’d written an early version of Launcher in native GCC, IIRC, but little else of value, and didn’t even have the DDE), and Google isn’t finding anything useful (it’s swamped by the politics), so would someone be willing to humour me by:

1. Outlining what those technical objections were, and
2. Explaining why they no longer apply in 2021, or why this new version of StubsG (which we don’t yet have access to) will overcome them.

If we can do that, and if someone provides a version of StubsG which is guaranteed to work on GCC 4.7.4 and all later versions (in the GCCSDK environment), then I’ll offer to ponder the situation again and see if I come to a different conclusion when armed with any new facts which might emerge.

or even publicly available…

Indeed. Had he not asked, nobody would have known a more recent version even existed.

Presumably it will use the functions in the Shared C Library if they’re available, and only use its own versions if the SCL is too old?

No source, and, of course, there isn’t a copy of this version floating around to look to see what it actually does.

What is the actual issue with upgrading the SCL on end-users’ machines?

Bloody mindedness, really.

It isn’t as if a newer CLib isn’t available.
It isn’t as if a newer CLib will taint their machine.
It isn’t as if a newer CLib is particularly hard to install.

And as has been said numerous times already, wanting to use just one single non-StubsG application would require an updated CLib to be installed, which pretty much makes StubsG’s raison-d’être evaporate.

So, I’d be interested in knowing whether this is a real problem or a mostly imaginary one. Who is it out there that is so unwilling to perform any update maintenance on their system that one of the major software producers feels the need to use a hack to allow “any old CLib” to work.

Furthermore, I would say in this day and age, not encouraging users to upgrade their CLib is actively doing them a disservice. As we all know, a softloaded CLib really doesn’t tolerate being reloaded. But, everybody blindly RMEnsures/RMLoads CLib if it is too old. They shouldn’t, but they do.

Just looked at software here… Director (5.17), DiscKnight (5.17), Hearsay (??? – tests 5.17 for the RMLoad, and then tests 5.34 to ensure it worked!), NetSurf (does the same sort of thing, tests 5.17 and then 5.43), OpenVector (5.17 then 5.34), PhotoDesk (5.34), Samba (5.17/5.34), BeebIt (5.17/5.34), Avalanche (5.17/5.53), Verma (0.00/3.75 (is linked with StubsG)).

Congratulations to Fireworkz for doing it nicely. ;-)

Of my own stuff, EBook checks for 5.17 in Stubs, nothing in !Run as I think we can assume there will be some sort of CLib in use.
Harinezumi checks for 5.17 in Stubs. Doesn’t have an !Run.
KanaTutor checks for 5.74/5.74. I’ll need to fix that.
Koi-Koi checks for 5.40/5.40. That’ll need to be fixed too.
Manga checks for 5.44, but does not attempt to RMLoad as of v0.54.

nearly two decades on?

It isn’t as if anybody actually needs to update CLib much. While there are various bugfixes and updates, the big releases appear to be:

• First 26/32 bit version – 5.17 (2000/10/03)
• First 26/32 bit version that is recommended (earlier versions have numerous important 32 bit bugs) – 5.27 (2001/02/22)
• First version with full C99 support – 5.52 (2005/03/07)
• First ROOL version with a correctly working scanf() – 5.76 (2013/03/20).
• First version to not use SWP[B] if [LD|ST]REX[B] exist (ARMv8 support) – 5.88 (2016/02/13).

The minimum probably ought to be 5.44 if not using C99, or 5.52 if using C99.

So, while it would be useful to the end user to include a recent build, what we are asking is “at least a sixteen year old version”.

Things like CLib and BASIC ought to be considered core updateable parts of the OS and made really easy to update (run this, then reboot) in preference to finding technical means of allowing people to avoid updating anything.

CLib and BASIC ought to be … made really easy to update

Could not agree more.
And hopefully when Toolbox re-unification is complete they could be included.

BASIC is really easy to update. If you have a pre-RISC OS 5 machine you just download System Resources from the Miscellaneous downloads page and follow the instructions in the ReadMe to merge it, then add a one-line Obey file to Choices:Boot.PreDesk containing the following line:

RMEnsure BASIC 1.73 RMLoad System:Modules.BASIC

Job done.

BASIC is really easy to update. If you have a pre-RISC OS 5 machine you just download System Resources…

And if the machine isn’t internet connected?

If no internet connection, then updates could be done by Floppy, USB or any connection to another machine. And if there is none of those they will not be installing or updating any software, so what they have will keep on working.

nd if the machine isn’t internet connected?

As Martin points out – you use a floppy.
Specifically, as an “old school” machine user you update anything that needs updating using “old school” methods, however I feel we should point out that said methods were close to leading edge when those machines came out, so you’re just continuing with the retro feel.

Is there anyway of downloading ImpStyle from !Store from a Android phone?

Windows/Vrpc tends to slurp the data allowance when not looking.

Iyonix doesn’t have wifi.

I don’t think RISC OS has been ported to an Adroid phone yet.

Is there anyway of downloading ImpStyle from !Store from a Android phone?

Not directly, but, since you also mention an Iyonix, you might be able to use it via the phone’s WiFi access point. Clearly you would need to have a wifi-ethernet dongle. I’ve used that principle at user group meetings to access the internet.

Clearly you would need to have a wifi-ethernet dongle. I’ve used that principle at user group meetings to access the internet.

Here, I use a Vonets VAP11G. The ethernet output of the Vonets is plugged into a cheap Netgear FS205 five port switch, to share the WiFi connection between the Pi, the PC, and the Beagle. It also operates in bridge mode to allow my tablet and my ESP32 net radio to hook into a strong signal rather than trying to pick up WiFi from the Livebox in the other room (on the other side of a thick stone wall).

It’s a really useful thing to have.

Originally, it plugged directly into the Pi, but the addition of the switch means it “just magically works” with the other machines too. :-)

Give us an updated, bug-fixed SharedCLibrary without any of the C99 or newer stuff and without 32-bit support and we will be able to be rid of the hacks like StubsG.

How on earth does a clearly broken-by-design version of CLib offer any advantages to anybody?

Plus – if you aren’t using C99 then it’s quite clear that you aren’t using functions such as snprintf(). Didn’t you comment just the other day about buffer overruns? These functions help prevent such things. They should be used.

Especially important for those that wish to save every byte

You might have had an argument with RISC OS 3.10 on an A5000 (one of the main arguments against the take-up of the Toolbox was how much memory it consumed on the older machines), but the baseline now is a RiscPC which can be expanded to a useful amount of memory. Thus, the benefits of what the library offers far outweigh the extra bytes taken.

Yes bug-fixes are needed, so provide them to all, not just those that are able to use the newer versions.

It’s open source. If you really want a broken CLib for RISC OS 3.10 and earlier, go ahead. But since pretty much nobody actively targets said hardware any more, please don’t expect our limited developer resources to be taken up by supporting obsolete hardware.

I just looked in my copy of the C Programming Language to be sure that I had that correct, they are in the ANSI version of the standard from 1989,

Try again. strncpy, yes, that’s been around since about 1979.
Now look for snprintf and vsnprintf.

http://www.dii.uchile.cl/~daespino/files/Iso_C_1999_definition.pdf

There are still users that attempt to save memory on there Archimedes RISC OS 3.1x machines with 512K or 1MB of RAM.

One could argue that they won’t need an updated CLib because they probably won’t be using any updated software.
Trust me, I’ve done DTP on a 1MB machine (an A3000), and internet on a 4MB one (an A5000). Both were functional but painful. In either case, switching to a Pi would be a hell of a lot better than persisting with such limitations. It isn’t as if there aren’t choices and options these days.

ive us an updated, bug-fixed SharedCLibrary without any of the C99 or newer stuff and without 32-bit support and we will be able to be rid of the hacks like StubsG.

I think you have misunderstood the use-case that Andrew has for StubsG. For him, it is important to preserve all bugs and make no changes to the SharedCLib that runs on the customer’s machine, because that is what apparently works (or seems to). Every bugfix is a change that might break old software that expects that bug or happens to rely on that bug.

Still though the usage case I mention is ongoing valid, as there are still low end Archimedes users that need to be accounted for. The extra RAM usage by the module could have adverse effects on some of there other software. So we still need the bug-fixed SharedCLib without the C99 or newer stuff, and without the 32-support to provide for those users.

No idea if “we” (whoever that is) should cater for the approximately two or three users who might be interested in updated software on outdated hardware (emulated “classic” machines can have 16 MiB of RAM easily, so a few kBytes extra should not have them worried) from 30 or more years ago.

But I wonder why you arbitrarily chose that cut-off point “no C99”. Why would updated software NOT want C99 capabilities? As soon as you have two of them running on your A310, you already save memory if you have the C99 functionality in the shared library instead of putting it into the executable. And if you really want to save memory, surely you don’t want any updated CLib at all, since the ROM one will suit you fine? Unless you are on RISC OS 2 of course.

Once we get the planned ROM update “RISC OS 3.20” via “Arcflash” with much of the goodness of modern RISC OS running from ROM and therefore wasting no space (IP stack, Toolbox modules, nested WIMP…), surely for the “modern software on classic machine” use case (if it exists), you’d just include the C99 functionality?

that might break old software that expects that bug or happens to rely on that bug.

Are we still going on about scanf? ;-)

I had thought that everyone stuck to the C standard

Which? There’s K&R, there’s original ANSI C. There’s C89, there’s C99, C11, C18…

To me, that’s the problem. The language evolves. The library evolves to follow suit (maybe a few years later…). And then? People need to update their libraries. No if/but/maybe about it.

So we still need the bug-fixed SharedCLib without the C99 or newer stuff, and without the 32-support to provide for those users.

As I said, CLib is open. Feel free to poke, fiddle, and bake your own version.

Did you not see the statement we need the Bug Fixed SharedCLib without the newer stuff to save memory for some users.

Leaving out the newer stuff will render the library useless for software that uses those features, plus any attempt at using modern version numbering will completely muck up RMEnsure testing for a suitable module version.
In short, making a modern CLib with bits of functionality missing is broken by design. There’s no other way to look at it.

They are listed in the standard for C89.

Please point me to this, because the link I gave you, if you bothered looking at it, was the ISO/IEC 9899:1999 (E) which I would consider to be pretty definitive.
In the foreword it says: This second edition cancels and replaces the first edition […snip various standard IDs…]. Major changes from the previous edition include:

And in the following list, it says: — the vscanf family of functions in <stdio.h> and <wchar.h> and — the snprintf family of functions in <stdio.h>.

There’s no mention of snprintf in C89 → http://port70.net/~nsz/c/c89/c89-draft.html

So the absence from the library has nothing to do with C99, these are C89/ANSI C functions.

The actual standards say otherwise.

still run whatever software they normally use there Archimedes to run, guess what.

I can guess – it’s easy. Don’t upgrade. Use what you know works. Just don’t expect much support from anybody for outdated outmoded hardware with far too many restrictions to be particularly useful for today’s sorts of activities.

and have no reason to upgrade that.

“I have no reason to upgrade my memory” and “wah, I can’t afford 4K because I don’t have enugh spare memory”. You understand you’re talking about an invisible pink unicorn, right?

Oh, do pay attention.

You said:

the rest of the n versions of the string functions are there, even though you say they are not.

While earlier I said:

Try again. strncpy, yes, that’s been around since about 1979.

You might be thinking that I said:

is anyone still writing code that uses the “non-n” versions of sprintf(), strcpy() and so on?

Firstly, that wasn’t me.
Secondly, that wasn’t making any claims regarding what is or isn’t part of C99.

Yes, we all (that is, all of us who write stuff in C) know that functions like strncpy have been around for ages…because we’ve been using them for ages.

It has been wrongly repeated that these are C99 and newer in this thread, they are not.

Please indicate which message indicates that strncpy is only available in C99 or later. I’ve just searched all three pages of this for that string, and none of the matches imply such a thing.

AS PART OF ANSI C

Out here in the rest of the world, it is ISO C. ;-)

and turn to Appendix B, section B3, on pages 249 and 250.

Remember a while back when I suggested that before you post a long almost-rant, you should ask yourself “am I sure about this?”.
Well, are you?
Because that’s an awful lot of effort to refute something that nobody said.