David Heffernan

Why aren't you debugging? That's what I would do if faced with this problem.

You've had my suggestion. Use a boolean and give your function a good name. Where you can't do that, use an enumerated type. You seem to be looking for problems where none exist. These kind of problems don't need to be fixed!

A truly shockingly bad one at that!

Should have been titled "In Which I Argue that Embarcadero Should Write Their Unit Tests".

Then you'll need to do some debugging. Only you can do that.

Use the debugger to trace through. Also look in the revision control system to see what has changed.

You really think that an enumerated by, with a meaningful name, carries more information than: FindFiles('c:\', True); I think you are in a large minority if that is your view.

That's not what I am saying. I'm saying that if an attacker gets as far as running code on your machine, then things like reading another process's memory are moot. Once the attacker is executing their code on your system, it's over.

If you've managed to be able to execute code on the target's machine, it's already game over. Bulleting passwords is only ever intended to stop over the shoulder password theft. See point 1. No matter since points 1 and 2 are invalid.

In this case the lock is needless (with interlocked reference counting). The interesting case has to be where G is modified. But the reference counting is interlocked, and I'm sure it's there for a reason, and I'm sure that I've forgotten what that reason is.

In this case, you don't need interlocked operations on the ref count.

Stepping back here, are piecemeal comments from numerous different authors in a forum the best way to design the security for your software? I'd want to be reading a book written with a train of thought. Covering a variety of issues, with explanation of why they matter. And a book that has been well reviewed. It seems to me that standalone tips are the kind of thing that lead to insecure software. Security is an end to end, entire process thing, where the interactions matter. Using a couple parts of best practise doesn't make your software secure. It only needs one part to be missing.

If I were you, I think I'd probably want to know what type of phones these actually were.

Why do you need a phone? Wouldn't it be easier to do it without the phone?

Question is actually about identifying which piece of code is responsible for the lock. Asker already knows which process has it.

Well then they aren't what you say they are.

@avk I am sceptical of your numbers. How can the other algorithms match TimSort for sorted and reverse data?

It's strange then that you don't seem to read what people post. I get a sense sometimes that you ask questions but have already decided what the answer is.

Names mean nothing. You have to understand what people say, and judge it for yourself. Stop following people blindly based on reputation. Try to develop your own critical assessment of what you read.

You weren't following his advice. You misunderstood what he said. I already said this. Did you also misunderstand what I said?

Nick's point is fine. I think you just misunderstood it to mean that you needed to replace all boolean args. Following somebody else's recipe without really grasping the issue won't make your code any better. It will just give you work to do and make it likely that you will introduce bugs to your code? If you don't have comprehensive tests for all of your code then you are in big danger of that.

This makes no sense whatsoever.

There is a well known design flaw with passing arguments to const arguments. procedure Foo(const Bar: IMyInterface); .... Foo(TMyImplementingClass.Create); As we know, Foo won't increment the reference count because Bar is const. Possible issues are the object is leaked, or released early inside Foo (e.g. if something inside takes a reference and then releases it). This should be fixed by having the compiler realise at the call site that something needs to take a reference to the interface while the function is executing, and emitting the necessary code at the call site. I've given up hope that this will ever be fixed. On the other hand, perhaps I should be pleased that Idera consider itself to be one of the hottest companies around.

Use some judgement. You don't need to get rid of all booleans. Code like: SetControlsEnabled(True); SetMenusEnabled(True); SetFeaturesEnabled(True); is perfectly fine. Does it make sense when you read it? Yes, of course it does. What you need to watch out for is code like: EnumerateFrogs(True); Nobody reading that can infer what the argument does.

That's not a problem with the Delphi side of things, that would be a basic design flaw of the library. If the consumer of the library has to call functions that it can't access, in order to use the library, then the library is unusable. You are better off not to speculate and guess like this. If the asker has a question, trust them to ask it.