[Nasm-bugs] [Bug 3392373] bugs found by pvs-studio

[no-reply at bugzilla-nasm.gorcunov.org]

https://bugzilla.nasm.us/show_bug.cgi?id=3392373

Cyrill Gorcunov <gorcunov at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|OPEN                        |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Cyrill Gorcunov <gorcunov at gmail.com> ---
> 
> In addition, pvs-studio is pointing out some code fragments that I am unsure
> how to resolve, or if they are real issues. It would be great if someone
> more familiar with the code base had a look at these:
> 
> asm/float.c:587	err	V512 A call of the 'memcpy' function will lead to
> underflow of the buffer 'mult'.

False alarm. The caller supplies fp_limb mant[MANT_LIMBS] pointer.

> 
> asm/assemble.c:338	warn	V507 Pointer to local array 'xdata' is stored
> outside the scope of this array. Such a pointer will become invalid.
> 
> asm/assemble.c:356	warn	V507 Pointer to local array 'xdata' is stored
> outside the scope of this array. Such a pointer will become invalid.

These two are vague: the @q variable used to write data and that's all.

> 
> asm/assemble.c:2351	err	V536 Be advised that the utilized constant value is
> represented by an octal form. Oct: 0370, Dec: 248.

Yes, we do use octal form on purpose.

> 
> asm/nasm.c:492	err	V595 The 'ofile' pointer was utilized before it was
> verified against nullptr. Check lines: 492, 499.

Wrong. The test already done as

        ofile = nasm_open_write(outname, (ofmt->flags & OFMT_TEXT) ? NF_TEXT :
NF_BINARY);
        if (!ofile)
            nasm_fatal(ERR_NOFILE,
                       "unable to open output file `%s'", outname);


> 
> asm/parser.c:528	warn	V557 Array underrun is possible. The value of 'slot'
> index could reach -1.

It won't. nasm_panic is called in prefix_slot for such case.

> 
> output/outas86.c:408	warn	V684 A value of the variable 'sym->flags' is not
> modified. Consider inspecting the expression. It is possible that '1' should
> be present instead of '0'.

No, it's for better readability.

Thanks again for the report! Very appreciated.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are watching all bug changes.