$ in identifiers

[cottrell at nbs-vms.ARPA]

/*
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!
*/