You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Eric Howe <er...@pieinsky.ca> on 2010/01/19 06:53:47 UTC
Re: [KinoSearch] 64-bit linux errors with t/core/032-string_helper.t
On 2010-01-18, at 21:05 , Marvin Humphrey wrote:
[...]
> It seems messed up that an unsigned type gets promoted to a negative signed
> type when used as an array subscript. You're not supposed to use "char" on
> its own as an array subscript, because whether "char" is signed or unsigned is
> implementation defined, but either "signed char" or "unsigned char" are
> allowed.
Arrays in C are just convenient notation for pointer arithmetic so array indices in C are not char, nor are they signed char nor unsigned char, they're probably int. Are you getting tripped up by an implicit "a[(int)i]" cast on the index?
Just a wild guess.
Eric Howe
eric@pieinsky.ca
Re: 64-bit linux errors with t/core/032-string_helper.t
Posted by Peter Karman <pe...@peknet.com>.
Marvin Humphrey wrote on 01/19/2010 01:35 PM:
> I think the next step is to isolate the behavior of this platform in a minimal
> test app.
Here's another one.
#include <stdio.h>
typedef unsigned char u8_t;
const u8_t StrHelp_UTF8_SKIP[] = {
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,4,4,4,4,4,4,4,4,5,5,5,5,6,6,7,7
};
const u8_t StrHelp_UTF8_TRAILING[] = {
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,
7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,
7,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,3,3,3,3,3,7,7,7,7,7,7,7,7,7,7,7
};
int main() {
u8_t i, max;
for (i=127, max=255; i<max; i++) {
printf("[%d] TRAILING[%d] SKIP[%d]\n",
i, StrHelp_UTF8_TRAILING[i], StrHelp_UTF8_SKIP[i]);
}
}
// eof
output:
[127] TRAILING[0] SKIP[1]
[128] TRAILING[7] SKIP[1]
[129] TRAILING[7] SKIP[1]
[130] TRAILING[7] SKIP[1]
[131] TRAILING[7] SKIP[1]
[132] TRAILING[7] SKIP[1]
[133] TRAILING[7] SKIP[1]
[134] TRAILING[7] SKIP[1]
[135] TRAILING[7] SKIP[1]
[136] TRAILING[7] SKIP[1]
[137] TRAILING[7] SKIP[1]
[138] TRAILING[7] SKIP[1]
[139] TRAILING[7] SKIP[1]
[140] TRAILING[7] SKIP[1]
[141] TRAILING[7] SKIP[1]
[142] TRAILING[7] SKIP[1]
[143] TRAILING[7] SKIP[1]
[144] TRAILING[7] SKIP[1]
[145] TRAILING[7] SKIP[1]
[146] TRAILING[7] SKIP[1]
[147] TRAILING[7] SKIP[1]
[148] TRAILING[7] SKIP[1]
[149] TRAILING[7] SKIP[1]
[150] TRAILING[7] SKIP[1]
[151] TRAILING[7] SKIP[1]
[152] TRAILING[7] SKIP[1]
[153] TRAILING[7] SKIP[1]
[154] TRAILING[7] SKIP[1]
[155] TRAILING[7] SKIP[1]
[156] TRAILING[7] SKIP[1]
[157] TRAILING[7] SKIP[1]
[158] TRAILING[7] SKIP[1]
[159] TRAILING[7] SKIP[1]
[160] TRAILING[7] SKIP[1]
[161] TRAILING[7] SKIP[1]
[162] TRAILING[7] SKIP[1]
[163] TRAILING[7] SKIP[1]
[164] TRAILING[7] SKIP[1]
[165] TRAILING[7] SKIP[1]
[166] TRAILING[7] SKIP[1]
[167] TRAILING[7] SKIP[1]
[168] TRAILING[7] SKIP[1]
[169] TRAILING[7] SKIP[1]
[170] TRAILING[7] SKIP[1]
[171] TRAILING[7] SKIP[1]
[172] TRAILING[7] SKIP[1]
[173] TRAILING[7] SKIP[1]
[174] TRAILING[7] SKIP[1]
[175] TRAILING[7] SKIP[1]
[176] TRAILING[7] SKIP[1]
[177] TRAILING[7] SKIP[1]
[178] TRAILING[7] SKIP[1]
[179] TRAILING[7] SKIP[1]
[180] TRAILING[7] SKIP[1]
[181] TRAILING[7] SKIP[1]
[182] TRAILING[7] SKIP[1]
[183] TRAILING[7] SKIP[1]
[184] TRAILING[7] SKIP[1]
[185] TRAILING[7] SKIP[1]
[186] TRAILING[7] SKIP[1]
[187] TRAILING[7] SKIP[1]
[188] TRAILING[7] SKIP[1]
[189] TRAILING[7] SKIP[1]
[190] TRAILING[7] SKIP[1]
[191] TRAILING[7] SKIP[1]
[192] TRAILING[7] SKIP[1]
[193] TRAILING[1] SKIP[2]
[194] TRAILING[1] SKIP[2]
[195] TRAILING[1] SKIP[2]
[196] TRAILING[1] SKIP[2]
[197] TRAILING[1] SKIP[2]
[198] TRAILING[1] SKIP[2]
[199] TRAILING[1] SKIP[2]
[200] TRAILING[1] SKIP[2]
[201] TRAILING[1] SKIP[2]
[202] TRAILING[1] SKIP[2]
[203] TRAILING[1] SKIP[2]
[204] TRAILING[1] SKIP[2]
[205] TRAILING[1] SKIP[2]
[206] TRAILING[1] SKIP[2]
[207] TRAILING[1] SKIP[2]
[208] TRAILING[1] SKIP[2]
[209] TRAILING[1] SKIP[2]
[210] TRAILING[1] SKIP[2]
[211] TRAILING[1] SKIP[2]
[212] TRAILING[1] SKIP[2]
[213] TRAILING[1] SKIP[2]
[214] TRAILING[1] SKIP[2]
[215] TRAILING[1] SKIP[2]
[216] TRAILING[1] SKIP[2]
[217] TRAILING[1] SKIP[2]
[218] TRAILING[1] SKIP[2]
[219] TRAILING[1] SKIP[2]
[220] TRAILING[1] SKIP[2]
[221] TRAILING[1] SKIP[2]
[222] TRAILING[1] SKIP[2]
[223] TRAILING[1] SKIP[2]
[224] TRAILING[2] SKIP[3]
[225] TRAILING[2] SKIP[3]
[226] TRAILING[2] SKIP[3]
[227] TRAILING[2] SKIP[3]
[228] TRAILING[2] SKIP[3]
[229] TRAILING[2] SKIP[3]
[230] TRAILING[2] SKIP[3]
[231] TRAILING[2] SKIP[3]
[232] TRAILING[2] SKIP[3]
[233] TRAILING[2] SKIP[3]
[234] TRAILING[2] SKIP[3]
[235] TRAILING[2] SKIP[3]
[236] TRAILING[2] SKIP[3]
[237] TRAILING[2] SKIP[3]
[238] TRAILING[2] SKIP[3]
[239] TRAILING[2] SKIP[3]
[240] TRAILING[3] SKIP[4]
[241] TRAILING[3] SKIP[4]
[242] TRAILING[3] SKIP[4]
[243] TRAILING[3] SKIP[4]
[244] TRAILING[3] SKIP[4]
[245] TRAILING[7] SKIP[4]
[246] TRAILING[7] SKIP[4]
[247] TRAILING[7] SKIP[4]
[248] TRAILING[7] SKIP[5]
[249] TRAILING[7] SKIP[5]
[250] TRAILING[7] SKIP[5]
[251] TRAILING[7] SKIP[5]
[252] TRAILING[7] SKIP[6]
[253] TRAILING[7] SKIP[6]
[254] TRAILING[7] SKIP[7]
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: 64-bit linux errors with t/core/032-string_helper.t
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Wed, Jan 20, 2010 at 12:25:01PM -0600, Peter Karman wrote:
> Marvin Humphrey wrote on 01/20/2010 11:22 AM:
>
> > Do you have valgrind on these boxen? It would be interesting to see valgrind
> > analysis of the small program with and without -02. However, I'm not sure
> > we'll see anything -- Valgrind's ability to detect stack corruption is
> > limited:
>
> http://peknet.com/~karpet/char-with-O2.txt
> http://peknet.com/~karpet/char-without-O2.txt
For the email archive record... there's almost no difference between these two
files. Valgrind wasn't able to help.
Marvin Humphrey
Re: 64-bit linux errors with t/core/032-string_helper.t
Posted by Peter Karman <pe...@peknet.com>.
Marvin Humphrey wrote on 01/20/2010 11:22 AM:
> Do you have valgrind on these boxen? It would be interesting to see valgrind
> analysis of the small program with and without -02. However, I'm not sure
> we'll see anything -- Valgrind's ability to detect stack corruption is
> limited:
http://peknet.com/~karpet/char-with-O2.txt
http://peknet.com/~karpet/char-without-O2.txt
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [Lucy] Re: 64-bit linux errors with t/core/032-string_helper.t
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Wed, Jan 20, 2010 at 08:56:35AM -0600, Peter Karman wrote:
> although changing the main() function to this, and compiling with -O2,
> still works ok, which makes me think Marvin's comment about the variadic
> function printf() might be on target.
Well, that seems to demonstrate that it's variadic argument passing
misbehaving under -O2, but it's still misbehaving. I don't see anything in
the C code that's invalid. Kudos to Nate if he spots something I've missed.
Do you have valgrind on these boxen? It would be interesting to see valgrind
analysis of the small program with and without -02. However, I'm not sure
we'll see anything -- Valgrind's ability to detect stack corruption is
limited:
http://www.valgrind.org/docs/manual/faq.html#faq.overruns
Marvin Humphrey
Re: 64-bit linux errors with t/core/032-string_helper.t
Posted by Peter Karman <pe...@peknet.com>.
Peter Karman wrote on 01/20/2010 01:46 PM:
> Nathan Kurz wrote on 01/20/2010 01:35 PM:
>
>> If we are seeing success with GCC 4.2.4 and failure with GCC 3.4.6,
>> and nothing else obviously wrong, this would seem to indicate a
>> compiler bug or library bug. Are there other GCC versions that have
>> shown problems?
>
> No other compilers I know of.
>
> I'm currently downloading gcc 3.4.6 (the last of the 3.4.x releases
> fwiw, from 2006), and will try duplicating the problem on a different
> platform with the same compiler version.
>
>
gcc 3.2.3 on the same platform works ok. So I think we can safely call
it a compiler bug.
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: 64-bit linux errors with t/core/032-string_helper.t
Posted by Peter Karman <pe...@peknet.com>.
Nathan Kurz wrote on 01/20/2010 01:35 PM:
> If we are seeing success with GCC 4.2.4 and failure with GCC 3.4.6,
> and nothing else obviously wrong, this would seem to indicate a
> compiler bug or library bug. Are there other GCC versions that have
> shown problems?
No other compilers I know of.
I'm currently downloading gcc 3.4.6 (the last of the 3.4.x releases
fwiw, from 2006), and will try duplicating the problem on a different
platform with the same compiler version.
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [KinoSearch] 64-bit linux errors with t/core/032-string_helper.t
Posted by Nathan Kurz <na...@verse.com>.
On Wed, Jan 20, 2010 at 5:43 AM, Peter Karman <pe...@peknet.com> wrote:
> Nathan Kurz wrote on 1/20/10 1:35 AM:
>
>> Could you attach your failing standalone test case so I can take a
>> quick look at it? I tried the inline one above, but saw nothing
>> strange with GCC 4.2.4 on Slamd64.
>>
>
> http://rectangular.com/pipermail/kinosearch/2010-January/007228.html
That's the one I tried, but I didn't see anything odd when running it
with or without -O2. The symptom of failure would be the loop
skipping directly from i = 0 to i = 255?
If we are seeing success with GCC 4.2.4 and failure with GCC 3.4.6,
and nothing else obviously wrong, this would seem to indicate a
compiler bug or library bug. Are there other GCC versions that have
shown problems?
Nathan Kurz
nate@verse.com
Re: [Lucy] Re: 64-bit linux errors with t/core/032-string_helper.t
Posted by Peter Karman <pe...@peknet.com>.
Peter Karman wrote on 01/20/2010 07:43 AM:
> Nathan Kurz wrote on 1/20/10 1:35 AM:
>
>> Could you attach your failing standalone test case so I can take a
>> quick look at it? I tried the inline one above, but saw nothing
>> strange with GCC 4.2.4 on Slamd64.
>>
>
> http://rectangular.com/pipermail/kinosearch/2010-January/007228.html
>
although changing the main() function to this, and compiling with -O2,
still works ok, which makes me think Marvin's comment about the variadic
function printf() might be on target.
int main() {
u8_t i, max;
int j;
for (j=0, i=0, max=255; i<max; i++, j++) {
printf("[%d] TRAILING[%d] SKIP[%d]\n",
j,
(int)StrHelp_UTF8_TRAILING[i],
(int)StrHelp_UTF8_SKIP[i]
);
}
}
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: 64-bit linux errors with t/core/032-string_helper.t
Posted by Peter Karman <pe...@peknet.com>.
Nathan Kurz wrote on 1/20/10 1:35 AM:
> Could you attach your failing standalone test case so I can take a
> quick look at it? I tried the inline one above, but saw nothing
> strange with GCC 4.2.4 on Slamd64.
>
http://rectangular.com/pipermail/kinosearch/2010-January/007228.html
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [KinoSearch] 64-bit linux errors with t/core/032-string_helper.t
Posted by Nathan Kurz <na...@verse.com>.
On Tue, Jan 19, 2010 at 10:39 PM, Marvin Humphrey
<ma...@rectangular.com> wrote:
> On Tue, Jan 19, 2010 at 11:33:00PM -0600, Peter Karman wrote:
>
>> >Was this standalone file compiled with the same set of flags? Maybe
>> >there's some aggressive optimizer gone whack?
>>
>> bingo.
>>
>> When I compiled with -O2 I got the standalone to break.
>
> Rokk. :)
>
> I think we stop here. It's not worth working around this. The test will
> prevent silent failure, and if people care about compiling on systems that
> exhibit the bug, the workaround of disabling optimization is straightforward.
Marvin might be right, but inexplicable bugs have a nasty way of
biting back. Yes, there are real GCC bugs, but more often than not
there's something else going on.
Could you attach your failing standalone test case so I can take a
quick look at it? I tried the inline one above, but saw nothing
strange with GCC 4.2.4 on Slamd64.
Nathan Kurz
nate@verse.com
Re: 64-bit linux errors with t/core/032-string_helper.t
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Jan 19, 2010 at 11:33:00PM -0600, Peter Karman wrote:
> >Was this standalone file compiled with the same set of flags? Maybe
> >there's some aggressive optimizer gone whack?
>
> bingo.
>
> When I compiled with -O2 I got the standalone to break.
Rokk. :)
I think we stop here. It's not worth working around this. The test will
prevent silent failure, and if people care about compiling on systems that
exhibit the bug, the workaround of disabling optimization is straightforward.
Marvin Humphrey
Re: 64-bit linux errors with t/core/032-string_helper.t
Posted by Peter Karman <pe...@peknet.com>.
Marvin Humphrey wrote on 1/19/10 11:17 PM:
> Was this standalone file compiled with the same set of flags? Maybe there's
> some aggressive optimizer gone whack?
>
bingo.
When I compiled with -O2 I got the standalone to break.
>> I'm going to go drink a beer and try not to think about this madness for
>> awhile and hope that the answer just comes to me in my sleep.
>
> Can we tag out? If you can get me an account on one of these boxen, or if we
> can duplicate this behavior on an Amazon EC2 instance, I'd like to take a
> crack at it.
I'll work on that and mail you offlist.
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: 64-bit linux errors with t/core/032-string_helper.t
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Jan 19, 2010 at 09:13:35PM -0600, Peter Karman wrote:
> Notice that 'i' just skips straight from 0 to 255.
That's certainly puzzling and troublesome. It sounds like a stack corruption
bug -- as in the memory where the stack variable "i" resides is being
overwritten somehow. I don't suppose valgrind turns anything up...
> When I comment out either of the UTF8_*[..] calls, then it works fine. It's
> the combination of the two that causes the problem.
Oi. Shades of that damn NetBSD nightmare...
> So there are no macros to affect that _local() function, and no vararg
> oddities.
Well, don't shoot me but StrHelp_UTF8_TRAILING is actually a macro alias for
kino_StrHelp_UTF8_TRAILING, and printf is a variadic function so char arguments
such as StrHelp_UTF8_TRAILING[i] automatically get promoted to int. We should
try to remove all varidic functions and all macro expansions from the
equation.
Clearly stuff like that *shouldn't* make a difference, but our local char
array works, and there's not much difference between what's happening there
and what's happening in these tests.
> However, when I put the same code into a standalone file and run it, it
> works (see the test app I sent earlier in this thread with the UTF8 arrays
> hardcoded).
Was this standalone file compiled with the same set of flags? Maybe there's
some aggressive optimizer gone whack?
> I'm going to go drink a beer and try not to think about this madness for
> awhile and hope that the answer just comes to me in my sleep.
Can we tag out? If you can get me an account on one of these boxen, or if we
can duplicate this behavior on an Amazon EC2 instance, I'd like to take a
crack at it.
Marvin Humphrey
Re: 64-bit linux errors with t/core/032-string_helper.t
Posted by Peter Karman <pe...@peknet.com>.
Marvin Humphrey wrote on 1/19/10 2:45 PM:
> On Tue, Jan 19, 2010 at 02:14:17PM -0600, Peter Karman wrote:
>
>> I do get the same result.
>
> Good, 'cause working around that class of bug would have been a huge PITA -- I
> threw up my hands at that NetBSD bug.
>
> Maybe it's macro expansion weirdness? Try changing "ASSERT_INT_EQ" to
> "kino_TestBatch_int_equals" and "StrHelp_UTF8_SKIP" to
> "kino_StrHelp_UTF8_SKIP".
>
> I'm also not totally satisfied that we've ruled out vararg argument passing.
> What if we do something like this?
>
> bool_t condition = StrHelp_UTF8_SKIP[i] == 1 ? true : false;
> ASSERT_TRUE(batch, condition, "UTF8_SKIP ascii %d", (int)i);
>
I added a new function to the core/KinoSearch/Test/Util/TestStringHelper.c file
as below:
static void
test_SKIP_and_TRAILING_local()
{
u8_t i, max;
for (i=0, max=255; i < max; i++) {
printf("i == %d\n", i);
printf("UTF8_SKIP[%d] == %d\n", i, StrHelp_UTF8_SKIP[i]);
printf("i == %d\n", i);
printf("UTF8_TRAILING[%d] == %d\n", i, StrHelp_UTF8_TRAILING[i]);
printf("i == %d size %d\n", i, sizeof(i));
}
printf("finally: i == %d\n", i);
}
output:
$ perl -Mblib t/core/032-string_helper.t
<...snip regular test output...>
i == 0
UTF8_SKIP[0] == 1
i == 0
UTF8_TRAILING[0] == 0
i == 0 size 1
finally: i == 255
Notice that 'i' just skips straight from 0 to 255.
When I comment out either of the UTF8_*[..] calls, then it works fine. It's the
combination of the two that causes the problem.
So there are no macros to affect that _local() function, and no vararg oddities.
However, when I put the same code into a standalone file and run it, it works
(see the test app I sent earlier in this thread with the UTF8 arrays hardcoded).
I have tried this on two different RHEL 4 boxes, both with gcc version 3.4.6
20060404 (Red Hat 3.4.6-3).
I'm going to go drink a beer and try not to think about this madness for awhile
and hope that the answer just comes to me in my sleep.
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: 64-bit linux errors with t/core/032-string_helper.t
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Jan 19, 2010 at 02:14:17PM -0600, Peter Karman wrote:
> I do get the same result.
Good, 'cause working around that class of bug would have been a huge PITA -- I
threw up my hands at that NetBSD bug.
Maybe it's macro expansion weirdness? Try changing "ASSERT_INT_EQ" to
"kino_TestBatch_int_equals" and "StrHelp_UTF8_SKIP" to
"kino_StrHelp_UTF8_SKIP".
I'm also not totally satisfied that we've ruled out vararg argument passing.
What if we do something like this?
bool_t condition = StrHelp_UTF8_SKIP[i] == 1 ? true : false;
ASSERT_TRUE(batch, condition, "UTF8_SKIP ascii %d", (int)i);
Marvin Humphrey
Re: 64-bit linux errors with t/core/032-string_helper.t
Posted by Peter Karman <pe...@peknet.com>.
Marvin Humphrey wrote on 01/19/2010 01:51 PM:
> On Tue, Jan 19, 2010 at 01:37:12PM -0600, Peter Karman wrote:
>
>> ok - 0 == 0
>> ok - 1 == 1
>> ok - 100 == 100
>> ok - 126 == 126
>> ok - 127 == 127
>> ok - 128 == 128
>> ok - 129 == 129
>> ok - 250 == 250
>> ok - 254 == 254
>> ok - 255 == 255
>
> Whew. If that's the case, we ought to be able to make this work.
>
> If you dump that same code into the TestStringHelper.c file, do you get the
> same result? Checking for compiler flag weirdness or bizarre interactions
> from include libraries... (KinoSearch's tests once tickled a NetBSD bug that
> changed how doubles and long longs were converted to each other when a
> particular library was included...)
>
I do get the same result.
Patch below (in case I messed it up):
Index: core/KinoSearch/Test/Util/TestStringHelper.c
===================================================================
--- core/KinoSearch/Test/Util/TestStringHelper.c (revision 5710)
+++ core/KinoSearch/Test/Util/TestStringHelper.c (working copy)
@@ -4,7 +4,20 @@
#include "KinoSearch/Test/Util/TestStringHelper.h"
#include "KinoSearch/Util/StringHelper.h"
+static unsigned char numbers[256];
+
static void
+check_subscript(unsigned char subscript)
+{
+ if (subscript == numbers[subscript]) {
+ printf("ok - %d == %d\n", subscript, numbers[subscript]);
+ }
+ else {
+ printf("not ok - %d == %d\n", subscript, numbers[subscript]);
+ }
+}
+
+static void
test_SKIP_and_TRAILING(TestBatch *batch)
{
u8_t i, max;
@@ -48,6 +61,37 @@
ASSERT_TRUE(batch, StrHelp_UTF8_TRAILING[i] == 7,
"UTF8_TRAILING bogus but no memory problems %d", (int)i);
}
+ for (i=0, max=255; i < max; i++) {
+ printf("i == %d\n", i);
+ printf("UTF8_SKIP[%d] == %d\n", i, StrHelp_UTF8_SKIP[i]);
+ }
+ for (i=0, max=255; i < max; i++) {
+ printf("i == %d\n", i);
+ printf("UTF8_TRAILING[%d] == %d\n", i,
StrHelp_UTF8_TRAILING[i]);
+ }
+ for (i=0, max=255; i < max; i++) {
+ printf("i == %d\n", i);
+ printf("UTF8_SKIP[%d] == %d\n", i, StrHelp_UTF8_SKIP[i]);
+ printf("UTF8_TRAILING[%d] == %d\n", i,
StrHelp_UTF8_TRAILING[i]);
+ printf("i == %d\n", i);
+ }
+ printf("finally: i == %d\n", i);
+
+ int j;
+
+ for (j = 0; j < 256; j++) {
+ numbers[j] = j;
+ }
+ check_subscript(0);
+ check_subscript(1);
+ check_subscript(100);
+ check_subscript(126);
+ check_subscript(127);
+ check_subscript(128);
+ check_subscript(129);
+ check_subscript(250);
+ check_subscript(254);
+ check_subscript(255);
}
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [KinoSearch] 64-bit linux errors with t/core/032-string_helper.t
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Jan 19, 2010 at 01:37:12PM -0600, Peter Karman wrote:
> ok - 0 == 0
> ok - 1 == 1
> ok - 100 == 100
> ok - 126 == 126
> ok - 127 == 127
> ok - 128 == 128
> ok - 129 == 129
> ok - 250 == 250
> ok - 254 == 254
> ok - 255 == 255
Whew. If that's the case, we ought to be able to make this work.
If you dump that same code into the TestStringHelper.c file, do you get the
same result? Checking for compiler flag weirdness or bizarre interactions
from include libraries... (KinoSearch's tests once tickled a NetBSD bug that
changed how doubles and long longs were converted to each other when a
particular library was included...)
Marvin Humphrey
Re: 64-bit linux errors with t/core/032-string_helper.t
Posted by Peter Karman <pe...@peknet.com>.
Marvin Humphrey wrote on 01/19/2010 01:35 PM:
> I think the next step is to isolate the behavior of this platform in a minimal
> test app. Peter, what output do you see when you run the program below?
>
ok - 0 == 0
ok - 1 == 1
ok - 100 == 100
ok - 126 == 126
ok - 127 == 127
ok - 128 == 128
ok - 129 == 129
ok - 250 == 250
ok - 254 == 254
ok - 255 == 255
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [KinoSearch] 64-bit linux errors with t/core/032-string_helper.t
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Jan 18, 2010 at 09:53:47PM -0800, Eric Howe wrote:
> On 2010-01-18, at 21:05 , Marvin Humphrey wrote:
> [...]
> > It seems messed up that an unsigned type gets promoted to a negative signed
> > type when used as an array subscript. You're not supposed to use "char" on
> > its own as an array subscript, because whether "char" is signed or unsigned is
> > implementation defined, but either "signed char" or "unsigned char" are
> > allowed.
>
> Arrays in C are just convenient notation for pointer arithmetic so array
> indices in C are not char, nor are they signed char nor unsigned char,
> they're probably int. Are you getting tripped up by an implicit "a[(int)i]"
> cast on the index?
>
> Just a wild guess.
GCC will warn under -Wchar-subscripts (enabled by -Wall) if you use a naked
"char" variable as an array subscript. It won't warn under either "signed
char" or "unsigned char", because those are both unambiguous. That's what I
was referring to; it was imprecise of me to use "supposed to" and "allowed"
because it's the compiler rather than the C standard that imposes the
restriction, and it's only a warning not an error.
I'm still not sure exactly what's going on. If it's just promotion, an int
should be wide enough to hold all the values of an unsigned char, so the
converted value should be the same. So should values converted to whatever
64-bit type is used internally to perform pointer math on this system.
I think the next step is to isolate the behavior of this platform in a minimal
test app. Peter, what output do you see when you run the program below?
Marvin Humphrey
#include <stdio.h>
unsigned char numbers[256];
static void
check_subscript(unsigned char subscript)
{
if (subscript == numbers[subscript]) {
printf("ok - %d == %d\n", subscript, numbers[subscript]);
}
else {
printf("not ok - %d == %d\n", subscript, numbers[subscript]);
}
}
int main ()
{
int i;
for (i = 0; i < 256; i++) {
numbers[i] = i;
}
check_subscript(0);
check_subscript(1);
check_subscript(100);
check_subscript(126);
check_subscript(127);
check_subscript(128);
check_subscript(129);
check_subscript(250);
check_subscript(254);
check_subscript(255);
return 0;
}