6 ms·

I don’t blame you for having a hard time, as that snippet you’re showing is not legal C (you can’t assign to a cast). --(char*)x is not legal C. Old compilers w

I don’t blame you for having a hard time, as that snippet you’re showing is not legal C (you can’t assign to a cast). --(char*)x is not legal C. Old compilers were more permissive though. unfortunately, you are going to have to both become a proficient C programmer and then figure out what the intent of that code was and rewrite it to legal constructs.

cbrogrammer 5y ago
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 5y 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_ 5y 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 5y ago
      No, that extension has been deprecated in 3.4 and removed in 4.0.
      - avar 5y ago
        The OP is running this on Debian Woody, which used GCC 2.95.
        fhars 5y ago
        The OP is wondering why this does not work with a current gcc.
        deleted 5y ago
        [deleted]
        sargstuff 5y 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 5y 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_ 5y 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 5y 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.

cbrogrammer 5y ago

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 5y 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_ 5y 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 5y ago
    No, that extension has been deprecated in 3.4 and removed in 4.0.
    - avar 5y ago
      The OP is running this on Debian Woody, which used GCC 2.95.
      - fhars 5y ago
        The OP is wondering why this does not work with a current gcc.
        deleted 5y ago
        [deleted]
        sargstuff 5y 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 5y 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_ 5y 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 5y 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.