This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: semantic error: cannot expand unknown type
Hi -
dsmith wrote:
> [...] Yeah, it is a bit ugly. However, if we don't explicitly only
> take "return" and "function" here, then the user is free to write
> 'probe kernel.while("sys_read").if'.
I'd be OK with that. We can keep a separate namespace for probe
points.
> [...]
> >We should outlaw the latter two (and rename or remove the current
> >string() function in conversions.stp).
> >
> Glad we agree. What do we want to rename the string() function to?
> ltoa()? long2str()? long_to_string()? Or something else? I'd probably
> pick "long_to_string()".
Or just remove it altogether: sprint(<numeric-expression>) is equivalent.
> [...]
> if (!(ok)) return (value) = (retval())
> When the parser sees the return, it isn't smart enough to realize that a
> return keyword isn't valid in a probe point, only in a function.
Yes, and similarly with "next". Detecting the wrong "escape"
statement is left to translation time. One could fix the parser in a
couple of little ways:
- parametrize the statement parsers, passing along a "in_function_p" flag
that originates from from parse_functiondecl() and parse_probe()
- or pass the equivalent flag within a parser class member variable
- or fork the parse_stmt_block and parse_statement
The first and second of these seem okay, only slightly noxious.
The third has a theorist's respect and an engineer's disdain. :-)
- FChE