[request-sponsor] Bug i.d 5054112_fix synopsis:_tx_error needs to preserve the errno value it is supposed to display
Bug I.d :5054112 Synopsis _tx_error needs to preserve the errno value it is supposed to display Category:Subcategory library:libnsl Fix send by: Hima Gopi - Awaiting SCA numberArchana.N - SCA number:OS0167 Description: _tx_error, called by t_error, is supposed to display a message, followed by the error string for the error defined in t_errno, followed by the error string for the error defined in errno. If any of the system calls/library routines invoked between the start of _tx_error and when it calls perror() set errno, the output will be incorrect. _ Post free property ads on Yello Classifieds now! www.yello.in http://ss1.richmedia.in/recurl.asp?pid=219 -- next part -- An HTML attachment was scrubbed... URL: http://mail.opensolaris.org/pipermail/request-sponsor/attachments/20080113/2ae484b0/attachment.html -- next part -- An embedded and charset-unspecified text was scrubbed... Name: diff_file_Fix_Perror.txt URL: http://mail.opensolaris.org/pipermail/request-sponsor/attachments/20080113/2ae484b0/attachment.txt
[request-sponsor] Bug 6502132 comment in lx_call_init() lies
Hi , I would like to work on the bug : 6502132 and will finish working on it within 2 Days. (I have a fix ready) Bug ID 6502132 Synopsis comment in lx_call_init() lies Category:Subcategory kernel:brandz My SCA number is : OS0148 My opensolaris id : rishios see the attached and suggest me if you want asomething more Thanks Regards, Rishi M Nair -- next part -- An HTML attachment was scrubbed... URL: http://mail.opensolaris.org/pipermail/request-sponsor/attachments/20080113/32b5fd69/attachment.html -- next part -- An embedded and charset-unspecified text was scrubbed... Name: diff_lx_thunk_server.txt URL: http://mail.opensolaris.org/pipermail/request-sponsor/attachments/20080113/32b5fd69/attachment.txt
[request-sponsor] Bug:6207957
Sir,
I have worked upon this bug and ready with the diff.
My open solaris user id is : krishna.
SCA number : OS0191
BUG ID : 6207957
SYNOPSIS: uu_list_find() leaves error unset when successfully returning NULL
DESCRIPTION:
If uu_list_find() is called on a list which doesn't have a comparison
function, then it sets the uu_error() to UU_ERROR_NOT_SUPPORTED and
returns NULL. NULL is also the return value for when uu_list_find()
completes successfully, but didn't find anything. If the uu_error()
happened to be UU_ERROR_NOT_SUPPORTED before uu_list_find() was
called, then there's no way for the caller to know whether the function
completed successfully.
CATEGORY: library
SUBCATEGORY:libuutil
DIFF'S OUTPUT:
*
--- uu_list.c.orig Tue Oct 2 19:44:01 2007
+++ uu_list.c Sat Jan 12 10:46:29 2008
@@ -330,16 +330,19 @@
if (cmp == 0) {
if (out != NULL)
*out = NODE_TO_INDEX(lp, np);
+ uu_set_error(UU_ERROR_NONE);
return (ep);
}
if (sorted cmp 0) {
if (out != NULL)
*out = NODE_TO_INDEX(lp, np);
+ uu_set_error(UU_ERROR_NONE);
return (NULL);
}
}
if (out != NULL)
*out = NODE_TO_INDEX(lp, 0);
+ uu_set_error(UU_ERROR_NONE);
return (NULL);
}
**
Thanks Regards
Krishna Kumar
* *
* *
-- next part --
An HTML attachment was scrubbed...
URL:
http://mail.opensolaris.org/pipermail/request-sponsor/attachments/20080113/2953f281/attachment.html
[request-sponsor] Diff of the Bug:6598117
Hi,
I have completed the work on this bug by successfully building
it.Everythingworked fine.
So, i am sending the diff.
*Bug Id:* 6598117
*Synopsis:* code cleanup in vn_createat()
**
*Description:* Following code in vnode.c:vn_createat() is difficult to read:
offset = vap-va_size vattr.va_size ?
vattr.va_size : vap-va_size;
length = vap-va_size vattr.va_size ?
vap-va_size - vattr.va_size :
vattr.va_size - vap-va_size;
and would benefit if it is changed to:
offset = MIN(vap-va_size, vattr.va_size);
length = MAX(vap-va_size, vattr.va_size) - (size_t)offset;
oss-bite-size
*Category:* kernel:fs
*Diff:*
bash-3.00# diff -u vnode.c.orig vnode.c
--- vnode.c.origThu Dec 27 16:55:19 2007
+++ vnode.c Thu Dec 27 17:05:35 2007
@@ -1253,11 +1253,9 @@
u_offset_t offset;
ssize_t length;
- offset = vap-va_size vattr.va_size ?
- vattr.va_size : vap-va_size;
- length = vap-va_size vattr.va_size ?
- vap-va_size - vattr.va_size :
- vattr.va_size - vap-va_size;
+ offset = MIN(vap-va_size , vattr.va_size);
+ length = MAX(vap-va_size , vattr.va_size) -
(size_t)offset;
if (nbl_conflict(vp, NBL_WRITE, offset,
length, 0)) {
error = EACCES;
*SCA Number*: *OS0186 *
**
Thanks and Regards
Rejeesh Nath
-- next part --
An HTML attachment was scrubbed...
URL:
http://mail.opensolaris.org/pipermail/request-sponsor/attachments/20080113/591e4c72/attachment.html
[request-sponsor] The Diff Output For bug id 6207957
Sir,
I have already sent you the diff output but I think the following will be
more correct with the same effect.
Please check it.
*SCA Number:OS 0191*
My open solaris user id is : krishna.
*BUG ID : 6207957*
*SYNOPSIS:* uu_list_find() leaves error unset when successfully returning
NULL
*DESCRIPTION:*
If uu_list_find() is called on a list which doesn't have a comparison
function, then it sets the uu_error() to UU_ERROR_NOT_SUPPORTED and
returns NULL. NULL is also the return value for when uu_list_find()
completes successfully, but didn't find anything. If the uu_error()
happened to be UU_ERROR_NOT_SUPPORTED before uu_list_find() was
called, then there's no way for the caller to know whether the function
completed successfully.
*CATEGORY:* library
*SUBCATEGORY:*libuutil
*DIFF'S OUTPUT**:*
*
--- uu_list.c.orig Tue Oct 2 19:44:01 2007
+++ uu_list.c Sat Jan 12 13:16:31 2008
@@ -316,7 +316,7 @@
int sorted = lp-ul_sorted;
uu_compare_fn_t *func = lp-ul_pool-ulp_cmp;
uu_list_node_impl_t *np;
-
+ uu_set_error(UU_ERROR_NONE);
if (func == NULL) {
if (out != NULL)
*out = 0;
*
Looking forward to hear from you
*Thanking you sir*
*Krishnakumar D.*
-- next part --
An HTML attachment was scrubbed...
URL:
http://mail.opensolaris.org/pipermail/request-sponsor/attachments/20080113/73b99888/attachment.html
[request-sponsor] new bugs awaiting sponsors.
hi, i am working on the following bugs SCA no: OS0192 Bugid:6461634 Synopsis:gcore should warn the user if CTF was requested, but could not be produced Category:Subcategory utility:proc -- Bugid:6578204 Synopsis:centralise HMAC code into $SRC/common/crypto/ algorithm implementation Category:Subcategory solaris-crypto:algorithms - Bugid:6341292 Synopsis:cleanup of hsfs warning messages required Category:Subcategory kernel:hsf Bugid:6559498 Synopsis:sdpadm Makefile should use targets in $SRC/cmd/Makefile.targ Category:Subcategory ib_sw:sdp Bugid:6566991 Synopsis:broken ru_RU.UTF-8/Compose and pl_PL.UTF-8/locale_map files Category:Subcategory library:l10n-europe thanks Visakh Amrita School of Engineering Amritapuri. This message posted from opensolaris.org
[request-sponsor] new bugs awaiting sponsors.
On Sun, 13 Jan 2008, Visakh M R wrote: hi, i am working on the following bugs SCA no: OS0192 [ ... ] Bugid:6341292 Synopsis:cleanup of hsfs warning messages required Category:Subcategory kernel:hsf I'll sponsor you on that one. Please mail me off list. Thx, FrankH.
[request-sponsor] Request to work on a bug.
I would like to work on the bug having id- 6614275.
The following are the bug description :
In /usr/include/getopt.h, struct option is declared as:
struct option {
char *name; /* name of long option */
int has_arg;/* whether option takes an argument */
int *flag; /* if not NULL, set *flag to val when option found */
int val;/* if flag is not NULL, value to set *flag to. */
/* if flag is NULL, return value */
};
According to the Solaris man page and the GNU documentation for
getopt_long(), the name member should be of type const char*.
category:-library
subcategory:-libc
Thanking you.
Neena A S
SCA no - OS0161
Amrita vishwa vidyapeetham.
-- next part --
An HTML attachment was scrubbed...
URL:
http://mail.opensolaris.org/pipermail/request-sponsor/attachments/20080113/4d851baf/attachment.html
[request-sponsor] Can I subscribe this mailing list?
ying Now I've been approved to be a middle-tier sponsor. Anyone can subscribe to the mailing list. As a middle-tier sponsor, you are now welcome to sponsor requests as well. Have at it! :-) -- John http://blogs.sun.com/jbeck
