what -I- consider a bug in *cabe

[Kenneth Brody]

Quoting Fairlight (Sat, 2 Jun 2007 15:20:45 -0400):
[...]
> There have been examples of "typo" or semantic type bugs that fP
> -does- catch that I was trying to think of last night.  Things that
> specifically make me think, "Gee, if it goes this far, certainly it
> should check for a non-numeric argument as a sole string literal in
> a place where a numeric is required."  Emphasis on -sole string
> literal-.

What sort of "typos" are you refering to which filePro catches at
compile time yet aren't syntax errors?

[...]
> However, now that I think back, I remember having issues in lookups
> with long variable names if you don't put parentheses around them in
> the k= portion of the lookup statement, for one.  Yes, I just tested
> to make sure it still does that as of 5.6.06R4 on linux.
>
> ::declare longvar;longvar="abcde":
> ::lookup test = demo k=longvar i=a -nx:

This _is_ a syntax error.  What follows "k=" must either be a field,
or an expression contained within parentheses.  The variable "longvar"
is not a "field".

> And it'll complain about longvar there as an "invalid field in
> processing set" (that's the literal error text).

As I said above, the variable longvar is not a "field".

> I would personally say that's a lot less of a typo than what I had
> with my mid() statement.  And if you just use "aa" without using it
> elsewhere, it complains because it doesn't exist anywhere, which
> makes sense.  If you use "aa" and it is used elsewhere, it passes.

That's because "aa", while a valid field name, does not exist unless
it has been declared (either explicitly or implicitly) elsewhere.

> But since I've declared "longvar", why should I get that error
> unless putting parens around it?

Because "longvar" is not a field, and expressions in this context
require parentheses around them.

> It's convoluted stuff like that where it's obviously going to some
> lengths to check against something obscure that makes me go, "If it
> will check for something that arcane there, why won't it check for
> a simple numeric value as a sole string literal if it detects that's
> all that was there?"

As stated elsewhere, a string which contains a value which doesn't
make sense in context is not a "syntax error", as long as a string
is valid syntax in that context.

[...]
> What I'm asking for seems -logical- to expect, but again, I can't
> think of another language that actually does it, prompted by your
> example and reducing it to a single literal.  Even perl took
> substr($test,"g","2") and just evaluated the start position to 0.
>
> So yeah...you're right.

Told ya!  :-)

[...]
> Nah, upon reflection of what you said and looking at other languages
> (I'm 99% sure even without testing that C would compile such gibberish
> as well, it would just possibly act -really- severely cranky at
> runtime...

Now, _some_ C compilers do parse literal strings passed as the format
specifier to the *printf set of functions in order to type-check the
parameters being passed.  However, I don't know if there are any that
will check the mode flags to fopen(), for example.

[...]
> Damn, but I'm glad I prefaced it as opinion this time.  Now I only
> feel like half an idiot instead of a complete one.

That's okay.  You'll do better next time.  :-)

> But this leaves me feeling unfulfilled!  :) :) :)

You need to order fulfillPro.

> > Maybe a whole new class of errors??
> >
> > ***Warning a typo has been encountered***
> >
> > :-)
>
> I'll go for that.  Can we also add:
>
> ***PEBKAC***

The problem is that such a message would appear so often that it
would become the new BSOD.  :-)

[...]

--
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com