Hi, On 2024-05-20 19:03:25, Alexey Kardashevskiy wrote: > > > On Tue, 14 May 2024, at 19:08, Kautuk Consul wrote: > > Hi Alexey/Segher, > > > > :-). But this is the only other path that doesn't have a CATCH > > > > like the do-load subroutine in slof/fs/boot.fs. According to Segher > > > > there shouldn't ever be a problem with throw because if nothing else the > > > > outer-most interpreter loop's CATCH will catch the exception. But I > > > > thought to cover this throw in read-sector more locally in places near > > > > to this functionality. Because the outermost FORTH SLOF interpreter loop is not > > > > really so related to reading a sector in disk-label.fs. > > > > > > > Alexey/Segher, so what should be the next steps ? > > > Do you find my explanation above okay or should I simply remove these > > > CATCH blocks ? Putting a CATCH block in count-dos-logical-partitions is > > > out of the question as there is already a CATCH in do-load in > > > slof/fs/boot.fs. This CATCH block in the open subroutine is actually to > > > prevent the exception to be caught at some non-local place in the code. > > > > Any ideas on how we proceed with this now ? > > > Ufff, I dropped the ball again :-/ > > Sorry but if read-sector cannot read a sector because of misconfiguration (not because some underlying hardware error) - this tells me that this should be handled when we open the block device which we knows the size of in sectors and if it is not an integer - barf there. Or it is not possible? In general, when you tweak libvirt xml like this - there are plenty of ways to break SLOF, this one is not worth of another exception throwing imho. Thanks, Sure, no issues. Just thought to send in this patch as we encountered this problem. Will abandon this email chain now. Thanks again! :-)
