David Heffernan

In for i := 0 to List.Count - 1 do Foo(I); List.Count is evaluated exactly once.

Websearch took me here https://en.m.wikipedia.org/wiki/Static_application_security_testing https://docs.gitlab.com/ee/user/application_security/sast/ https://github.blog/changelog/2020-05-06-github-advanced-security-code-scanning-now-available-in-limited-public-beta/

That's exactly the sort of analysis that you should be doing rather than blanket use of direct access of the internals.

I think OP's takeaway was to use direct array access always. I'd say use it with specific intent only. I'm dead against TList exposing its internal implementation details like that. Anyway, the Delphi collection classes have been such a mess over the years with so many bugs I gave up on them a long time ago and use my own collection library. If you can't do that then it's hard to see past spring's collections.

Which is why accessing via Items is to be preferred unless there are very well understood extenuating circumstances, for instance, measurable and significant performance gains. But in such a case I'd probably look to use a different collection.

Your interposer is effectively useless. When you call CardPanel.AddNewCard an instance of Vcl.WinXPanels.TCard is returned. No amount of casting can change that. You are just telling a big fat lie to the compiler. If you use as to cast then you will find out the runtime truth. They issue here is that you are trying to change the instantiated type of the cards. But declaring a new type of card doesn't achieve that since that code lives in the panel class. It's therefore the behaviour of the panel class that you need to modify. In order to get your card types created you should override GetCardClass. http://docwiki.embarcadero.com/Libraries/Sydney/en/Vcl.WinXPanels.TCustomCardPanel.GetCardClass You could do that with an interposer for TCardPanel. However, I wonder if perhaps the right thing to do is to stop using GUI controls to store data. GUI controls present data. They should not have knowledge of that data. Code outside of the control should be in charge of that.

Er, I mean the compiler option. You just switch it on and it finds defects in your code.

Nobody ever sets out to access out of bounds. But it happens. It doesn't happen because you decided to have a go at accessing out of bounds in case you get away with it. It happens because it's a mistake. The point of range checking is to detect those programming errors before the user is exposed to them. Presumably you use range checking?

Probably a bad idea. I would only do this in specific instances where you have timed your program and identified a bottleneck.

Wrong. The answer to my question is yes. SubItems: TList<TSubItem> When you access the items, a function getter is called, and that's where the copy comes from. That function getter has to assign its result somewhere and the compiler makes a temporary local variable for it. Hence the record init etc. Access the array directly and there will be no copy. aItem.SubItems.List[i] The const arg works as you expect.

Does aItem.SubItems[i] access an array directly, or is it a property getter with a function for the getter. The latter means a copy and would explain the behaviour. And if so nothing to do with the const arg.

It kinda makes no sense then that you also say that the data is ASCII (0..127). I'm very confused.

Just so long as VS Code doesn't auto uninstall every fortnight like it does with me......

At the start of this thread you said that the data was binary. Now you say it is ASCII. Hard to give advice on this basis.

Would be perverse to use 16 bit Char to store 8 bit data. In terms of performance byte strings and byte arrays are similar but if anything byte arrays will be faster. Precisely because they don't have coy on write. No idea why you thing strings perform better. My guess is that your antipathy to byte arrays is a hangover from the legacy Delphi anti pattern that byte arrays are handled as strings.

Flashing can be quite visually aggressive. It is often preferable to highlight a control in some other way.

In the long run it will be less efficient to continue using these bridges.

I can't understand why you would. Aren't you likely just to end up changing your code for no reason, given that the defect is almost certainly not in your compression library?

It's pretty bad advice. Changing algorithm and implementation without any justification or rationale. Seems like you are advocating trying libraries at random. If every time you encounter an issue you replace the lirbsry, after a while you'll have run out of libraries.

They are. That's the a very plausible explanation. File corruption is something that does happen. You'll want to reproduce the issue before trying to solve the problem. And if it is file corruption then the solution is somebody else's problem.

How did you diagnose that the defect was in ZCompressStream or ZCompressStream?

As usual the most simple explanation was the answer. If a string variable is empty then the obvious explanation is that you either assigned it to be empty, or didn't assign it at all.

Kind of odd that you wouldn't just use a byte, TBytes.

Make a minimal reproduction. FastMM reports leaks only in the delphi heap. madExcept reports those leaks and also leaks in many other system resources.

Websearch took me here https://delphi.fandom.com/wiki/Delphi_Release_Dates