This is not a question but rather a conclusion. I do not know where to post this message since I do not think it is a bug of B4R but rather a difference in behaviour derived from the ESP8266 core. Consider the following code:
If you run it in an Arduino Nano (mine uses the old bootloader) it will work fine. If you run it though in an ESP8266 the code will break. If you try to get arr1 larger f.e.
B4X:
#Region Project Attributes
#AutoFlushLogs: True
#CheckArrayBounds: True
#StackBufferSize: 300
#End Region
'Ctrl+Click to open the C code folder: ide://run?File=%WINDIR%\System32\explorer.exe&Args=%PROJECT%\Objects\Src
Sub Process_Globals
Public Serial1 As Serial
Dim bc As ByteConverter
End Sub
Private Sub AppStart
Serial1.Initialize(9600)
Log("AppStart")
Dim arr1(200) As Byte
Dim arr2(210) As Byte
For ii= 0 To 199
arr1(ii) = 10
Next
For ii= 0 To 209
arr2(ii) = 50
Next
bc.ArrayCopy(arr2, arr1)
For ii = 0 To arr1.Length - 1
Log(ii, "-", arr1(ii))
Next
Log("Ok")
End SubIf you run it in an Arduino Nano (mine uses the old bootloader) it will work fine. If you run it though in an ESP8266 the code will break. If you try to get arr1 larger f.e.
Dim arr1(211) As Byte it will work fine. Thus in Arduino Nano it copies larger arrays to smaller ones but in ESP8266 it does not and the code breaks. What one has to do is to make always sure that the length of the array is at least as the one it will copy to it for the ESP8266.