If tcl is compiled with the "-ftrapv" option (which adds checks for integer overflow) the string to integer conversion code in tclStrToD.c fails when parsing the most negative 64-bit integer (-9223372036854775808).

This manifests itself in the clock command:

% clock format [clock seconds] -format "%d-%b-%Y"
Process 4807 stopped
* thread #1: tid = 0x4e9b38, 0x000000010009ebcc libtcl8.5.dylib`TclParseNumber(interp=0x0000000000000000, objPtr=<unavailable>, expected=0x00000001000ca82e, bytes=<unavailable>, numBytes=-1, endPtrPtr=0x0000000000000000, flags=<unavailable>) + 5628 at tclStrToD.c:560, queue = 'com.apple.main-thread, stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
    frame #0: 0x000000010009ebcc libtcl8.5.dylib`TclParseNumber(interp=0x0000000000000000, objPtr=<unavailable>, expected=0x00000001000ca82e, bytes=<unavailable>, numBytes=-1, endPtrPtr=0x0000000000000000, flags=<unavailable>) + 5628 at tclStrToD.c:560
   557 		    } else if (flags & TCL_PARSE_OCTAL_ONLY) {
   558 			goto zeroo;
   559 		    } else if (isdigit(UCHAR(c))) {
-> 560 			significandWide = c - '0';
   561 			numSigDigs = 1;
   562 			state = DECIMAL;
   563 			break;

because the clock command at some point gets to here in clock.tcl:

   3596     set r {}
   3597     set lastTime $MINWIDE
   3598     foreach t $times c $codes {
   3599         if { $t < $lastTime } {
   3600             return -code error "$fileName has times out of order"
   3601         }
   3602         set lastTime $t

The crash happens in line 3599 when $t is compared with $MINWIDE. This code doesn't look quite right to me as $t can never be less than $lastTime the first time through as $lastTime is the most negative number. Shouldn't lastTime be initialized with the first time in the list? Or given that lastTime is presumably seconds the arbitrary choice of $MINWIDE to seed it could be somewhat different?

I'm not sure whether the bug is in tclStrToD (because it deliberately overflows and -ftrapv should never be used) but there surely does seem to be a bug in clock.tcl as well.

For reference this also fails:

% set last -9223372036854775808
-9223372036854775808
% incr last
Illegal instruction: 4

This is on OS X Mavericks with clang but colleagues report a similar problem on linux with gcc.

Apologies if this is a duplicate as I've had trouble finding how to search the ticket database.