Hi Andy > > > My personal opinion is a bit different. I'm rather safe than sorry. I think > > we should first aim to get this working in all cases before trying to > > optimise. > > > > In any case, the current code is already faulty for those elements for which > > VM>1, i.e. which have multiple numbers. It is of course possible to rewrite > > those with memcpy as well, but we'd first need to allocate sufficient > memory > > etc. That'll get somewhat painful. > > That is convincing. Please go ahead and commit it. If it is dire, we > can always revert. >
Done. > I thought I had tested it for VM>1, but I can't recall. I can't see anything in the (now previous version of the) code testing for the size etc. I might now have a look at the sequences. Can you summarize the situation there? Kris PS: By the way, I've also committed a tiny fix to dicomdict.cpp that makes it compile and run outside of octave (for debugging only) ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
