Re: Fwd: Bug#1050663: dar option --on-fly-isolate creates catalogue with broken slice_layout

On 03/09/2023 19:37, Rolf Gebhardt wrote:
> Hello everyone,

Hi Rolf,

> 
> I've been following the discussion here and had a look at the patch and 
> the associated code of the class 'slice_layout'.
> I noticed one little thing:As far as I can see, the boolean member 
> variable 'older_sar_than_v8', which acts as condition in the patched 
> code, is not initialized in the constructor.

Yes, you are correct, but this is not necessary (read below)

> 
> I'm not familiar with the internals of DAR, so I don't know if 
> slice_layout::write can be called without first calling 
> slice_layout::read or slice_layout::clear. 

In the slice_layout::older_sar_than_v8 (as well as some others) are 
public and are either:
- initialized by the caller code (sar, macro_tools, ...) before calling 
slice_layout::write() to write this to an dar backup
- or setup by the caller code using slice_layout::read() to reading 
those same fields from an existing dar backup, in order then to use this 
slice_layout fields.

In other words, this class is used like a C struct, but with two 
additional methods to read() and write() those fields to and from a dar 
backup.

If it were and I'm right with
> my observation, the variable would be uninitialized in this case and its 
> value would be random (or more correctly: determined by the previous 
> history).
> If it is ensured that 'write' is never called without a previous 'read' 
> or 'clear', this can of course be ruled out as the cause.

What should be ensured here, is that the fields value are properly set 
before calling slice_layout::write(), which is here the point, as the 
resulting on-fly isolated catalogue seems to have been setup with 
unacceptable value for that slice_layout::older_sar_than_v8 field, 
leading --- at reading time --- libdar to complain about that incorrect 
value.

But as the valid values for this field are either '7' or '8', I doubt 
that the compiler would set this field to either one of these 
non-trivial values when optimizations are disabled, if ever libdar 
lacked to initialize it properly...

Anyway, I will have to double check this, just in case.

Thank you for your comment, better checking my backyard is clean, before 
going further toward gcc :)

> 
> Best regards
> 
> Rolf
> 
[...]

Regards,
Denis