[Bug testsuite/29737] make check fixinclude test FAILURES

[tjk at tksoft dot com]

--- Comment #4 from tjk at tksoft dot com  2007-07-25 21:24 ---
I got the same problem using sed 3.02 to build. Upgrading to sed 4.1.5
fixed the problem.

The fixincl program runs sed scripts for glibc pthread checks which fail on sed
3.02, but succeed on sed 4.1.5.

What happens is that pthread.h doesn't get created in the
"fixincludes/tests/res" directory because sed fails.

My version is gcc 4.2.1 with host i486-pc-linux-gnu.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29737

[Bug java/32904] New: Typo in Base64.java's decode function

[tjk at tksoft dot com]

There is a typo in libjava/classpath/gnu/java/security/util/Base64.java's
decode function.
public static byte[] decode(final byte[] src, final int off, final int len)
{... }

The following loop ends up throwing an exception on correct input.
A "continue" line is missing, as shown below.
When the continue line is added, the function works correctly.

for (i = off; i < off + len; i++)
  {
sbiCrop = (byte) (src[i] & 0x7F); // Only the low seven bits
sbiDecode = DECODABET[sbiCrop];
if (sbiDecode >= WHITE_SPACE_ENC)
  { // White space, Equals sign or better
if (sbiDecode >= EQUALS_SIGN_ENC)
  {
b4[b4Posn++] = sbiCrop;
if (b4Posn > 3)
  {
outBuffPosn += decode4to3(b4, 0, outBuff, outBuffPosn);
b4Posn = 0;
// If that was the equals sign, break out of 'for' loop
if (sbiCrop == EQUALS_SIGN)
  break;
  } // end if: quartet built
  } // end if: equals sign or better
// ERROR HERE: The following line is missing.
// continue;
  }
throw new IllegalArgumentException("Illegal BASE-64 character at #"
   + i + ": " + src[i] + "(decimal)");
  }


-- 
   Summary: Typo in Base64.java's decode function
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
        AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tjk at tksoft dot com
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32904

[Bug ada/70015] New: Finalizer not called depending on declaration order

[tjk at tksoft dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70015

Bug ID: 70015
   Summary: Finalizer not called depending on declaration order
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tjk at tksoft dot com
  Target Milestone: ---

Created attachment 37823
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37823&action=edit
Example 1 where Finalizer call gets omitted

Call to the Finalizer for an object doesn't get called, or gets called twice,
unless declarations are placed in a specific order.

I wrote five versions of the same code, with two versions producing the bug;
two are workarounds which make the code useless, and the fifth example actually
makes the code work as it should.

The behavior is unpredictable and violates the expected behavior of a
controlled type, so this should probably be classified as a rather serious
issue.

The original code is for a parser, and written in a pretty predictable way, so
I wouldn't be surprised if there was other code out there where this bug just
hasn't been noticed. A missing Finalizer call will only be noticed if the
controlled resource misbehaves because of a lacking call to the finalizer.  

Complete list of examples:
http://tksoft.com/people/troy/ada/dtor_examples/

[Bug ada/70015] Finalizer not called depending on declaration order

[tjk at tksoft dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70015

Troy Korjuslommi  changed:

   What|Removed |Added

URL||http://tksoft.com/people/tr
   ||oy/ada/dtor_examples/

--- Comment #1 from Troy Korjuslommi  ---
Platform is x86_64 GNU/Linux.