> Both. "Ready to use" meaned that the code worked

Yes, I understand your manager's expectations. If it worked,
it must be "ready to use". Despite what managers believe, it's
often not true of course... It's hard to convince them that the
code really is spaghetti, it doesn't just seem like because you
can't understand it. I usually try to put my foot down by
describing the resultant cost of the defects in the product,
in addition to the extra development time. It's often cheaper
to fix the infrastructure first, even though it seems non-
productive and managers view it as "creeping elegance" :-).
 
> > So get a copy of scpp and remove all the AVR
ifdefs. 
> I did it already, manually. Took time, though.

It does - and it's error-prone. It's easy to remove the wrong
bit of code, and break the thing you're trying to understand.
That's why scpp is good.

> Sorry about my erraneous copying. What was there,
was "*ri_count = 0".

Ok, no problem, that explains it.

> I have studied and written C code. Just that I
could not find any
> reference (from the books I have) on what does a declaration like
> char *pointerA;
> in global variables exactly do? Where the pointer points to? How much
> room is in the memory area pointed? I think that is not very
> self-explaining as code.

All global variables which are not explicitly initialised are set
to zero (which is NULL for a pointer, and ASCII NUL for characters).
Unfortunately, zero is also a device address, so it can cause problems.

Some compilers on machines with valid zero addresses have used
a non-zero bit pattern for a NULL pointer. The lexical symbol "0"
used in a pointer context then produces a *nonzero* bit pattern.
This can trip up folk who freely cast pointers to integers and
back again (embedded folk are terrible for doing this), but it's
still preferable to having valid memory at (void*)0.

Clifford Heath.

"Clifford Heath" <cjh@m...> wrote:
> Yes, I understand your manager's
expectations. If it worked,
> it must be "ready to use". Despite what managers believe,
it's
> often not true of course... It's hard to convince them that the
> code really is spaghetti, it doesn't just seem like because you
> can't understand it. I usually try to put my foot down by
> describing the resultant cost of the defects in the product,
> in addition to the extra development time. It's often cheaper
> to fix the infrastructure first, even though it seems non-
> productive and managers view it as "creeping elegance" :-).

Once upon a time I was a university student looking for a summer job
in a laboratory. They asked me to debug and extend a piece of code
(running on a normal pc) controlling an electron beam litography
system. The code was undocumented C++ (well, one comment), 100-page in
print and written by a foreign summer employee a year ago.

I told them that if somebody is that dumb that he accepts the job, he
is not able to do it. I turned down the job offer and suggested that
they hire somebody to write the code from scratch, with comments this
time. For myself I went to another lab, to do a similar job on a
well-documented, 10-year-old, Turbo Pascal code.

I'll terminate my (propably) annoying ranting about coding projects
here. :)

> It does - and it's error-prone. It's
easy to remove the wrong
> bit of code, and break the thing you're trying to understand.
> That's why scpp is good.

Must use it next time. Thanks for the hint.

-- 
Iiro Jantunen