Re: Bug in Long.toOctalString

[Tom Tromey]

>>>>> "Eric" == Eric Blake <address@hidden> writes:

Eric> Yet another bug in the wrapper classes.

Can you sign paperwork so we can get you direct write access?

Eric> Plus, the previous commit didn't update the (c) date for
Eric> Byte.java.

I use a small piece of Emacs code to remind me to do this.  I can send
it to anybody who wants it.

Eric> The code in Classpath does not seem to follow any consistent
Eric> standards.  Are .java files supposed to follow Sun's
Eric> recommendation (hanging open braces) or GNU convention (open
Eric> braces on new line)?

I don't think there is actually a rule in Classpath.

However, in libgcj we use the GNU style.  And, as we've been merging
code with Classpath we've been slowly reindenting Classpath to this
standard.  So this is what I recommend you use.

Eric> When there is enough indentation, should I use TABs or 8 spaces?

I don't think tabs-vs-spaces matters.  Use whichever is most
convenient for you (or your editor).

Eric> And different files in java.lang disagree whether indentation is
Eric> 2, 4, or 8 spaces; but both Sun and GNU recommend 4.

Actually, GNU uses 2 spaces for the brace and then another two for the
code.  This matters if there is no brace.  For instance here are two
examples from libgcj:

    if (num <= Integer.MAX_VALUE && num >= Integer.MIN_VALUE)
      return Integer.toString((int) num);

    do
      {
        buffer[--i] = Character.forDigit((int) (num & mask), radix);
        num = num >>> exp;
      }
    while (num != 0);

In libgcj we line up the opening brace of a method with the
indentation of the type (no extra two spaces here):

  private static String toUnsignedString(long num, int exp)
  {
    ...
  }

We chose this style since we were all long-time GNU hackers and it had
a very familiar feel.  In particular the exception for method braces
is reminiscent of the special case in the GNU standards for C
functions (in C they want the opening brace for a function to be in
column 0).

Tom