At final step, and after some other tests, I think I found the origin of the bug :
1/ Supposing a unit is set with "x" strikes in editor
2/ Supposing a terrain is set with a penalty of "y" in number of strikes for unit that are on this terrain
If the reduction of strikes number (x - y) is > 0 or = 0 : all works ok in game
If the reduction of strike number (x - y) is < 0 , the programm has a bug and give 255 strike to the concerned unit
I tested :
If I give 2 strikes to armored assault guns and if at the same time I give them a penalty of -2 strike on rough terrains : in game, they display 0 strikes = all is ok
But if I give only 1 strike to armored assault guns and if at the same time I give them a penalty of -2 strikes, the result is that 1 - 2 = -1 and in this case program has a bug and give them 255 strikes
Conclusion : somewhere in the code, a function is missing : this function should "say" to the program this instruction :
if the final result of number of strikes for a unit, considering penalties of terrains that reduce this number of strikes, is < 0, consider that 0 has to be applied in place of the real negative result
The problem does not come from negative values themselves, it comes from the lack of this needed instruction : if the difference between basic capacity and penalty become negative, the program should consider that 0 has to be applied in place of this negative result.
So, I think that the bug I reported in the first post here (long and repetitive attacks cycle):
https://forums.matrixgames.com/viewtopic.php?t=418666
does come from this instruction that is missing in the code : the unit is on a terrain that does reduce his strike capacity under 0 (example : 1-2=-1, etc), and in this case the program "bugs" : it gives 255 strikes to the unit, and that does cause the long attack cycles I reported.
I think this analyse should probably work for all negative parameters in the editor : when the difference between basic capacity of unit and reduction caused by penalty is < 0, the program "bugs" because it has no any instruction to take 0 as result in place of the negative result.
Conclusion : Users of editor have to take care when they set the parameters :
Never set a negative penalty that is superior (in absolute values) to the basic capacity of the concerned unit,
because the goal is to have a result = 0 or > 0, and never a negative result that does cause the reported bug.
Each time you have as final result of the below operation a negative result, you will have a problem.
Total "vanilla" capacity of a unit (for any matter) - total of penalties for this unit in a certain terrain = x
If x is < 0, you have a risk of bug because the program don't know it should ignore this negative result and that it should in place apply 0
The practical problem is that : it's easy to take care to set a penalty inferior or equal to the basic capacity of a unit, but it's more difficult to do the synthetic/global analysis of all different penalties we set for a unit, that may conduct this unit to have a negative value at final step
If the program would have the instruction to replace the eventual negative result by 0, all things would work ok.
EDIT :
Another practical solution could also be that : To implement in editor an alert when settings choiced by users in COUNTRY DATA, DEFENSE BONUS DATA, MOVEMENT COST DATA and PENALTIES-BONUS DATA, etc) conduct to a final negative value for the concerned capacity (number of strikes, entrenchment, etc)
In informatic matter, value = -1 are sometimes highly dangerous devils 
