[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: [PATCH] second try at fixing up socklen issues on Solaris
From:       Oswald Buddenhagen <ob6 () inf ! tu-dresden ! de>
Date:       2001-04-05 7:44:42
[Download RAW message or body]

> > Actually, this sounds perfect. I hadn't thought of forcing everyone
> > over to int externally instead of socklen_t. I won't get a chance to
> > look at this until at least tomorrow, so if somone else builds a
> > patch, that's fine. It's not complicated, just insidious....
> 
> Which is exactly the reason I created the ksocklen_t type in the first 
> place. Actually, I didn't want to include sys/socket.h in the code just 
> to have socklen_t defined, so I created a type that would be exactly that.
> 
why didn't you just use int? ;)
never mind.

> Maybe the problem was making it a typedef instead of #define.
> 
i don't think so. this should not matter in the source (except some
possible warnings about type mismatches).

> So, my recommendation is: - use a general type for all KDE exported
> functions, from KExtendedSocket, KSocket, K*SocketAddress and
> KSocks. Should be "int", "unsigned" or a #define'd ksocklen_t
> 
i'm voting for unsigned. it's compatible with sizeof() (no gcc warning
...) and it's a primitive type.

> - make sure all our calls to the system functions cast that to 
> "ksize_t", which is #define'd to be the third parameter of getsockname()
> 
yes, but note, that casting is possible only for values. don't cast 
pointers - they need the temporary step i presented in the previous mail.

> And "ksize_t" is a misnomer. It's the one that should be "ksocklen_t", 
>
yeah ... :(

> but we can't change that anymore.
>
why? the goal is not to export it. and running a perl -pi on the whole
kde sources is no problem. am i missing something?

> Or it should be "size_t", not the third parameter of getsockname().
> 
???

> I don't think typedef is a good alternative anymore because some 
> compilers use the new type's name in the mangling of the C++ function, 
> while others (like gcc) will use the primitive type.
> 
sounds sensible.

best regards

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Nothing is fool-proof to a sufficiently talented fool.
 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]