Did you know that IP addresses (IPv4) can be written in shorter representations?

Did you know that IPv4 addresses can be written in shorter representations, like IPv6 addresses?

Everyone have seen form of IPv6 represented as “shorter form”:
Example from IPv6:

  • 2001::7334
  • ::1
  • ::

You can use our free tool ipv6-literal.com to convert these addresses to long form. The result is:

  • 2001:0000:0000:0000:0000:0000:0000:7334
  • 0000:0000:0000:0000:0000:0000:0000:0001
  • 0000:0000:0000:0000:0000:0000:0000:0000

What admins / programmers usually do not know, is that the same principle applies to IPv4 addresses:

  • 127.1
  • 1
  • 192.168.257
  • 192.168.65535
  • 192.168.65535
  • 192.168
  • 10.1

To test these, use built in ping command. I used ping in Windows 7 and Ubuntu 10, and the result addresses are:

  • 127.1 -> 127.0.0.1
  • 1 -> 0.0.0.1
  • 192.168.257 -> 192.168.1.1
  • 192.168.65535 -> 192.168.255.255
  • 192.168 -> 192.0.0.168
  • 10.1 -> 10.0.0.1

As a bonus, you can try to ping other IP address representations:

  • ping 0x7F000001 – hex
  • ping 010 – octal, does not work in Ubuntu
  • ping 2130706433 – decimal

Why it works this way? Because network funcions built into OS support a such behavior, for example:

Have a fun, and remember, that year of IPv6 is near.

C# / .NET MessageBox is hidden behind the Form

Imagine calling the following C# code:MessageBox.Show(this, "Some text...", "Title", MessageBoxButtons.OKCancel);

After executing this line, the Message Box is not visible, it seems like hidden behind your form, without input focus, mouse clicks cause default beeps, and it suddenly appears if you click Alt or F10 key.

It turns out I had a custom drawing routine for one of the form’s controls (OwnerDraw / OnPaint), and I was changing the property that was causing the redraw cycle. Make sure, that in your OnPaint / DrawItem / DrawSubitem / etc. you are not invalidating your Control.

Also, if you are using .NET ListView control, it has a bug.

Because of a bug in the underlying Win32 control, the DrawItem event occurs without accompanying DrawSubItem events once per row in the details view when the mouse pointer moves over the row, causing anything painted in a DrawSubItem event handler to be overpainted by a custom background drawn in a DrawItem event handler. See the example in the OwnerDraw reference topic for a workaround that invalidates each row when the extra event occurs. An alternative workaround is to put all your custom drawing code in a DrawSubItem event handler and paint the background for the entire item (including subitems) only when the DrawListViewSubItemEventArgs.ColumnIndex value is 0.

http://msdn.microsoft.com/en-us/library/system.windows.forms.listview.drawitem%28v=vs.80%29.aspx

This is not limited to MessageBox using C# / .NET framework. This also happens very often, with Win32 & WinAPI, with a Form class, etc.:

String.format in Java has weird rounding by default

I was participating in one of our Android projects, and while testing I discovered, that our program acted weird — app displayed one value, but acted like the value was different. The value was 1.45, and our Java Android app displayed 1.4 instead of 1.5.

The source looked something like:
double d = 1.45;
String val = String.format(Locale.US, "%.1f", d) + "%";

I am still a beginner in Java, and at first I believed, that String.format rounds down by default. This was till I saw, that value 1.55 is rounded up by default.

Digging into Java documentation I found, that String.format uses RoundingMode HALF_EVEN by default:

Rounding mode to round towards the “nearest neighbor” unless both neighbors are equidistant, in which case, round towards the even neighbor. Behaves as for RoundingMode.HALF_UP if the digit to the left of the discarded fraction is odd; behaves as for RoundingMode.HALF_DOWN if it’s even. Note that this is the rounding mode that statistically minimizes cumulative error when applied repeatedly over a sequence of calculations. It is sometimes known as “Banker’s rounding,” and is chiefly used in the USA. This rounding mode is analogous to the rounding policy used for float and double arithmetic in Java.

http://docs.oracle.com/javase/6/docs/api/java/math/RoundingMode.html

Of course other beginners are also discovering this Java Rounding.

Unfortunately Android does not support setRoundingMode, so currently using the following workaround:
double d = (double)Math.round(((double)percents) * 10f) / 10f;
String val = String.format(Locale.US, "%.1f", d) + "%";