🚀 go-pugleaf

Ken (shiva@well.com) wrote:
: [g21k is DOS-based Gnu C 2.3.3 targeted for Analog Devices SHARC 21000
: architecture.]

: I'm compiling in a DOS window under OS/2, specifically Warp 4 with
: fixpak 8. After a few modules compile, the whole system crashes to a
: register screen. It's not related to a specific source module, as
: following a reboot, the Make will resume, go for a few more modules, and
: crash again. Anyone seen this? It's most likely IBM's fault, but I don't
: have a good idea on how to narrow it down for a bug report or
: workaround. I suppose I'll have to start doing my compiles under NT and
: hope it works a little better.

You might try changing the version of make you are using; there are
several around.  I've done quite a bit with Mix C in a DOS box under
OS/2, and had no problems.

: Also, I've inherited an idiom that looks like this:

: [in header]
: #define LOCAL_LINKAGE
: #define near
: #define local_proc static near LOCAL_LINKAGE

: [in .c file]
: int local_proc foo (int arg) { ... }

: g21k warns about "static" not being at the beginning of the declaration.
: Does standard C not allow "static" (a property of the function, not the
: return type) to be sytacticly adjacent to the function name?

Gimpel lint gives:

int local_proc foo(int arg) { return 0; }
.\test.c(74:15) : Warning 618: Storage class specified after a type
.\test.c(74:40) : Info 715: arg (line 74) not referenced

That is, the storage class specifier was found after the type was
specified, which is legal but deprecated.  Hence the warning.

: I've also seen warnings about an array index being of type char. Why
: should it care?

Because it's unusual to index an array with a character; mostly arrays
are larger than 127 elements, a common maximum for the char type.  OTOH,
you are dealing with a DSP processor and chars could well be 32 bits.

: Is there a way to silence these warnings?

Not really, no; I'd be inclined to run a lint (eg: LCLint, which is
freely available) on the code, and fix whatever warnings come up.


Will
cwr@crash.cts.com