[comp.sys.amiga] Lattice C V5.0 #include <setjmp.h> bug

deven@pawl.rpi.edu (Deven Corzine) (03/02/89)

Just a quick note - the setjmp.h include file distributed with V5.0 of
Lattice C begins with:

#ifndef __setjmp_h
#define __setjmp_h 1

but does not have the corresponding #endif.  It's a minor bug that may
have been fixed in V5.02, but it a sort that could slip by unnoticed
for quite a long time.  I expect that if a program had 2

#include <setjmp.h>

lines in it, everything after the second #include would be ignored as
part of the #ifndef ... #endif.  Actually, it would seem to make the
most sense for Lattice to adopt the conventions of the Amiga includes
(exec/*, libraries/*, etc.) and make it

#ifndef SETJMP_H
#define SETJMP_H

.
.
.

#endif /* SETJMP_H */

IMHO.

I noticed in the exec/types.h:

-----------------------------------------------------------------------
typedef unsigned char  *STRPTR;    /* string pointer */
typedef STRPTR         *APTR;      /* absolute memory pointer */

/* sigh.  APTR was misdefined, but compatibility rules.  Heres what it
 * should have been
 */

typedef ULONG          CPTR;       /* absolute memory pointer */
-----------------------------------------------------------------------

When I first saw that declaration for APTR a while back, it baffled me
that (unsigned char **) was being declared as a generic absolute
memory pointer.  This change makes more sense, but now CPTR isn't even
a pointer; it's only an unsigned long.  Granted, under the Amiga's
architecture, a pointer is always 4 bytes, as is a long, but if it
were later changed to, say, a 64-bit address space (probably not a
too-soon occurance, but not improbable, eventually.) this declaration
would break, while the former APTR declaration, while still not quite
right, would indeed work, as it IS a memory pointer.  Anyway, my point
is, shouldn't it be:

typedef void           *APTR       /* absolute memory pointer */
    -or-
typedef char           *APTR       /* absolute memory pointer */

?  Or am I missing something?

One question - is it possible to create a compiled C module which can
be linked alone, without being linked to the lib:c.o startup module or
the lib: libraries?  (Clearly the libraries can be ditched if nothing
in them is used.  The question is whether or not you MUST use assembly
for the startup module...)

Deven
--
------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine ---------------------
Cogito  shadow@acm.rpi.edu          2346 15th Street            Pi-Rho America
ergo    userfxb6@rpitsmts.bitnet    Troy, NY 12180-2306         (518) 272-5847
sum...     In the immortal words of Socrates:  "I drank what?"     ...I think.

cmcmanis%pepper@Sun.COM (Chuck McManis) (03/03/89)

In article <DEVEN.89Mar1183038@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu writes:
>One question - is it possible to create a compiled C module which can
>be linked alone, without being linked to the lib:c.o startup module or
>the lib: libraries?  (Clearly the libraries can be ditched if nothing
>in them is used.  The question is whether or not you MUST use assembly
>for the startup module...)

Yes, with Lattice 5.0x it is possible to have nothing but 
blink myprog.o to myprog
(which sometimes you can just execute myprog.o if there are no externals
at all) 

Essentially, you will have to define your lib pointers internally and use
the prototypes for direct linkage to the libraries.


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.

scott@applix.UUCP (Scott Evernden) (03/05/89)

In article <DEVEN.89Mar1183038@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu writes:
>Just a quick note - the setjmp.h include file distributed with V5.0 of
>Lattice C begins with:
>
>#ifndef __setjmp_h
>#define __setjmp_h 1
>
>but does not have the corresponding #endif. 

There are 2 #endifs at the end of the file, but there is no
newline after the second one.  I'll bet you're using "cat"
which doesn't display the file properly.  "type" it and
you'll see both #endifs.

-scott

yo