[snips]
The full code is avaliable at:
http://www.brlivre.org/c/468.c
Actually, it's not. However, a little poking around found it. Allow me
to start by saying this code is *bad*, in every conceivable meaning of the
term.
A quick compile complains about bzero, and so it should - what the heck is
bzero? It's not defined anywhere in the code. Apparently - from a little
searching - it's just a memset, which leads to the obvious question, why
not use the standard memset? Also, in decode, the variable k is unused,
according to the compiler. That it still exists despite being unused
suggests either you forgot to write some code, or you're using one of the
other variables incorrectly - assigning to j when you should be assigning
to k, say. There are other possibilities, of course, but the unused
variable warning is quite sufficient to render the entire piece of code
questionable.
Okay, fine, it compiles. Let's run it. Hmm. No prompt, no nothing. So
I give it some input to see what happens - I type "woof". It spews out a
"cannot allocate memory" message and quits. Well, if it didn't want
"woof" as an input, why didn't it ask for what it did want?
So I read the code. It wants something called "cases". I'll give it
three and see what happens.
More waiting for unknown things to happen. Attempting to read through
your readinput function proves... futile, really. It's bad, evil, nasty.
It doesn't "read input", it loops, it jumps, it calculates, it glues, it
appends, it does all sorts of weird and wonderful things. A line such as
if (!(j + 1) % 2 && j < (c * 2) - 1) has absolutely no business in a
"readinput" function, the purpose of which is - from the name, at least -
to simply _read_ the input, possibly with validation. Not to process it,
store it, redirect it, do database lookups from it, or stuff it, quite
possibly incorrectly. into buffers it probably shouldn't be touching other
than to store one piece of finally-accepted data into.
However... we'll send some text at it, since it seems to want three pieces
of data. I give it "This is a test." and it promptly spews "Wrong input
format". Really? So why didn't it tell me what format it wanted? Let's
try again.
Give it a "3", give it "woof" and... it pukes. All in all, a most
unfriendly application, so let's ignore that and focus on the code.
While wading through it, I see some odd things. For example, I see chcode
= *foo - 97; the purpose of which isn't entirely clear. Oops... it looks
like this is intended to produce a character value, presumably on the
notion that, say, 'a'-97 == 0 or some such. Except that this notion can't
cope with different cases, for one thing, and isn't portable, as there's
no guarantees about the order of characters or what their numeric values
are.
A little further on, we see hchcount = 0. hchcount? What, exactly, is an
hch, and why are you counting them? No indication is given. Nor is there
any indication of what an sch is and why you're counting those.
On we go to decode(). Here's the function header:
void decode(int *hf, int *sf, char *s, char *hch, char *sch, int f)
Yeesh. That's no fewer than 5 separate things you're planning on
modifying. You're going to modify hf and sf and s and hch and sch. I've
met *very* few functions which actually do so much work that they require
*five* separate outputs. Indeed, I'd tend to suggest that such a function
needs a complete redesign.
For example, a decompression function might return three things - the
decompressed data, the size of the decompressed data, and a result code.
You're returning five things, but you're using completely non-descriptive
names for the parameters, so one has to simply guess what the function
actually means.
Moving on to main... there are 9 separate variables declared in main.
That's actually a _lot_ of variables for a single function, and this is
compounded by using some of the worst variable names imaginable; there is
absolutely nothing about "schars" which indicates what it really is, and
the comment isn't clear, either - what is a "diff character"? While
we're at it, what's with this: scanf("%d", &cases); ? Not even an
attempt to validate the input.
Between lack of comments, bad variable names, overly-busy functions,
non-standard functions, functions which do things other than what they
claim to do, non-portable assumptions, lack of prompts for inputs and the
use of what I'd regard as being at _best_ a truly bizarre handling of user
inputs, the best thing that could happen to this code would be to print it
out, gather around a campfire with a few wiccan priestesses, burn it while
chanting ritual cleansing mantras, then bury the ashes for all time.