Parallel sockets or?

Joshua Judson Rosen rozzin at geekspace.com
Thu Oct 8 15:33:23 EDT 2009


"Shawn O'Shea" <shawn at eth0.net> writes:

>     The originators of psock were at cesnet.cz, there is a link to
>     the library at http://www.cesnet.cz/project/qosip
>    
>     The make doesn't finish.  Several compile errors.  I played
>     about a bit, but did not make much headway...
> 
> I was curious and downloaded this. I'm working on CentOS 5.3 (32-bit).
> 
> After untarring and doing a ./configure, when I try to make, very
> early in the compile I got the following error (which I presume was
> similar with your attempts):
>
>  gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -MT pollall_cdrv.lo -MD -MP -MF .deps
> /pollall_cdrv.Tpo -c ptransfer/pollall_cdrv.c  -fPIC -DPIC -o .libs/
> pollall_cdrv.o
> ptransfer/pollall_cdrv.c: In function 'ptransfer_pollall_send_block':
> ptransfer/pollall_cdrv.c:119: error: invalid lvalue in assignment
> make[2]: *** [pollall_cdrv.lo] Error 1
> make[2]: Leaving directory `/storage/home/shawn/psock-0.2a/psock'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/storage/home/shawn/psock-0.2a'
> make: *** [all] Error 2
> 
> I googled: error: invalid lvalue in assignment
> The first google result is this discussion thread:
> http://www.tek-tips.com/viewthread.cfm?qid=1353180&page=12
> 
> It is noted by the original poster later in the thread "[...] we haven't had
> issues with it compiling and working until we moved to gcc 4"
> He later notes " I have found referrences where the developers of gcc dropped
> support for 'casting an l-value', they called it a 'bogosity'."

Yes, that's right.

The code in question is:

    (const void*)iov[1].iov_base = buf;

And..., wow. That *does* look bogus. Even at the surface--if you need
a cast to remedy a type-mismatch, just put the cast on the *other*
side. Of course, if it's on the other side, the it the cast needs to
be the `other type', too.

Looking beyond the surface...:

> So it would appear this code is not "gcc4 friendly", so it either needs to be
> fixed (suggestions on how to do this are presented in the thread), or use a
> gcc3.x compiler. RH/CentOS provide such in the compat-gcc-34 (and C++ in
> compat-gcc-34-c++) packages.

"not `gcc4 friendly'" is not the term I'd use. The term I'd use
is probably more along the lines of... "wrong", but "bogosity"
is also apropos ;)

The problem becomes clear when you move the cast to the right (pun!) side:

    iov[1].iov_base = (void*) buf;

See how the cast just /removes/ the `const' qualifier from the value?
What that's saying is `this memory may be read-only, but we're going
to pretend that we can write to it regardless'.

So, the /actual/ fix is (presumably) to remove all of the `const'
qualifiers leading up to `const void *buf', and make sure that there
aren't actually any read-only buffes being passed along that
path. This may be somewhat involved.

Alternately, you can just add another level of indirection, e.g.:

    *((const void**) &iov[1].iov_base) = buf;

This is much `simpler': it just circumvents the sanity-check
that GCC4 is doing, so the code may not actually /work right/,
but it will compile without complaint.

There is a chance the the code's authors were right to do what they
were doing. It doesn't smell right, though.

-- 
Don't be afraid to ask (Lf.((Lx.xx) (Lr.f(rr)))).


More information about the gnhlug-discuss mailing list