Why is an lvalue required as left operand of assignment in this for-loop?

Question

This isn't my code; I'm working on getting a very old internet chat/file sharing client and server compiled for Linux - and while the server compiles fine, I'm running into errors compiling the client.

fh_lookup (const char *path)
{
        struct hl_filelist_hdr *fh;
        char const *p, *ent;
        char *dirpath;
        int len, flen, blen = 0;
        u_int16_t fnlen;
        struct cached_filelist *cfl;

        ent = path;
        len = strlen(path);
        for (p = path + len - 1; p >= path; p--) {
                if (*p == dir_char) {
                        ent = p+1;
                        while (p > path && *p == dir_char)
                                p--;
                        blen = (p+1) - path;
                        break;
                }
        }

        dirpath = xmalloc(blen + 1);
        memcpy(dirpath, path, blen);
        dirpath[blen] = 0;

        for (cfl = cfl_list->next; cfl; cfl = cfl->next)
                if (!strcmp(cfl->path, dirpath))
                        break;
        xfree(dirpath);
       if (!cfl)
                return 0;

        for (fh = cfl->fh; (u_int32_t)((char *)fh - (char *)cfl->fh) <
cfl->fhlen; 
            (char *)fh += flen + SIZEOF_HL_DATA_HDR) {
                L16NTOH(flen, &fh->len);
                L16NTOH(fnlen, &fh->fnlen);
                if (!memcmp(fh->fname, ent, fnlen))
                        return fh;
        }


        return fh;
}

When compiling, I get the error:

error: lvalue required as left operand of assignment
             (char *)fh += flen + SIZEOF_HL_DATA_HDR) {

But I'm not entirely sure why. This error appears in for-loops throughout other files as well; So it might be old C styling, perhaps? I think the original code was written in 2003. I'm not sure. But any help to fix this would be greatly appreciated.

Answer 1

An assignment expression must have a place to store the value being assigned. So the left operand must designate such a place. This is called an lvalue—an lvalue is an expression that designates an object, such as an int, a double, another basic type, a structure, and certain other things.

The most common lvalue is simply an identifier—the name of an object. For example, after int x; defines an object (the memory reserved for x) and an identifier (the name x), x designates the object.

Constants such as 37 or 'a' are just values in C. They do not designate anything in memory. Most expressions produce simple values, not lvalues. For example, the result of 3 * x is three times the value of x (if there is no overflow), and it is just a value, not an lvalue, even though it used x. Another example is that, the result of the cast (char *) p is just the value of a pointer; it is not an lvalue for p.

Other lvalues include:

• The results of applying unary * to pointers. If p is a pointer with a valid value pointing to some object, then *p is an lvalue for the object, so you can write *p = 37;, assuming the object type is compatible with being assigned 37.

• Members of structures. If s is a structure with a member foo, then s.foo is an lvalue for that member. This applies to pointers to structures as well; if p points to s, then p->foo is an lvalue for the member foo. (Note that s must itself be an lvalue. It is possible to have a temporary structure that is just a value. In that case, a reference to its member is just a value, not an lvalue.)

In the assignment (char *)fh += flen + SIZEOF_HL_DATA_HDR, (char *)fh is not defined to be an lvalue by the C standard. If this code was accepted by some C compiler, that compiler was provided some unusual extension to the C language.

It appears the intent of this statement is to add flen + SIZEOF_HL_DATA_HDR bytes to the location pointed to by fh. If so, this can be accomplished by converting fh to char *, adding the desired amount, converting back to the type of fh, and then assigning the result to fh:

fh = (struct hl_filelist_hdr *) ((char *) fh + flen + SIZEOF_HL_DATA_HDR)

(There are certain hazards in doing this sort of raw pointer arithmetic. This answer does not speak to those; we assume the underlying code deals with those and is designed for implementation that support what it is doing.)

Answer 2

Well, the expression (char *)fh is not an lvalue for your compiler. The row is not correct:

(char *)fh += flen + SIZEOF_HL_DATA_HDR

I clould correct it by this way:

fh = (struct hl_filelist_hdr *)((char *)fh + flen + SIZEOF_HL_DATA_HDR))

We have following syntax for assignment operator in C:

lvalue = rvalue;

An lvalue (locator value) represents an object that occupies some identifiable location in memory or (rarely) memory itself. I will mention some examples of lvalue in modern C:

#define X a int a, b[2], *c, **d; const int e = -1;

• a variable (e.g: a = 0;)
• a structure (e.g: structa = structb;)
• a member of array (e.g: b[0] = 3;)
• a pointer to variable, structure, array or member of array (e.g: *c = 4;)
• a pointer to reference (e.g: *&c = &a;)
• a pointer to another pointer (e.g: **d = 5;)
• a group operator around lvalue (e.g: (a) = 6;)
• macros substituting lvalue (e.g: X = 7;)
• a constant lvalue is an lvalue without permission of assignment (e.g: an expression e = 8; is wrong)

Lvalue is typically not:

• a number (e.g: 9 = a;)
• any math expression (e.g: a + 10 = 11;)

In your case, the conversion operator will not return lvalue for assignment.

Answer 3

Since I spent some time on cleaning up, I'll post my reworked code here. IMHO the code is older than 2003, it uses alloca-constructs, and "struct hack". Probably the magic voodoo code was copied from other networked game programs, and never reworked.It could originate from the nineties.

---

        /* GUESSED structure definitions */
struct hl_filelist_hdr {
        u_int16_t len;          //<< Total length, rounded up modulo 32bit (EXLUDING header??) ; in network byte order.
        u_int16_t fnlen;        //<< string length, presumably, including NUL-byte, rounded up modulo 32bit; in network byte order.
        char fname[1];          //<< "STRUCT HACK" construct???
        };


struct cached_filelist {
        struct cached_filelist  *next;
        unsigned fhlen;
        char *path;
        struct hl_filelist_hdr *fh;
        };

        /* appears to be global */
struct cached_filelist *cfl_list=NULL;

struct hl_filelist_hdr *fh_lookup (const char *path)
{
        struct hl_filelist_hdr *fh;
        struct cached_filelist *cfl;
        unsigned len, namelen, dlen = 0;
        unsigned nstart;

        len = strlen(path);
        if(!len) return NULL; // an empty path would not make sense

                // find final (back)slash
        nstart = 0;
        for (dlen=len ; dlen-- >0; ) {
                if (path[dlen] != dir_char) continue;
                // filename starts after the final slash
                nstart = dlen+1;
                // if the slash was doubled, dont include it in the dirpath.
                while (dlen  > 0 && path[dlen-1] == dir_char) {dlen--;}
                break;
        }
        namelen = len - nstart;
        if(!namelen) return NULL; // an empty name would not make sense

        for (cfl = cfl_list->next; cfl; cfl = cfl->next) {
                if (!memcmp(cfl->path, path, dlen) && !cfl->path[dlen]) break;
                }

                // Directory is not in cache: nothing we could do
       if (!cfl) return NULL;

        /** we dont need this anymore
        dirpath = xmalloc(dlen + 1);
        memcpy(dirpath, path, dlen);
        dirpath[dlen] = 0;
        **/

                /* Without the MACRO definitions, this cannot be
                ** rewritten.
                ** It looks like a "struct-hack" kind of thing, but aligned on 32bit boundaries
                */
        for (   fh = cfl->fh;
                (u_int32_t)((char *)fh - (char *)cfl->fh) < cfl->fhlen; // <<--
                (char *)fh += flen + SIZEOF_HL_DATA_HDR //<<--
                ) {
                u_int16_t fnlen;`               //<<
                L16NTOH(flen, &fh->len);        //<<-- len appears to be a rounded-up length of the variable-size struct-array element, in bytes.
                L16NTOH(fnlen, &fh->fnlen);     //<<--
                if (!memcmp(fh->fname, path+nstart, fnlen)) // fnlen appears to include the NUL-byte
                        return fh; // Found it!
        }

        return NULL; // not cached
        // return fh; <-- would point beyond the allocated size. Is this intended?
}

Answer 4

Here: https://stackoverflow.com/a/5367481/7332147 you can perhaps find a better solution than declaring fh as a char*.

That answer says that

(int *)p++;

is rejected, but

(*(int**)&p)++;

is not.

In a comment under this question: Casting a pointer does not produce an lvalue. Why? there is written:

I don't see why you'd have any need to cast an lvalue. In an assignment, you can cast the rvalue being assigned.

This is another reasonable solution, I think, as reported in the 5th comment under your question.

Anyway, both the links above can make you better understand what the problem is; at first sight, for me your cast should work, and I believe I also use similar things - but I normally use non-standard compilers and normally I don't need portability.