2011 Nov 16, 12:19
“It’s not that common to find a signed copy of malware. It’s even rarer that it’s signed with an official key belonging to a government.”
technical ssl 2011 Nov 15, 11:59
Summary of some of the new C++ features with comments and suggested usage. Not sure I agree with the take on auto.
‘“C++11 feels like a new language.” – Bjarne Stroustrup’
technical c++ programming 2011 Nov 14, 12:37
Draw ShapeCatcher a symbol and ShapeCatcher shows you the characters in Unicode that look similar. Try a smiley face. (via Eric Lawrence)
technical unicode via:ericlaw 2011 Oct 20, 6:52
Wow, FTA: "Given all of this, reporter Charlie Savage of the NY Times filed a Freedom of Information Act request to find out the federal government's interpretation of its own law... and had it
refused. According to the federal government, its own interpretation of the law is classified."
technical 2011 Oct 19, 5:58
The following code works fine. I have a ccomptr named resolvedUri and I want to update its hostname so I do the following:
CreateIUriBuilder(resolvedUri, 0, 0, &builder);
builder->SetHost(host);
builder->CreateUri(0xFFFFFFFF, 0, 0, &resolvedUri);
But the following similar looking code has a bug:
ResolveHost(resolvedUri, &resolvedUri);
The issue is that doing &resolvedUri gets the address of the pointer but also clears out the pointer due to the definition of my smart pointer class:
operator T**()
{
T *ptrValue = mPtrValue;
mPtrValue->Release();
mPtrValue = NULL;
return &ptrValue;
}
In C++ there’s no guarantee about the order in which parameters for a function or method are evaluated. In the case above, &resolvedUri clears out the ccomptr before evaluating
resolvedUri.Get() and so ResolveHostAlias gets a nullptr.
An interesting and related thread on stack overflow on
undefined behavior in C++.
c++ technical bug programming smart-pointer cpp 2011 Oct 19, 2:07
Don't prefix your proprietary URI schemes with "x-". Your company name or label reversed domain name is acceptable though.
technical 2011 Oct 18, 4:52
I haven't been updating my blog recently. But I have three excellent reasons:
2011 Oct 17, 5:58
Essentially anybody can resolve it however they like except for tokens from the about URI special token registry which currently only contains 'blank'.
technical 2011 Sep 19, 12:53Counter intuitive argument for not making the larger fix: "Should we fix them all preemptively, meaning the next time they block us it will be through some more complex mechanism that's harder to
figure out? Or should we leave things as they are, knowing there will be more blocking events but also knowing that we can solve them easily?"
tor censorship government iran technical