🚀 go-pugleaf

Ok, here is another bug report for pointer to data member operations.
Sorry for my bad language at the last post. Instead of f***ing up I
really wanted to use the expression fouling up. The offensiveness
of my language unfortunately escaped me.

Declaration of pointer to data members
as a function argument is not possible. Defining COMPILE
will get the thing compiled with a circumvention. However, the actual
access uses one
indirection too much of the pointer prior to the proper use,
generating a core dump.
I tried to track this down in the compiler, but got absolutely
lost in the parser syntax. Sorry for that.

Here the specs:

Reading specs from /usr/local/lib/gcc-lib/isc/2.3.1/specs
gcc version 2.3.1
 /usr/local/lib/gcc-lib/isc/2.3.1/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dunix -Di386 -D__unix__ -D__i386__ -D__unix -D__i386 test.cc /usr/tmp/cca01039.i
GNU CPP version 2.3.1 (80386, ATT syntax)
 /usr/local/lib/gcc-lib/isc/2.3.1/cc1plus /usr/tmp/cca01039.i -quiet -dumpbase test.cc -version -o test.s
GNU C++ version 2.3.1 (80386, ATT syntax) compiled by GNU C version 2.3.1.
test.cc:9: parse error before `ptr'

Here the source:

struct xxx {
	int i;
} lll;

typedef int xxx::*kah;
#ifdef COMPILE
kkk(kah ptr)
#else
kkk(int xxx::*ptr)
#endif
{
	return (&lll)->*ptr;	// code is (&lll)->*(*ptr)
	return lll.*ptr;	// code is lll.*(*ptr)
// The code will have this erroneous level of indirection even if
// you declare a variable int xxx::*ptr = &xxx::i instead of the
// function argument and use that
}

main() {
	return kkk(&xxx::i);	// Code seems correct, but is
	return kkk(0);		// indistinguishable from this line.
// ARM says, 0 must be a separate pointer to member
// Most reasonable is always giving 1 too much as offset, then
// compensating at the time of the dereference
}