Beginner questions (C/OSLib)

Hi all,

I’ve finally moved my Pi, updated my SD card (firmware, ROM image and HD4) and got the DDE installed. After a bit of fun with installing OSLib, I have managed to get a simple Hello World command-line program running – complete with the new-trendy shared makefiles. I’m happy with all that.

I knocked up a quick program to open a USB endpoint and read some bytes. This sort-of works (the issues I have with it can wait!). It uses only the pure ANSI C functions provided in stdio.h. I wanted to investigate OSLib, so decided to change my ‘fopen’ to ‘osfind’ and ‘fread’ to ‘osgbpb’. Similar result (as you’d expect) but with one critical difference: if the OSLib version of the code crashes, or I abort it with ESCAPE, then I cannot re-run it without re-booting (I get ‘endpoint in use’ when my code tries to do the osfind again).

I must have overlooked a difference! Do I need some sort of ‘cleanup’ section in my code? Is there something I can detect from the osfind failure and re-try cleanly? (I assume this is what open does behind the scenes, but I don’t know)

Apologies for the beginner-ish nature of this. I have barely touched RISC OS for about 15 years (and even back then, I only used GCC or the DDE once or twice). I actually write software professionally, so the concepts are not an issue – it’s just the unfamiliarness of the specific environment.

Cheers,
Richard.

On most operating systems, when an process terminates the kernel will make sure that all the resources the process was using (memory, file handles, sockets, etc.) get cleaned up correctly. RISC OS has very poor process management – a lot of the housekeeping when your process exits (or crashes) has to be done manually.

For applications, the C library will take care of closing open FILE *s when your app terminates, and the malloc heap will be located in the application slot, so the system will take care of that automatically (i.e. the Wimp will get rid of it, or if you’re single-tasking the next app to run will inherit it).

If you’re bypassing the C library’s file management and making direct OS calls then you’ll have to make sure you close the files manually whenever your app exits. There are a couple of ways you can go about things:

1. Install an exit handler via atexit and have it close the open files (or clean up any other resources). I think this will correctly catch both normal and abnormal app termination with CLib.
2. If you’re using UnixLib with GCC then I think you may have to use signal handlers to perform some of the cleanup (I ran into issues with this when working on arcem – http://arcem.cvs.sourceforge.net/viewvc/arcem/arcem/riscos-single/sound.c?revision=1.3&view=markup#l121)
3. There should be two versions of most OSLib calls, ‘os’ and ‘xos’. The ‘xos’ version will call the ‘X’ form of the SWI, so that if the SWI generates an error the error will be returned to your code so that you can process it. If a non-X form of a SWI is used and it generates an error then the current error environment handler will be invoked, which will generally terminate the app. So basically if you want to handle errors in code then make sure you’re using a call which uses the X form of the SWI.

Also, if you start writing modules:

1. The malloc heap will be the RMA, and the C lib won’t free the memory automatically when you exit. You have to do it manually.
2. Calling non-X SWIs is generally forbidden. Unless the module runs as an application, it won’t install any environment handlers, so a non-X SWI which generates an error will call the error handler that’s associated with the app that called the module. (Also in respect to OSLib, the non-X calls won’t work at all in modules, since they don’t preserve R14_svc before calling the SWI)
3. I’m not sure offhand if the C lib will close open FILEs when the module terminates (I’d assume it will)

I’m not sure offhand if the C lib will close open FILEs when the module terminates (I’d assume it will)

I believe files open with fopen() will be closed, but ones opened using RISC OS’s native calls (OS_Find) will not be closed.

The C library is your friend here. If you bypass it, prepare for extra work as Jeffrey outlines!

The C library is your friend here.

Hmm, pass a stale file handle to CLib and watch the machine hang. ;-)

Defensive programming is also your friend ;-) e.g. file_dispose(FILE “**”) that zeroes the FILE “*” on close…, alloc_dispose(void “**”) (albeit annoying with Norcroft) etc. Trivial wrappers that save buckets loads of heartache.

Ah… Thanks chaps.

I thought I had a good idea at lunchtime… Look at the CLib source code and see how fopen is implemented. Funnily enough, just the same SWI calls as I am making. So I was still scratching my head!

I think Jeffrey’s bit about the CLib runtime doing some cleanup must be where the solution lies. I will have a flick through the PRMs and see if I can find examples.

I shall no doubt be back with more silly questions!

Thanks everyone.

I have had another fiddle. OSLib stuff now working as I would expect – Jeffrey was right on the money, I needed an atexit handler.

What is the consensus for such C programs? Do we hit the various SWIs (directly or via OSLib) or do people prefer using the ANSI libraries? Most example RISC OS code I see is all about the former.

I thought I would play around with a simple command line program, then progress to a module. Should I revise that, as it seems there are greater differences at play in RISC OS?

Also, my program uses printf for debugging. What is the proper way to achieve this on RISC OS? Is there a framework I should be using?

Now I am going to do some reading on USB input, as it doesn’t sound straightforward!

What is the consensus for such C programs? Do we hit the various SWIs (directly or via OSLib) or do people prefer using the ANSI libraries? Most example RISC OS code I see is all about the former.

Depends on use case. ANSI works OK for streaming of files (i.e. reading/writing bits at a time). But if you want to read/write a file in one go then using OS_File directly is generally quicker and easier (in terms of programming effort and runtime performance). And if you care about filetypes (e.g. when writing) or have special requirements (e.g. the ANSI functions may attempt to perform their own buffering, which could cause problems with “device as a file” things like USB) then using OS SWIs is generally the only way.

I thought I would play around with a simple command line program, then progress to a module. Should I revise that, as it seems there are greater differences at play in RISC OS?

Normally starting with a command line app is fine, but since USB is a bit tricky to use effectively you may encounter some issues with doing USB in an app which wouldn’t be present if you were doing it in a module.

To make life more RISC OS friendly while dealing with unix binaries from Obey files, I have decided to make a command similar to or better still, using Do (from the BootCommands module)
There is reference to main.h that I cant find in the GCC oslib but there is no conventional main() anyway (must be something to do with building a module)
I have added some includes that will be needed, and I guess stdarg.h and a few others will be needed for the new main routine. (Yet to be added along with unixifying routine)

#include oslib/tracef.h
#include oslib/os/h
static os_error *main_error_lookup (int errnum, char *token, ...)
static os_error *Do (const char *tail)
{  os_error *error = NULL;
   bits psr;
   tracef ("Do\n");
   if ((error = xos_gs_trans (tail, buffer, sizeof buffer, NULL,
         &psr)) != NULL)
      goto finish;
   if ((psr & _C) != NONE)
   {  error = main_error_lookup (error_BUFF_OVERFLOW, "BufOFlo");
      goto finish;
   }
   if ((error = xos_cli (buffer)) != NULL)
      goto finish;
finish:
   return error;

len%=LEN sv$
pos%=1
char$=LEFT$(sv$,1)
IF char$="<" THEN ERROR ELSE out$=char$
REPEAT
pos%+=1
char$=MID$(sv$,pos%,1)
out$+=char$
UNTIL char$="$"
REM eg ADFS::4.$ has been reached - now start unixifying
REPEAT
pos%+=1
char$=MID$(sv$,pos%,1)
CASE char$ OF
WHEN "." :out$+="/"
WHEN "/" :out$+="."
WHEN "hardspace" :out$+="?"
OTHERWISE out$+=char$
ENDCASE
UNTIL pos%=len%

It’s easy enough to do from BASIC if that is what you would prefer.

If you look in the CVS download I recently announced theres a basic program in sources called convert_files which has a procedure PROCget_args which returns a string array – argv$() – and the number of arguments – argc%. Note you can put an argument in inverted commas if there is spaces in it, the inverted commas are stripped. argv$(0) is the path used to run the program, like <obey$dir>, the other entries in argv$() are the command line arguments

You then just need to canonise any paths – not gstrans, I think its os fscontrol something or other.

Thinking further about it do you actually need a conversion

Does

Set MYPROGHOME /<obey$dir>.^/home

work for you. It works for me with cvs which I set up like this

unset cvs$*

set alias$cvs wimpslot -min 8m|M<obey$dir>.cvs %%*0

set UnixEnv$cvs$sfix ""

set alias$mycvs cvs -d :local:/<obey$dir>.^/CVSRepository %%*0

set alias$roolcvs cvs -z9 -d :pserver:anonymous:@riscosopen.org:/home/rool/cvsroot %%*0

set cvs$editor <obey$dir>.editor

set cvs$tmpdir /tmp/cvs

The advantage being that when the unix prog appends various
filenames for logs pids etc, It is then all in unix form and doesn’t break.
Unixlib /could/ handle a pure RISC OS path otherwise.

Unixlib can handle pure RISC OS paths if it’s configured correctly.

• Programs can directly control the default filename translation rules by setting __riscosify_control to the right value (see <unixlib/local.h> – http://www.riscos.info/websvn/filedetails.php?repname=gccsdk&path=%2Ftrunk%2Fgcc4%2Frecipe%2Ffiles%2Fgcc%2Flibunixlib%2Finclude%2Funixlib%2Flocal.h)
• Programs can also manually invoke the __riscosify and __unixify functions to convert filenames between different forms (same header as above)
• Users have partial control over the behaviour of programs by setting the UnixEnv$ProgramName$sfix system variable (where ProgramName is the name of whatever the program is). This variable controls which unix filetype suffixes should be mapped to RISC OS directory prefixes and vice-versa (e.g. for GCC it will say that c, h, etc. files should appear in folders with those names)

Of course if you’re dealing with unix vs. RISC OS filenames on the command line, user interfaces, etc. then some extra logic in the program (or a utility like unixdo) might be necessary to make sure that the filename is in the right format before the core of the program starts to manipulate it.

Hi Jeffrey,Colin,
What I know is that converting the path as per the sample is reliable with /all/ unixlib binary cases, and having unixdo allows you to behave in the Obey file in the normal RISC OS fashion, and with no hard coded paths.
You have to admit it would be simple compared with the alternatives, especially when not getting something right.
As an aside, I altered unixlib to recognise pipe: and now I can use bsdcat tosend and receive from pipe:file in the command line.
I’m not sure why this hasn’t been enabled in the past, or perhaps it has and the binary I tried at the time was at fault.
But Thomas Milius RISC OS utility concatenate is very useful for files, it works with Dir variables, and doesn’t add in OD like the standard RISC OS methods for redirection/concatenation.
concatenate <outfile> <infile1> <infile2> ...is the same as
bsdcat infile1 infile2 >> outfile
It doesn’t do stdin etc, but saves several lines of work/time.

Edit: pretty busy with house and summer is ending, but Colin,

Set FETCHMAILHOME  /<Fetchmail$Dir>

Do <Fetchmail$Dir>.unixdir <Fetchmail$Dir> FETCHMAILHOME

Thanks Jeffrey, for the comments on SWI vs. ANSI. Makes sense to me.

I just need to experiment with some logging (DADebug looks interesting) and get my head around USB input. I have read a few threads on here, as there seems to be a lack of official documentation, and it seems ‘unsettled’ to say the least!

And as you say, I should look into modules, as my techniques may need to change.

Any pointers on any of that, particularly USB, would be welcome.

Jeffrey you mentioned the sfixing etc

(e.g. for GCC it will say that c, h, etc. files should appear in folders with those names)

<Ram::RamDisc0.$.src.>

Ram::RamDisc0.$/src/