William F Pokorny <ano### [at] anonymousorg> wrote:

> which highlights another kind of trap! Namely, using z,y,z,u or v
> internal to a function body where you've not specified them in the
> argument list. Looks like those all default to 0 and the variables are
> available within the function body without complaint from the parser
> whether they are getting set by some explicit (or defaulted) argument
> passing or not. The 'not' case being the exposure.

I vaguely recall running into this (or very similar) in the past year or so, and
think I commented on it.  Still good to keep it closer to the front burner for
general awareness.


> With the function
> arguments I believe by the time the parsing sees the second 'a' it
> understand it to be a value - there is already an entry in the local
> symbol hash table for 'a'. So, for any after the first, it substitutes
> the value it knows 'a' to be.

Ooooh.  Tricky.  I wouldn't have anticipated that.

> Thinking aloud, with this kind of stuff, might well be a stand alone SDL
> linter utility would be easier to implement. Static code analysis for
> SDL! :-o

Yes, I think that sort of general idea has been poked with a stick a few times.
I've even thought of unrolling all of the code and spreadsheeting out all of the
"live" values.  All of which is way beyond my present coding skills in any
language.

Very cool experiments.  Somewhat hard to follow, and I'm sure there are a few
more things that could be tried.   I'm assuming that using "a" (or any other
non-special variable name) in a function without declaring it in the argument
list gives the expected error.

Maybe writing a script using parse_string to cycle through a list of variable
names might highlight some things we haven't even thought of yet.

I'm guessing keywords are obviously forbidden in macro and function argument
lists and equation expressions (just asking because x, y, z, u, v, t) are all
"keywords" -  but transmit, filter, red, green, blue, r, g, b, are all
dot-notation variable-extensions....

Post a reply to this message