[cbrogrammer]

What do you mean? A cast to a char pointer is absolutely valid C. For most intents and purposes, a pointer "type" in C is merely the step size, and only void pointers cannot be decremented.

The line of code is basically two lines:

  (char*)hash_ptr.parm.v.p = (char*)hash_ptr.parm.v.p - 1; // move the pointer back by one byte
  *((char*)hash_ptr.parm.v.p) = fpop(sst); //At the memory location, write the output of fpop(sst)

[david2ndaccount]

It’s not the cast to the char pointer that’s a problem, it’s decrementing the casted pointer that is the problem. (char*)hash_ptr.parm.v.p is not an lvalue so you cannot assign to it.

    (char*)hash_ptr.parm.v.p = (char*)hash_ptr.parm.v.p - 1;

is not legal C, neither is

   --(char*)hash_ptr.parm.v.p

[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>

[groos]

A cast does not yield an lvalue in C (in C++ it can, if it is to a reference type). See:

http://port70.net/~nsz/c/c89/c89-draft.html#3.3.4

Footnote 36.