Reading old files containing `std::auto_ptr<gen::PdfInfo>`

[makortel]

PR #43405 reminded us about the iorules in SimDataFormats/GeneratorProducts/src/classes_def.xml to read in std::auto_ptr<gen::PdfInfo> from files predating CMSSW_11_0_0. The std::auto_ptr was removed in C++17, although the libstdc++ still provides the implementation for backwards compatibility (link) while issuing a deprecation warning. We should nevertheless figure out a way to not have to use std::auto_ptr in the dictionaires (e.g. if we would have to use a standard library without std::auto_ptr some day).

For reference, here are pointers to various discussions from the time the iorules to convert the std::auto_ptr<gen::PdfInfo> to std::unique_ptr<gen::PdfInfo> were introduced

• https://root-forum.cern.ch/t/dictionary-generation-for-std-unique-ptr-error-root-6-12-07/30716
• https://sft.its.cern.ch/jira/browse/ROOT-9698
• https://sft.its.cern.ch/jira/browse/ROOT-9702
• Convert auto_ptr to unique_ptr in SimDataFormats/GeneratorProducts. #25239

[makortel]

assign core

[cmsbuild]

New categories assigned: core

@Dr15Jones,@makortel,@smuzaffar you have been requested to review this Pull request/Issue and eventually sign? Thanks

[cmsbuild]

A new Issue was created by @makortel Matti Kortelainen.

@makortel, @Dr15Jones, @rappoccio, @antoniovilela, @sextonkennedy, @smuzaffar can you please review it and eventually sign/assign? Thanks.

cms-bot commands are listed here

[makortel]

@cms-sw/generators-l2 @cms-sw/xpog-l2 Could you confirm if GenEventInfoProduct and/or LHEEventProduct data products from 10_6_X (Run 2 UL) AODSIM need to be readable in master for future MiniAOD/NanoAOD productions?

The PR test failures in #43405 (comment) occurred in

• workflow 158.01 reading /store/relval/CMSSW_10_3_3/RelValHydjetQ_B12_5020GeV_2018_ppReco/GEN-SIM-RECO/PU_103X_upgrade2018_realistic_HI_v11-v1/10000/49F1E805-73F9-AC4C-8E16-27019EE440FC.root
• pat1 test reading /store/relval/CMSSW_9_2_2/RelValProdTTbar_13/AODSIM/91X_mcRun2_asymptotic_v3-v1/10000/EEB99F74-DA4D-E711-A41C-0025905A48F2.root

[makortel]

type root

[vlimant]

extremely likely, until we do a full Run2 reprocessing and MC (reconstruction from RAW); i.e not any time soon

[makortel]

Thanks @vlimant, this is pretty much what I would have guessed (but wanted to make sure).

[makortel]

@pcanal We would need an ability to read an old file, and evolve std::auto_ptr<T> (for one specific T=gen::PdfInfo) into something that we can further evolve into std::unique_ptr<T> (or directly to unique_ptr), in some way that avoids explicit use of std::auto_ptr<T> (since it has been removed from the standard, even if libstdc++ still seems to provide the implementation out of the box).

[pcanal]

For better (or worse, but better in this case), the read rule does not check the type listed in the rules against the incoming class, so all you need is:

namespace Compatibility {
template <typename T>
struct auto_ptr_is_deprecated
{
   ~auto_ptr_is_deprecated() { delete _M_ptr; }
   void release() { _M_ptr = nulltptr; }
   T * get() { return _M_ptr; }
   
   T *_M_ptr = nullptr;
};
} // Compatibility

and

 <ioread sourceClass = "GenEventInfoProduct" version="[11]" targetClass="GenEventInfoProduct" source = "Compatibility::auto_ptr<gen::PdfInfo> pdf_;" target="pdf_">
   <![CDATA[pdf_.reset(onfile.pdf_.get()); onfile.pdf_.release();]]>
 </ioread>

With this style, you need to make 100% sure that the layout of auto_ptr_is_deprecated is exactly the same as the layout implied by the TStreamerInfo for auto_ptr that is stored in the file being read.

Alternatively you can have a class name ::auto_ptr for which you generate a dictionary. In that case the layout does not have to be strictly the same.

[makortel]

Thanks @pcanal.

With this style, you need to make 100% sure that the layout of auto_ptr_is_deprecated is exactly the same as the layout implied by the TStreamerInfo for auto_ptr that is stored in the file being read.

What would happen if the layout would not be exactly the same? Would we get an error, or would data be misinterpreted silently?

[pcanal]

Unfortunately the data would be (possibly) interpreted incorrectly .. silently (i.e. The memory will be allocated and set as described by the TStreamerInfo and for all for intents and purposes reinterpret_cast ed to the stated type.