Mailing List Archive: Freak TeX hash error

Freak TeX hash error

Jan 15, 2003, 1:40 AM

Post #1 of 4 (473 views)

On http://www.wikipedia.org/wiki/Feigenbaum_constant I see:

Warning: pack type H: not enough input, need 16, have 15 in
/usr/local/apache/htdocs/w/OutputPage.php on line 72

The line is:
$outputhash = unpack ("H32md5", $rpage->math_outputhash);

It's triggered by this tex fragment:

<math>\delta = 4.6692\cdots</math>

Inserting it into Wikipedia:Sandbox gives the same error there. On
submit it becomes all-encompassing; on page view it just hides behind
the regular text.

Adding a space to alter the input hash, or clearing it from the math
table causes the next load (with render) to work fine; on reload, the
error comes up.

Changing \delta to \alpha makes it play nice.

-- brion vibber (brion @ pobox.com)

Re: Freak TeX hash error [ In reply to ]

taw at users

Jan 15, 2003, 7:07 AM

Post #2 of 4 (472 views)

Permalink

On Wed, Jan 15, 2003 at 12:40:57AM -0800, Brion Vibber wrote:
> On http://www.wikipedia.org/wiki/Feigenbaum_constant I see:
>
> Warning: pack type H: not enough input, need 16, have 15 in
> /usr/local/apache/htdocs/w/OutputPage.php on line 72
>
> The line is:
> $outputhash = unpack ("H32md5", $rpage->math_outputhash);
>
> It's triggered by this tex fragment:
>
> <math>\delta = 4.6692\cdots</math>
>
> Inserting it into Wikipedia:Sandbox gives the same error there. On
> submit it becomes all-encompassing; on page view it just hides behind
> the regular text.
>
> Adding a space to alter the input hash, or clearing it from the math
> table causes the next load (with render) to work fine; on reload, the
> error comes up.
>
> Changing \delta to \alpha makes it play nice.

It seems it's MySQL who's not playing nice. Last byte of hash of such
expression is 20 and MySQL probably thinks that as it's a space it doesn't
have to be transferer to us, and so it transfer only first 15 bytes.

`char(16) NOT NULL' seems to behave that way.
Is there some data type that doesn't behave that way or should we
keep adding spaces to $rpage->math_outputhash until it is 16 bytes long ?

Re: Freak TeX hash error [ In reply to ]

brion at pobox

Jan 15, 2003, 1:46 PM

Post #3 of 4 (467 views)

Permalink

On mer, 2003-01-15 at 06:07, Tomasz Wegrzanowski wrote:
> It seems it's MySQL who's not playing nice. Last byte of hash of such
> expression is 20 and MySQL probably thinks that as it's a space it doesn't
> have to be transferer to us, and so it transfer only first 15 bytes.
>
> `char(16) NOT NULL' seems to behave that way.
> Is there some data type that doesn't behave that way or should we
> keep adding spaces to $rpage->math_outputhash until it is 16 bytes long ?

Yeah, that would do it. CHAR columns aren't binary-safe; they're
internally padded with spaces at the end and trailing spaces are
stripped on read. Perhaps VARCHAR(16) BINARY?

-- brion vibber (brion @ pobox.com)

Re: Freak TeX hash error [ In reply to ]

taw at users

Jan 15, 2003, 2:31 PM

Post #4 of 4 (471 views)

Permalink

On Wed, Jan 15, 2003 at 12:46:40PM -0800, Brion Vibber wrote:
> On mer, 2003-01-15 at 06:07, Tomasz Wegrzanowski wrote:
> > It seems it's MySQL who's not playing nice. Last byte of hash of such
> > expression is 20 and MySQL probably thinks that as it's a space it doesn't
> > have to be transferer to us, and so it transfer only first 15 bytes.
> >
> > `char(16) NOT NULL' seems to behave that way.
> > Is there some data type that doesn't behave that way or should we
> > keep adding spaces to $rpage->math_outputhash until it is 16 bytes long ?
>
> Yeah, that would do it. CHAR columns aren't binary-safe; they're
> internally padded with spaces at the end and trailing spaces are
> stripped on read. Perhaps VARCHAR(16) BINARY?

It's not variable size - it's always 128 bit.
What is usually used to store MD5s in MySQL ?

Would CHAR(16) BINARY NOT NULL work ?

Mailing List Archive

Mailing List Archive

Attached Files: