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