Line length limit of system() in the C library

I was recently foxed by a problem with *IFTHERE where I got a syntax error back complaining about the ‘else’. Further investigation showed the command worked fine at the ShellCLI but launched from a makefile it failed. Make (amu) uses system() for its commands.

It turns out the implementation of system has a hardwired check for commands over 255 long, in which case it passes it round the side using DDEUtils.

That works fine for things that check DDEUtils, but of course most stuff doesn’t.

I’m thinking that that got missed when the Ursula long command lines were added and I should just bump the limit up to 1k (or detect at runtime based on the kernel for softloaded copies of the CLib for 3.70 and earlier).

Are there any gotchas there? If a 1k command is used and the called application does understand DDEUtils I guess it just gets the command that way the same as before, since the definition of system doesn’t mention any limits and a C program just picks things up from argc/argv.

Would a rash of buffer overruns happen for things that don’t use DDEUtils but do assume 256 byte command line (where currently system() just truncates nicely), but presumably they’d also overrun if called from ShellCLI so maybe it’d be no more prone than already?

Detecting the limit at runtime sounds good to me. As you say, any software which uses fixed buffer sizes for processing the command line is already at risk from failure if called directly via ShellCLI/OS_CLI.

I have a hazy memory that when Mike Stephens was extending the command line lengths, he considered moving the OS_CLI – DDEUtils boundary up from 256 bytes, but decided against it on the grounds of (a) not needing to insert a kernel version check, and (b) because it was dangerous to use OS_CLI too close to its limit anyway – because of aliases and variable expansions. When stuff uses DDEUtils to make calls, all the parameters get passed round the side, meaning that OS_CLI can only overflow its 1K buffer if the executable name (limited to 256 bytes by system()) expands to over 1K, which was considered relatively safe.

Not that there should be a limit at all.

Mike … decided against it

Reason (a) is pretty weak, since the ROM C library can be hardwired at the long command line length, so the check’s only needed for the softloaded one really, which already adapts for things like SWP/UMULL availability.

Reason (b) is a fair consideration, but skim reading through OSCLI looks like it checks for buffer overruns after GSTrans and similar. I guess another way of thinking about it is: if the command limit used to be 256 I could define a alias containing a macro with %0 in it which would expand to exceed 256, now it’s just 1k instead, or in general the DDEUtils threshold should be (CLI_limit – 1) and I’ve not really changed the “safeness”.