[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-04 21:52:20
[Download RAW message or body]

hi,

we'll need a third try ... :(

> This one is a compromise between my original patch and some of
> Oswald's comments.
> 
yes, but it won't work ...

> Oswald believes we should have a ksocks.h.in (or other .h.in) to get
> ksocklen_t defined correctly (Oswald, please correct me if I'm
> misquoting you).
>
socklen_t, not ksocklen_t. but i guess, this was a typo.

> I don't like .h.in's if I can avoid them (they make include files
> platform dependent).
> 
yes. and they require a config.status run after changing the .h.in.
they are evil.

> Besides, there's no reason that callers should have to deal with a
> changeable parameter. ksock should hide this platform annoyance IMO
> and simply accept socklen_t (and define it for anyone who needs it).
> 
yes, this is the idea behind all that stuff.

> My solution gets rid of ksocklen_t in preference to simply using
> socklen_t (defining it in ksockaddr.h if needed).
the #define is fine, but the #ifndef won't work, as already stated.
if the system supports socklen_t, it is a typedef. the preprocessor
won't notice this and always #define socklen_t to unsigned. this is
the reason, why i suggested to change the ksize_t check into a
socklen_t check&define.

> I still use ksize_t in ksocks.cpp.  Maybe it's a bad name for it
> (maybe *this* should be ksocklen_t? or
> third_param_to_getsockname_t?), but it's a really good typedef.
>
yes, it is a bad name. the correct name IS socklen_t. get rid of
ksize_t.

> I got rid of all the XOPEN checks as Oswald suggested.
> 
i said, that i have no idea about that stuff ... ;)
but this should not matter, if the socklen_t check is ok. the only
point to keep in mind is, that all sources must be compiled with the
same -D<something> flags (or the lack of them), where <something>
is something like _POSIX_SOURCE, _XOPEN_SOURCE, etc.


if we don't want to install a system-dependend include file, we
"simply" should not export any functions with the questionable
parameter type - simply use int for this. inside the kde sources we
can use socklen_t, as our configure detected it. if we have to receive
lengths from users, we can put code like this in the exported
functions:

public KSocket::SockFunc(int fd, struct sockaddr *addr, int *len)
{
   socklen_t ouraddr = (socklen_t) *len;
   ::sockfunc(fd, addr, &ouraddr);
   *len = (int) ouraddr;
}

that way we would basically hide this whole size_t-instead-of-int 
braindamage the posix bozos created from our users (and ourselves).
hmm ... this sounds too simple to be possible. i surely overlooked
something. :)

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]