I've pinpointed the issue in our code, but I have no clue how the heck to implement any fixes in the source for this yet...
Here's a simple little QB64 program for illustration purposes:
Now, this produces code with the glitch in it for us, which looks like this:
S_0:;
fornext_value2= 1 ;
fornext_finalvalue2= 100 ;
fornext_step2= 1 ;
if (fornext_step2<0) fornext_step_negative2=1; else fornext_step_negative2=0;
if (new_error) goto fornext_error2;
goto fornext_entrylabel2;
while(1){
fornext_value2=fornext_step2+(*__SINGLE_I);
fornext_entrylabel2:
*__SINGLE_I=fornext_value2;
if (fornext_step_negative2){
if (fornext_value2<fornext_finalvalue2) break;
}else{
if (fornext_value2>fornext_finalvalue2) break;
}
fornext_error2:;
tmp_long=(qbr(*__SINGLE_I))-__ARRAY_BYTE_B[4];
if (!new_error) ((int8*)(__ARRAY_BYTE_B[0]))[tmp_long]=qbr_float_to_long(*__SINGLE_I);
tmp_long=(qbr(*__SINGLE_I))-__ARRAY_STRING1_S[4];
if (!new_error) qbs_set(qbs_new_fixed(&((uint8*)(__ARRAY_STRING1_S[0]))[tmp_long*1],1,1),func_chr(qbr(*__SINGLE_I)));
qbs_cleanup(qbs_tmp_base,0);
fornext_continue_1:;
}
fornext_exit_1:;
sub_open(qbs_new_txt_len("temp.txt",8), 2 ,NULL,NULL, 1 ,NULL,0);
qbs_cleanup(qbs_tmp_base,0);
sub_put( 1 ,NULL,byte_element((uint64)(&(((int8*)(__ARRAY_BYTE_B[0]))[0])),(1*(__ARRAY_BYTE_B[2]&1)*__ARRAY_BYTE_B[5])-(1*(0)),byte_element_3),0);
//sub_put( 1 ,NULL,byte_element((uint64)(&(qbs_new_fixed(&((uint8*)(__ARRAY_STRING1_S[0]))[(0)*1],1,1))),(1*(__ARRAY_STRING1_S[2]&1)*__ARRAY_STRING1_S[5])-(1*(0)),byte_element_4),0);
sub_put( 1 ,NULL,byte_element((uint64)(&(((uint8*)(__ARRAY_STRING1_S[0]))[(0)*1])),(1*(__ARRAY_STRING1_S[2]&1)*__ARRAY_STRING1_S[5])-(1*(0)),byte_element_4),0);
qbs_cleanup(qbs_tmp_base,0);
sub_end();
return;
}
Now, you might notice that there's a line already commented out for us above -- that's the line that's producing the glitch for us. Let me grab it and the line above it and below it to highlight the issue...
Here's the line above it, which works for _BYTE arrays:
sub_put( 1 ,NULL,byte_element((uint64)(&(((int8*)(__ARRAY_BYTE_B[0]))[0])),(1*(__ARRAY_BYTE_B[2]&1)*__ARRAY_BYTE_B[5])-(1*(0)),byte_element_3),0);
And here's our problem line, as we're currently translating it:
sub_put( 1 ,NULL,byte_element((uint64)(&(qbs_new_fixed(&((uint8*)(__ARRAY_STRING1_S[0]))[(0)*1],1,1))),(1*(__ARRAY_STRING1_S[2]&1)*__ARRAY_STRING1_S[5])-(1*(0)),byte_element_4),0);
And, if we change it to match the previous syntax, it works as it should for us with:
sub_put( 1 ,NULL,byte_element((uint64)(&(((uint8*)(__ARRAY_STRING1_S[0]))[(0)*1])),(1*(__ARRAY_STRING1_S[2]&1)*__ARRAY_STRING1_S[5])-(1*(0)),byte_element_4),0);
The issue is in the colored sections which I'll highlight here, which really don't seem to be needed at all in the code:
sub_put( 1 ,NULL,byte_element((uint64)(&(
qbs_new_fixed(&((uint8*)(__ARRAY_STRING1_S[0]))[(0)*1]
,1,1))),(1*(__ARRAY_STRING1_S[2]&1)*__ARRAY_STRING1_S[5])-(1*(0)),byte_element_4),0);
If someone can find the segment in our source (QB64.BAS, I'd imagine) that's adding the section above to our output, and we can remove it, I think the issue will disappear for us. Unfortunately, as you can tell from the code above, the source for this translation is kinda a mess, and so far, I haven't been able to locate the line(s) that are producing this extra, unneeded information for us.
I think I've zoomed in and found the problem, but I'm still looking for where the shooting range is, before I can even take a shot at fixing the glitch itself. :P
And for those that want to test the fix for themselves, you can manually go into main.txt and make the changes to your own code, and then run recompile.bat to create an EXE which works without issue while putting a whole string * 1 array to file.
