Re: length() returns wrong result

in reply to length() returns wrong result - suspicious magic

Looks like a there's a call to SvSETMAGIC missing in DBI or DBD::ODBC. Just to confirm, does the following cause length to return the correct length?

$txt=$txt;
[download]

By the way, using constant SQL_WCHAR would be clearer than using -8.

Comment on Re: length() returns wrong result - suspicious magic Select or Download Code

Replies are listed 'Best First'.
Re^2: length() returns wrong result - suspicious magic by mje (Curate) on Sep 15, 2010 at 14:53 UTC
I though DBI was missing a def for SQL_WCHAR but it turns out it is there. The code started out as code someone submitted to me to look into another issue so I've only modified some parts of it. Setting $txt = $txt at the end of the loop makes no difference but setting $txt='' fixes it. If this confirms your suspicion could you explain why DBD::ODBC (which wrote to the scalar) might need to call SvSETMAGIC?	[reply]
Re^3: length() returns wrong result - suspicious magic by ikegami (Patriarch) on Sep 15, 2010 at 15:35 UTC
why DBD::ODBC (which wrote to the scalar) might need to call SvSETMAGIC? To assign a value to a scalar, there are a few steps to follow. Make sure the scalar has the slot (IV, PV, etc) you need by upgrading the structure if necessary. Place the value in the appropriate slot. Set the flag indicating there's a usable value in the slot you populated. Call SvSETMAGIC to let magic respond to the new value if appropriate (if SMG=1). This will end up calling STORE for tied variables, for example. In this case, I expect that it will clear the precomputed length of the string. To obtain a value from a scalar, the same is done in reverse. Call SvGETMAGIC to populate the scalar with the a value. (This will end up calling FETCH for tied variables, for example.) Coerce the scalar into the requested type if necessary. (This may requiring upgrading the scalar). Return the value in the appropriate slot. Some macros and functions do more than one of these steps for you. Setting $txt = $txt at the end of the loop makes no difference No, at the start of the loop. After the fetch, but before you use it. There's no get magic on the scalar (GMG=0), so the fact that the set magic wasn't called earlier work won't matter. But when the value is assigned back to the scalar, the assignment will properly handle the set magic. If I'm right, I can provide a cheaper workaround than copying the string (which defies the purpose of binding).	[reply]
Re^3: length() returns wrong result - suspicious magic by ikegami (Patriarch) on Sep 15, 2010 at 15:10 UTC
No, at the start of the loop. After the fetch, but before you use it.	[reply]
Re^4: length() returns wrong result - suspicious magic by mje (Curate) on Sep 15, 2010 at 15:25 UTC
`while ( $sth_sel->fetch ) { $txt = $txt; printf "%3u %3u %3u %s [%s] [%s]\n", ++$i, length($txt), bytes::length($txt), (utf8::is_utf8($txt) ? ' utf8' : '!utf8'), $txt, $xml; }` [download] made no difference.	[reply] [d/l]
Re^5: length() returns wrong result - suspicious magic by ikegami (Patriarch) on Sep 15, 2010 at 16:19 UTC
Re^6: length() returns wrong result - suspicious magic by mje (Curate) on Sep 15, 2010 at 16:35 UTC
Re^5: length() returns wrong result - suspicious magic by ikegami (Patriarch) on Sep 15, 2010 at 15:37 UTC

In Section Seekers of Perl Wisdom