[#7653] parse.y: literal strings for tokens — Robin Stocker <robin@...>
Hi,
Hi,
Yukihiro Matsumoto wrote:
[#7674] Re: [PATCH] parse.y: literal strings for tokens — ville.mattila@...
ville.mattila@stonesoft.com wrote:
Hi again,
Hi,
[#7692] Socket Documentation commit ? — zdennis <zdennis@...>
-----BEGIN PGP SIGNED MESSAGE-----
[#7708] Bug in libsnmp-ruby1.8 — Hadmut Danisch <hadmut@...>
Hi,
On Apr 11, 2006, at 6:23 AM, Hadmut Danisch wrote:
On 2006-04-12 02:04:32 +0900, Eric Hodel wrote:
On Apr 11, 2006, at 10:20 AM, Marcus Rueckert wrote:
[#7721] Ruby mentor in Googe's Summer of Code — "Evan Phoenix" <evan@...>
We missed out on it last year, so lets this year try to get ruby
[#7725] readpartial not working on ARM — Joel VanderWerf <vjoel@...>
[#7727] Stack trace doesn't include class — noreply@...
Bugs item #4151, was opened at 2006-04-17 23:10
On Apr 17, 2006, at 1:11 PM, noreply@rubyforge.org wrote:
On Wed, 19 Apr 2006, Eric Hodel wrote:
Hi --
[#7729] xmlrpc and charset=utf-8 — "Phil Tomson" <rubyfan@...>
I'm needed to interact with an XMLRPC server written using the
>>>>> On Sun, 18 Jun 2006 12:00:19 +0900
I first sent this from the wrong email account, so if that post somehow makes
On 6/19/06, Sean Russell <ser@germane-software.com> wrote:
[#7738] RDoc patches for GetoptLong — mathew <meta@...>
I added RDoc documentation to GetoptLong. The patches are attached. As
[#7744] Coverity Scan — "Pat Eyler" <rubypate@...>
I don't know if anyone else has signed up for access to the coverity
[#7765] possible defect in array.c — "Pat Eyler" <rubypate@...>
This one may be a false positive, I'm not sure. If it is, I'll happily mark
On 4/25/06, Pat Eyler <rubypate@gmail.com> wrote:
[#7770] Re: possible defect in array.c — "Brown, Warren" <warrenbrown@...>
> rb_range_beg_len (in range.c) does set beg and len.
On 4/26/06, Brown, Warren <warrenbrown@aquire.com> wrote:
On 4/26/06, Pat Eyler <rubypate@gmail.com> wrote:
On 4/26/06, Jacob Fugal <lukfugl@gmail.com> wrote:
On Thu, Apr 27, 2006 at 01:15:24AM +0900, Pat Eyler wrote:
Hi,
On Thu, Apr 27, 2006 at 09:41:00AM +0900, Nobuyoshi Nakada wrote:
[#7799] Patch: code-cleanup (k&r style) — Stefan Huehner <stefan@...>
Hi,
Hi,
Another unitialized variable defect
(I hope I'm finally getting the hang of this.)
Another possible defect from Coverity looks like this:
----------------------------------------------------------------------------------------
915 static VALUE
916 BigDecimal_round(int argc, VALUE *argv, VALUE self)
917 {
918 ENTER(5);
919 Real *c, *a;
Event var_decl: Declared variable "iLoc" without initializer
Also see events: [uninit_use_in_call]
920 int iLoc;
921 U_LONG mx;
922 VALUE vLoc;
923 VALUE vRound;
924 U_LONG pl;
925
926 int sw = VpGetRoundMode();
927
928 int na = rb_scan_args(argc,argv,"02",&vLoc,&vRound);
929 switch(na) {
930 case 0:
931 iLoc = 0;
932 break;
933 case 1:
934 Check_Type(vLoc, T_FIXNUM);
935 iLoc = FIX2INT(vLoc);
936 break;
937 case 2:
938 Check_Type(vLoc, T_FIXNUM);
939 iLoc = FIX2INT(vLoc);
940 Check_Type(vRound, T_FIXNUM);
941 sw = FIX2INT(vRound);
942 if(!VpIsRoundMode(sw)) {
943 rb_raise(rb_eTypeError, "invalid rounding mode");
944 return Qnil;
945 }
946 break;
947 }
948
At conditional (1): "0" taking true path
949 pl = VpSetPrecLimit(0);
950 GUARD_OBJ(a,GetVpValue(self,1));
951 mx = a->Prec *(VpBaseFig() + 1);
952 GUARD_OBJ(c,VpCreateRbObject(mx, "0"));
953 VpSetPrecLimit(pl);
Event uninit_use_in_call: Using uninitialized value "iLoc" in call to
function "VpActiveRound" [model]
Also see events: [var_decl]
954 VpActiveRound(c,a,sw,iLoc);
955 return ToValue(c);
956 }
----------------------------------------------------------------------------------------
As long as rb_scan_args returns a 0, 1, or 2 everything will be good,
so this is probably a false positive. Since 0 is a valid value for
na, it could be initialized to zero and any uncertainty avoided:
@@ -917,7 +917,7 @@ BigDecimal_round(int argc, VALUE *argv,
{
ENTER(5);
Real *c, *a;
- int iLoc;
+ int iLoc = 0;
U_LONG mx;
VALUE vLoc;
VALUE vRound;