cottrell@nbs-vms.ARPA (12/21/84)
/* no, no no! the solution is obvious!!! the unused `entry' keyword is screaming to be used here! extern int foo() entry "VMS$FOO$STUPIDNAME"; should do the trick nicely. while i'm on the subject of what to use `entry' for, has anyone ever wanted struxures with negative offsets? this would alleviate excess pointer arithmetic/casting. struct blivet { char minus_two char minus_one; /* forget ; on previous line */ entry char zero; /* pointer points here */ char one; /* etc */ }; this is a stupid example. how about a better one? whoever makes the X.DOT package references buffers/frames/packets by their data pointer at the user level for convenience, and must diddle the pointers internally to get at the headers. how about a declaration like: struct thing { struct buf_hdr bufhdr; struct frm_hdr frmhdr; struct pkt_hdr pkthdr; entry char data[MAX_DATA]; }; the advantage of passing the user the data pointer should be obvious: no complicated include files to be bothered with, hiding the header from the user, etc. however the poor sytem code has to reference a field in the frame header by the unwieldy name of: ((struct frm_hdr *)(ptr-sizeof(struct pkt_hdr)-sizeof(struct frm_hdr))).field; typedefs help squeeze some chars out, but execution wise a useless addition takes place and another register may be tied up to point to the frame header. the offset can be uniquely determined at compile time and i argue that it should be done! let me simply reference my field as ptr->frmhdr.field! i know that some machines don't like to index backwards so the extra subtraxion must take place anyway and tie up a register on these brain damaged machines, but that does not stop me from referencing ptr[-1] if i so choose as a legal language construct. since this is a bizarre idea i expect and welcome flames. in fact, i'll be quite disappointed if i don't get any as this is my first submission to the network! jim cottrell P.S. (piggyback ack) hello bro! */