[tom_]

It's probably a use of this: https://gcc.gnu.org/onlinedocs/gcc-3.2.3/gcc/Lvalues.html - not clear that recent gcc versions support it. Frankly, this one line of code suggests to me that anybody looking to get started on their C career with this program is going to have a harder time than necessary ;) - though, who knows.

(If I were doing this, I'd probably change the p field to a char *. That's probably what it wants to be anyway. Then see what comes of that.)

[fhars]

No, that extension has been deprecated in 3.4 and removed in 4.0.

[avar]

The OP is running this on Debian Woody, which used GCC 2.95.

[fhars]

The OP is wondering why this does not work with a current gcc.

[sargstuff]

char --> signed 8 bits, no less/no more than 8 bits used.

(*char) --> compiler will detect how to align char address for given hardware.

aka, 32bit machine,there are 4 places that a byte can evenly fit in 32 bit address/pointer.

May not be a gcc issue.

Directly manipulating a memory address (aka the numeric location where value is stored) usually prohibited by OS (or not allowed by hardware used) for security reasons.

May also be reason why works under Debian <X> and not Debian <Y>

[tom_]

It is a gcc issue, in that this code is written using a non-standard gcc-specific dialect of C.

In standard C, -- operates on what in C terms is known as a modifiable lvalue, a value that may be used on the left hand side of an assignment expression (https://en.cppreference.com/w/c/language/value_category). And a cast returns a value that is specifically not an lvalue of any kind (https://en.cppreference.com/w/c/language/cast), meaning a cast expression is not a valid operand for the -- operator.

[sargstuff]

The 'fun' part about minimal addressable memory sizes (assuming hardward supports) is this :

if addresses are 64bits, and only 48 bits are used for addressing, there are 16 bits available for other use!