I've never received this message from Google before, but it was warning me about a malicious website I was about to visit. The search was for some Revolutionary War era person and the site I suspected was a family tree based on the information from Google.
My first through when I saw these warnings was "hey, what does this malicious script look like?" I block cookies and scripts by default, so it was probably pretty safe to go ahead and visit this site. But I also have 16 different operating system installed and setup in VirtualBox, and it really wouldn't matter if one of them ended up with some malicious software. Despite having homework to do, I decided to see what the scripts looked like.
I decided to try this experiment on my latest 64-bit Ubuntu VM, and just to see if my hypothesis about the script blocker was valid, I installed NoScript . Then, it was off to this site. Except Firefox hit me with this:
Seems both Firefox and Google really don't care for this site. Firefox gave me a nice "Ignore this warning" link and so in I went. No script threw up it's little "blocked script" tag like it does on most sites. When I tried to view the source, Firefox hit me again with the warning again, but the link for "ignore this warning" didn't work. This isn't the first time I've encountered this in Firefox.
Since I don't have a SSL certificate from a recognized root authority, anytime someone goes to one of the SSL areas of drque.net they will get a message about an invalid certificate. For the quite awhile, I was unable to use Firefox to get into the SSL areas of drque.net because the "add exception" button didn't do anything.
Nothing that stood out right away. Some code for Google ads, script to get the window size, and finally some script for an ad from "zedo.com". I hadn't herd of these guys before and decided to look into them. Web of Trust ranks them at 25% for "trustworthiness" and "vendor reliability." This is my bad guy.
It is possible the bad guy is inside some shockwave element, but I didn't see any URL for a sockwave file. Even if I did, I wouldn't be able to do much with it. So, my hunt has been rather uneventful.
Safe Browsing claims the root directory of this site had 21 script exploits and 1 Trojan. It listed the malicious software included several Chinese domains, none of which I found in the scripts or HTML I looked at. So, it's possible this page wasn't dangerous, but simply in with a group that were. Fortunecity.com is one of those free web hosts that have been around since the late 90ies and the page I looked at seemed to be one designed around that time—very basic. A lot of these old sites that sit on hosts like Fortunecity are susceptible to attack from script that try and guess passwords. Once they are in, they can change the website and add their own script, which it probably what happened. Unfortunately, nothing I saw was all that exciting.
Still, I really wanted to see if I could get something malicious from this site. For this, I needed the most insecure operating system and browser I could think of. Naturally, I picked an MS operating system and Internet Explorer. In VirtualBox, I saved a snapshot prior to this experiment, then fired up IE and went right to the site. No warnings this time and the page loaded up with ads, scripts and all. The only thing I saw happen was IE tell me it blocked a pop-up ad. How uneventful. I'm going to let this virtual machine run for awhile and see if anything bad happens. So far, it looks like a false-positive.
Many people have written about the problems of using macros in C. In C++, constants and templates should pretty much eliminate the need to use macros. Unless you are seriously pressed for speed, there should be no reason to use macros in C++.
In straight C, the keyword "const" doesn't produce constants that can be used to initialize array sizes.
The most common way I've seen people deal with this is by using macros:
This always works, but it has a few problems. Lets make the statement a little more complex.
How big is the array going to be? If you said 220 elements, you would be wrong--the correct answer is 120. This is due to the nature of macros. They are pre-processor substitutions and are not evaluated. What really happens is the following code is generated:
Now remember your operator precedence--10*2 will happen before adding 100, so the size of the array is 100 + ( 10 * 2 ) = 120.
Most programmers know to use parenthesis around everything defined in a macro.
This will produce the 220 elements desired. However, I learned a trick at my previous contract job that can avoid this whole scenario. Instead of using macro, use an entry from an enumeration. ANSI C says that a value in an enum is always treated as an constant int. enum values can be assigned to integer values and enums can be anonymous. So this syntax is valid:
Note we don't need to use parenthesis (although it wouldn't hurt) like we need to with a macro. enums are not pre-processor substitution and are evaluated at compile time. They are, in many respects, a C version of C++ const.
I use the anonymous enum constant instead of macros when ever I can. They always work for array sizes and work for most constants. However, there are some places they may not do the job. enums are always of type "int". If you need a floating-point constant, you'll be stuck with either a macro or a "const". And the int size can be different on different machines. This can really be an issue if you are making masks. For example:
This will create problems on a 16-bit compiler where the int size is 2-bytes. For such cases, you can still use "const".
The drawback is that in standard C, const values are required to take up storage space. So in this example:
Even if PI is never referenced in the source code again, it still has storage allocated. Where as:
Will never result in unused storage. In most cases, we're talking about a few bytes. If you are using a constant value for something other then array initialization, having storage allocated can actually produce smaller code. Rather then loading to a constant value every time the value is used, the code can load from a location in memory. Again, we're talking savings in the bytes. So unless you are an embedded programmer with a really tight ROM/RAM budget, it's hardly worth worrying about.
In C++, the rules for const change. Storage for a "const" object isn't necessarily allocated. So in our previous example with PI and _2_PI, the compiler is free to discard PI if it isn't used anywhere else. In addition, const values can be used to initialize arrays.
The compiler is free to discard storage for ARRAY_SIZE. In most cases, C++ const will do anything we had to do with enum values. And in most cases, the value will be used directly rather then loading from a memory location--although this may depend on your compiler.
The above loop might need to happen in some time-critical location. Assuming the compiler has no optimization, it would be preferable that MASK were evaluated as an intermediate and not stored at some memory location. Otherwise time is wasted loading the value from the memory location. However, even the most basic optimization will take care of this problem.
I was watching the movie Van Wilder and during one part they start a tutoring business. The first display of this tutoring taking place, one guy, concentrating hard, says “x... equals... six”. The geek in me wondered what the equation was the guy was solving. It is only display for about a quarter of a second, but I freeze framed it and had a look. Here's the frame:
It is written a little messy, but this appears to be the equation.
First of all, it's wrong. The integral actually comes out out be
For fun, let's assume this is a question, not a incorrectly solved integral. When would the two sides of the equation be equal? For this case, we have to drop the “C” constant. Solve for the integral and we get this:
Even for this, there is no answer. Has a vertical asymptote at x = 1. , and is undefined for all x > 1
has a vertical asymptote at x = 1 as well, but in the other direction: . Thus, there is no value for x in which the two equation meet. So as for x = 6? It just doesn't happen with the equation given. Yep—I really did just check the math of a comedy.