On Wed, 22 May 2024, at 18:55, Kautuk Consul wrote: > 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! :-) btw I was wondering what if you passed 513 as sector size, for example, have you tried? ;)
