Re: FXText setSelection

On 2025-09-22 13:13, John Selverian wrote:
> I have an FXText control and I use the following to select all of
> the text:
> 
> 
> 
> 
> 
>                 // select all
> 
>                 text->setSelection(0, text->getLength(), false);
> 
> 
> 
> 
> 
> it works fine but what I run "Code Analysis" in MSVS I get the
> following warning:
> 
> 
> 
> 
> 
> warning C6385: Reading invalid data from 'this->text':  the
> readable size is '8' bytes, but '261864' bytes may be read.
> 
> 
> 
> 
> 
> I get a similar warning:
> 
> 
> 
> warning C6386: Buffer overrun while writing to '_x_orig[iCurve]':
> the writable size is 'numDataPoints*8' bytes, but '16' bytes
> might be written.
> 
> 
> 
> 
> 
> With the code below:
> 
> 
> 
> 
> 
> 
> 
>                 // copy data to local arrays
> 
>                 for (int iCurve = 0; iCurve < _numCurves;
> iCurve++)
> 
>                 {
> 
>                                 for (int i = 0; i <
> _numDataPoints[iCurve]; i++)
> 
>                                 {
> 
>                                                 _x[iCurve][i] =
> _x_orig[iCurve][i] = plotDataArray[iCurve].x[i];
> 
>                                                 _y[iCurve][i] =
> _y_orig[iCurve][i] = plotDataArray[iCurve].y[i];
> 
>                                 }
> 
>                 }
> 
> 
> 
> 
> 
> 
> 
> 
> 
> What does this mean?

------

Possibility is that analyzer gets confused.  The array access to 
FXString's
buffer, and FXArray's buffer starts PAST the pointer returned by malloc, 
on account
of the fact that I keep the size of the arrays inside the array as the 
1st element;
[and before you ask, yes, stuff *does* pay attention to possible 
alignment issues].

Simple-minded code analysis may be thinking that array should start at 
pointer
returned to malloc.

On top of that, array sizes are allocated to the nearest multiple of 
ROUNDVAL,
[16 bytes in case of FXString].  Rationale is that you can't *really* 
allocate
anything smaller than that [first, malloc keeps some bookkeeping info 
around
the block, and needs to keep more bookkeeping info INSIDE the block 
after
its freed [so it can potentially merge with neighboring blocks once they
get freed].

Plus, minimum alignment size on 64-bit cpu is 8 bytes, possibly longer 
if
allocation routines are set up to be "SSE friendly".  SSE and AVX like
accesses to be 128 or 256-byte aligned, and you could set up malloc()
to make the alignment bigger than stock 64 bytes.

Botton line, if you ask for smaller buffers, the system will still round
them up to bigger sizes so you might as well ask for bigger size to 
begin
with, and thus grow your buffer up to that size w/o data movement.


            -- JVZ