4 ms·

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 po

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 4y ago
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_ 4y ago
  It's probably a use of this: https://gcc.gnu.org/onlinedocs/gcc-3.2.3/gcc/Lvalues.html 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 4y ago
    No, that extension has been deprecated in 3.4 and removed in 4.0.
    - avar 4y ago
      The OP is running this on Debian Woody, which used GCC 2.95.
      - fhars 4y ago
        The OP is wondering why this does not work with a current gcc.
        deleted 4y ago
        [deleted]
        sargstuff 4y ago
        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>
        sargstuff 4y ago
        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!
        tom_ 4y ago
        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 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 https://en.cppreference.com/w/c/language/cast), meaning a cast expression is not a valid operand for the -- operator.
groos 4y ago
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 http://port70.net/~nsz/c/c89/c89-draft.html#3.3.4 Footnote 36.

david2ndaccount 4y ago

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_ 4y ago
It's probably a use of this: https://gcc.gnu.org/onlinedocs/gcc-3.2.3/gcc/Lvalues.html 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 4y ago
  No, that extension has been deprecated in 3.4 and removed in 4.0.
  - avar 4y ago
    The OP is running this on Debian Woody, which used GCC 2.95.
    - fhars 4y ago
      The OP is wondering why this does not work with a current gcc.
      - deleted 4y ago
        [deleted]
      - sargstuff 4y ago
        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>
        sargstuff 4y ago
        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!
        tom_ 4y ago
        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 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 https://en.cppreference.com/w/c/language/cast), meaning a cast expression is not a valid operand for the -- operator.

groos 4y ago

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 http://port70.net/~nsz/c/c89/c89-draft.html#3.3.4 Footnote 36.