SysAdmin Solves Perl Mystery
The developers came. “We have a mystery wrapped inside an enigma?”
I told them if it was further wrapped in bacon, they had my interest.
Perl:
my $foo = sprintf("sseq_%012d_%012d",2153059002,2153059068);
print STDERR "$foo\n";
On some computers, this was printing:
sseq_002153059002_002153059068
On some older servers:
sseq_-02141908294_-02141908228
“That looks like an integer overflow,” I said, as a friend called me. I stepped out of the office, and when I returned, I checked man 3 printf and “fixed” the code:
my $foo = sprintf("sseq_%012u_%012u",2153059002,2153059068);
print STDERR "$foo\n";
As the code would only ever be printing positive integers anyway, the developers were satisfied with my workaround.
And impressed with my knowledge.
This is one of those things I learned by paying a little attention in CS classes. Normally Perl hides the details of integer field sizes from the developer, but provides C functions for handy stuff like print formatting. And in this case Perl was naively passing a 32-bit integer that had overflowed the first 31 bits (this happens a bit past 2,000,000,000) . . . this is probably a bug that was corrected in later versions of Perl.
Some day, I may have a job interview, or some other person ask me a time when I solved a really weird bug, or perhaps someone will want to know of an occasion where my CS minor proved useful, and I can check my web site to help me recall the answer.
So, why did they ask the SysAdmin? Because different machines, under my control, were giving different answers. They were running different versions of Perl, of course, but it is very helpful to be able to hypothesize why the different versions are behaving differently.
