[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:       George Staikos <staikos () kde ! org>
Date:       2001-04-04 22:13:30
[Download RAW message or body]

On Wednesday 04 April 2001 17:52, Oswald Buddenhagen wrote:

  Sorry for not being on top of this too much but I'm busy with school right 
now...

> we'll need a third try ... :(
>
> > 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.

  Terribly messy.  Exactly which platforms are causing these problems?

> > 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.

   There are two types on my system.  size_t and socklen_t.  If either of 
them are problems on any system, we need to provide both and define them 
where appropriate.  This is getting too confusing.

> > 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.

  These flags are nothing but trouble.  It's no wonder we're having problems.

> 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:

  Isn't that's what I was doing already? :)  Hm at least one of my versions 
did that anyways.  

> 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. :)

   I dunno.  I can't try it myself right now.  Perhaps next week or the week 
after.  In any case, I can change (or feel free to do it yourself) ksocks to 
do whatever is necessary with the types.


-- 

George Staikos

 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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