Hi All,

         This is regd the bug reported in tracker 
http://sourceforge.net/tracker/?func=detail&aid=3040496&group_id=1730&atid=101730
Richard had agreed to merge the two patches but he seems very busy. I would not 
want to disturb him so i decided to merge it myself.
I just wanted to let others know of the changes. Multiple revisions of the 
patches are already done and can be found in the tracker. If anyone has
any issues let me know.

Regards,
Varun
--- Begin Message ---
I will aim to get the patches in by the end of this week, if possible

-----Original Message-----
From: Varun Chandramohan [mailto:var...@linux.vnet.ibm.com]
Sent: 07 September 2010 09:07
To: Morrell Richard (external)
Subject: Re: Fwd: Re: Optional % parameter


Hi Richard,

                 May i know the approx time you would be commiting these
parches? I have updated win32 patch as take2. This is just clean up. These 2
patches are ready for upstream.

Regards,
Varun

On Tuesday, August 31, 2010 09:29:26 am Varun Chandramohan wrote:
> 
> ----------  Forwarded Message  ----------
> 
> Subject: Re: Optional % parameter
> Date: Tuesday, August 31, 2010, 09:29:00 am
> From: Varun Chandramohan <var...@linux.vnet.ibm.com>
> To: Varun Chandramohan <var...@linux.vnet.ibm.com>
> 
> Hi Richard,
> 
>                 I have asked my colleagues to work on a fix for win32. It
was already there. We did extensive testing and found few more bugs on win32
platform. Iam have uploaded that patch in the tracker with
> the name 385069: interface_scope_fix_final_win32_take1.patch
> 
> Could you please include this patch too over the commit. Fro our testing
it found to be working fine.
> 
> Regards,
> Varun
> 
> On Friday, August 20, 2010 06:59:48 pm you wrote:
> > Hi Richard,
> > 
> >                 Not an issue :-), i understood you were busy. Please
patch in and let me know. After your busy period is over can you look at
that MTU patch too?
> > 
> > Regards,
> > Varun
> > 
> > On Friday, August 20, 2010 06:53:51 pm Morrell Richard (external) wrote:
> > > Hi Varun,
> > > 
> > > I can hardly complain about you incorporating my own code, can I ?
No, I've
> > > no further concerns.
> > > 
> > > I'm in another busy period at the moment, but I'll see if I can
squeeze the
> > > patch in.
> > > 
> > > Regards,
> > > 
> > > Richard
> > > 
> > > -----Original Message-----
> > > From: Varun Chandramohan [mailto:var...@linux.vnet.ibm.com]
> > > Sent: 17 August 2010 03:00
> > > To: Morrell Richard (external)
> > > Subject: Re: Optional % parameter
> > > 
> > > 
> > > Any more changes needed? My mail server had conked off so was
wondering if i
> > > missed any mails yesterday. 
> > > 
> > > On Friday, August 13, 2010 09:48:50 am Varun Chandramohan wrote:
> > > > Hi Richard,
> > > > 
> > > >                  Take 4 has all changes you wanted. Its uploaded in
the
> > > tracker. Let me know if you are ok with it.
> > > > 
> > > > Regards,
> > > > Varun
> > > > 
> > > > On Thursday, August 12, 2010 07:14:47 pm you wrote:
> > > > > Hi Varun,
> > > > > 
> > > > > Hopefully the last point.
> > > > > 
> > > > > SLP_inet_pton:
> > > > > If the source string had exactly INET6_ADDRSTRLEN characters
before the
> > > %
> > > > > character, then the check you put in would allow the tmp_addr
buffer to
> > > be
> > > > > completely filled, overwriting all NULs, so the buffer passed to
> > > inet_pton
> > > > > might not be NUL-terminated.  The check should be against
> > > INET_ADDRSTRLEN-1:
> > > > >                            if (i == INET6_ADDRSTRLEN-1)
> > > > >                                       return -1;
> > > > > 
> > > > > I'm not sure how often this function is called, but there are some
> > > > > performance improvements that could be incorporated:
> > > > > 
> > > > > static int SLP_inet_pton(int af, char *src, void *dst)
> > > > > {
> > > > >     if(af == AF_INET6) {
> > > > >         char *src_ptr = src;
> > > > >         char tmp_addr[INET6_ADDRSTRLEN];
> > > > >         char *tmp_ptr = tmp_addr;
> > > > >         int bufleft = INET6_ADDRSTRLEN;
> > > > > 
> > > > >         while(*src_ptr && (*src_ptr != '%')) {
> > > > >             if (!--bufleft) {
> > > > >                 /* Need to have at least one byte left for the
trailing
> > > NUL
> > > > > */
> > > > >                 return -1;
> > > > >             }
> > > > >             *tmp_ptr++ = *src_ptr++;
> > > > >         }
> > > > >         *tmp_ptr = '\0';
> > > > >         return inet_pton(af, (char *)&tmp_addr, dst);
> > > > >     } else {
> > > > >         return inet_pton(af, src, dst);
> > > > >     }
> > > > > }
> > > > > 
> > > > > That gets rid of the call to memset, the repeated calls to
strlen() in
> > > the
> > > > > while condition, and the indexing operations on tmp_buffer[i].
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Varun Chandramohan [mailto:var...@linux.vnet.ibm.com]
> > > > > Sent: 11 August 2010 11:05
> > > > > To: Morrell Richard (external)
> > > > > Subject: Re: Optional % parameter
> > > > > 
> > > > > 
> > > > > On Wednesday, August 11, 2010 02:40:41 pm you wrote:
> > > > > > Hi Varun,
> > > > > > 
> > > > > > >> SLPGetIfaceNameFromScopeId:
> > > > > > >> 1) There is no protection against the name overflowing a
buffer of
> > > size
> > > > > > >> MAX_IFACE_LEN.
> > > > > > >> 2) When copying the interface name, the buffer is not
> > > NUL-terminated,
> > > > > and
> > > > > > in
> > > > > > >> this case you haven't zeroed the buffer in the caller.  For
the
> > > same
> > > > > > reasons
> > > > > > >> as SLPD_Get_Iface_From_Ip, I suggest the NUL termination
should be
> > > done
> > > > > > in
> > > > > > >> the function, not the caller, eg. using strcpy().
> > > > > > >> 
> > > > > > >For these two points you mean this code?
> > > > > > >if(((struct sockaddr_in6 *)ifa->ifa_addr)->sin6_scope_id ==
scope_id)
> > > {
> > > > > > >                memcpy(iface, ifa->ifa_name,
strlen(ifa->ifa_name));
> > > > > > >                freeifaddrs(ifaddr);
> > > > > > >                return 0;
> > > > > > >        }
> > > > > > Yes, that's the section of code I was referring to.
> > > > > > >
> > > > > > >The ifs->ifa_name will never be greater than MAX_IFACE_LEN. The
> > > > > > MAX_IFACE_LEN we defines is same as what is defined in linux
kernel,
> > > > > > >so i think we are safe here. However i can convert memcpy to
strcpy.
> > > Is
> > > > > > that ok?
> > > > > > 
> > > > > > Yes, please use strcpy rather than memcpy - it is needed here.
> > > > > > 
> > > > > > If the value is the same as what is defined in the linux kernel,
then
> > > is
> > > > > > there a macro defined for the value in the linux headers that we
can
> > > use
> > > > > > instead of a literal value ?  Where did you find the value in
the
> > > first
> > > > > > place ?  Although it works for now, it might change in future.
The
> > > > > ifaddrs
> > > > > > interface is available on platforms other than linux, so the
code may
> > > in
> > > > > > future get used on platforms where the value of 20 does not
hold.  It
> > > > > > doesn't cost much to put the length check in:
> > > > > > 
> > > > > >                 if (strlen(ifa->ifa_name) >= MAX_IFACE_LEN)
> > > > > >                 {
> > > > > >                         freeifaddrs(ifaddr);
> > > > > >                         return -1;
> > > > > >                 }
> > > > > >                 memcpy(iface, ifa->ifa_name,
strlen(ifa->ifa_name));
> > > > > >                 freeifaddrs(ifaddr);
> > > > > >                 return 0;
> > > > > > 
> > > > > > Incidentally, the #include <ifaddrs.h> in slp_socket.h is
> > > unconditionally
> > > > > > included - should it be conditional on LINUX for now ?  I have
found a
> > > > > > reference to it not being available on AIX 5.3, for example.
> > > > > > 
> > > > > > ie. should we use
> > > > > > 
> > > > > > #if defined(LINUX)
> > > > > > #include <ifaddrs.h>
> > > > > > #endif
> > > > > You are right, that value might change in future. I will put a
check
> > > none
> > > > > the less.
> > > > > Finished with all changes and uploaded to tracker. Please check.
> > > > > 
> > > > > > 
> > > > > > This email, including any attachment, is a confidential
communication
> > > > > > intended solely for the use of the individual or entity to whom
it is
> > > > > > addressed. It contains information which is private and may be
> > > proprietary
> > > > > > or covered by legal professional privilege. If you have received
this
> > > > > email
> > > > > > in error, please notify the sender upon receipt, and immediately
> > > delete it
> > > > > > from your system.
> > > > > > 
> > > > > > Anything contained in this email that is not connected with the
> > > businesses
> > > > > > of this company is neither endorsed by nor is the liability of
this
> > > > > company.
> > > > > > 
> > > > > > Whilst we have taken reasonable precautions to ensure that any
> > > attachment
> > > > > to
> > > > > > this email has been swept for viruses, we cannot accept
liability for
> > > any
> > > > > > damage sustained as a result of software viruses, and would
advise
> > > that
> > > > > you
> > > > > > carry out your own virus checks before opening any attachment.
> > > > > > 
> > > > > > 
> > > > > 
> > > > > This email, including any attachment, is a confidential
communication
> > > > > intended solely for the use of the individual or entity to whom it
is
> > > > > addressed. It contains information which is private and may be
> > > proprietary
> > > > > or covered by legal professional privilege. If you have received
this
> > > email
> > > > > in error, please notify the sender upon receipt, and immediately
delete
> > > it
> > > > > from your system.
> > > > > 
> > > > > Anything contained in this email that is not connected with the
> > > businesses
> > > > > of this company is neither endorsed by nor is the liability of
this
> > > company.
> > > > > 
> > > > > Whilst we have taken reasonable precautions to ensure that any
> > > attachment to
> > > > > this email has been swept for viruses, we cannot accept liability
for
> > > any
> > > > > damage sustained as a result of software viruses, and would advise
that
> > > you
> > > > > carry out your own virus checks before opening any attachment.
> > > > > 
> > > > > 
> > > > 
> > > 
> > > This email, including any attachment, is a confidential communication
> > > intended solely for the use of the individual or entity to whom it is
> > > addressed. It contains information which is private and may be
proprietary
> > > or covered by legal professional privilege. If you have received this
email
> > > in error, please notify the sender upon receipt, and immediately
delete it
> > > from your system.
> > > 
> > > Anything contained in this email that is not connected with the
businesses
> > > of this company is neither endorsed by nor is the liability of this
company.
> > > 
> > > Whilst we have taken reasonable precautions to ensure that any
attachment to
> > > this email has been swept for viruses, we cannot accept liability for
any
> > > damage sustained as a result of software viruses, and would advise
that you
> > > carry out your own virus checks before opening any attachment.
> > > 
> > > 
> > 
> 
> -----------------------------------------
> 

This email, including any attachment, is a confidential communication
intended solely for the use of the individual or entity to whom it is
addressed. It contains information which is private and may be proprietary
or covered by legal professional privilege. If you have received this email
in error, please notify the sender upon receipt, and immediately delete it
from your system.

Anything contained in this email that is not connected with the businesses
of this company is neither endorsed by nor is the liability of this company.

Whilst we have taken reasonable precautions to ensure that any attachment to
this email has been swept for viruses, we cannot accept liability for any
damage sustained as a result of software viruses, and would advise that you
carry out your own virus checks before opening any attachment.


--- End Message ---
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Openslp-devel mailing list
Openslp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openslp-devel

Reply via email to