Re: [9fans] more questions

Re: [9fans] more questions

[rob pike]

	Why does utflen() return an int instead of a long?
It should be long; fixed.

	Should Brdline take a Rune as the delimiter?
Probably, but it's a nasty change to make.

	isalpharune(2) claims that toupperrune and tolowerrune return ints, but they
	return Runes.
You're right; fixed.

-rob

Re: [9fans] more questions

[Quinn Dunkan]

Correction:
A tarball with a few plan9 binaries that crash my kernel every time is at

http://www.ugcs.caltech.edu/~quinn/9crash.tgz

Sorry.

Re: [9fans] more questions

[Quinn Dunkan]

[ rog ]
> i've been bitten by that regexp problem before.  your problem is that
> the matches array is being used uninitialised.  as the documentation
> says:

Of course, you're right.  I forgot about that whole uninitialized-auto-
variables thing.  Sorry to inflict my C-ignorance on the list.

But here's something else.  I've been having my program suicide, and while
tracking it down, managed to provoke a kernel panic.  The message is:

panic: fp: status 8181  fppc=0xfa62 pc=0x80100241
ktrace /kernel/path 8010649e 80c209ac
[ lots of hex ]


It has something to do with a number >= 2147483648, which smells like integer
overflow.  But the weird thing is that the number is being stored in a double,
and then cast to a ulong (and it does look like an fpu thing).  And whether or
not it crashes the program or the kernel changes when I do things like take
unrelated code out of the link line, or change the order of events.

A tarball with a few plan9 binaries that crash my kernel every time is at

http://www.calarts.edu/~quinn/9crash.tgz

Just run '1/lua 1/crash.lua' or '2/lua 2/crash.lua' and see if your printer
catches on fire.  I tried to isolate it better, but it's tricky because the
computer keeps crashing and I don't want to hose my kfs.  And it has a
tendency to hide.  I'm interested in seeing if it happens on other systems, or
if it's something wrong with mine.

If it's not just my setup, I'll upload the source too (or if people don't want
to run some random binary off the net).



Oh, and by the way, what do people do when they want to find the definition of
a function or type?  "grep -n '^func' *.c" works if the code is formatted right,
but that still doesn't work for types.

Re: [9fans] more questions

[rog]

i've been bitten by that regexp problem before.  your problem is that
the matches array is being used uninitialised.  as the documentation
says:

          If match[0].sp is nonzero on entry, regexec starts matching
          at that point within string. If match[0].ep is nonzero on
          entry, the last character matched is the one preceding that
          point.

in a larger program, your code would probably have broken... and then
you'd probably have found the problem!

  cheers,
    rog.

[9fans] more questions

[Quinn Dunkan]

A few anal questions:

Why does utflen() return an int instead of a long?

Should Brdline take a Rune as the delimiter?

isalpharune(2) claims that toupperrune and tolowerrune return ints, but they
return Runes.

9p(2) says that "the wstat function takes a fid and a new Dir structure for
it, as well as a bitmask specifying which fields to update".  The signature in
the struct Srv has no mention of a bitmask.  Is the documentation in error?



The following function, when called with 're = regcomp("(..):(..)")' and
's = "ab:34"' will print:

matching against 'ab:34'

However, when the first line after the '{' is changed from 'char *s, *src;' to
'char *s;', it will print:

matching against 'ab:34'
success

The match will succeed if 'char *s' is placed below 'Reprog *re', but it will fail
if placed below 'Resub matches[...]', or if it is at the top with 'Reprog *re' and
'Resub matches[...]' swapped.  It will always fail if another 'char *' (or plain
'char') is declared on the same line as it is (the name doesn't matter).
Another 'char *' being declared at the bottom makes the regexp succeed,
though.

// just a fragment
static int re_sub(lua_State *L)
{
	char *s, *src;
	Reprog *re;
	Resub matches[max_matches];

	if (lua_tag(L, 1) != re_tag)
		luaL_argerror(L, 1, "expected regexp object");
	re = (Reprog *) lua_touserdata(L, 1);
	s = luaL_check_string(L, 2);

	print("matching against '%s'\n", s);
	if (regexec(re, s, matches, max_matches) == 0) {
		lua_pushnil(L);
		return 1;
	}
	print("success\n");
	return 0;
}

I was under the impression that changing the order of one's variable
declarations should have no effect on the operation of the program.
I tried making a standalone function (called from C), but the problem went
away then.  Could it be a compiler bug?  It's hard to reduce since it's being
called from lua, but if it could be a real issue I'll try to track it down.

Re: [9fans] more questions

[Russ Cox]

the 9p(2) thing is an error.  it sounds like
an early version of 9p2000; probably i edited
the wrong manual.  

don't get too comfortable with 9p(2).  i changed
a bunch of stuff (including interfaces) when i
rewrote the library for 9p2000.  

in the lua code, what is max_matches?