 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/18/23 08:59, Kenneth wrote:
> So is a string expression the only kind of 'thing' that #ifdef sees as defined?
> Nope. Even an arbitrary float value behaves the same way:
>
> #ifdef(7.6)
> ...do this... // success
> #else
> ...do that...
> #end
>
> To me, this would seem to be an unexpected trap, waiting to be 'exploited' by
> mistake. I'm not sure how such a mistake might be made by a user, but still...
>
> My two-cents 😉
I agree with three-cents - and now we have five! :-)
I took a quick look just now and v3.7 works as expected in some quick
testing in that only identifiers are OK - which I do believe is the intent.
So, I'd say this is another v3.8 beta 2 bug.
It's something with the changes in parsing, but it must have happened
prior to Christoph's back off point for the v3.8 parser too.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscape net> wrote:
> >
> > So is a string expression the only kind of 'thing' that #ifdef sees
> > as defined?
> > Nope. Even an arbitrary float value behaves the same way:
> >
> > #ifdef(7.6)
> > ...do this... // success
> > #else
> > ...do that...
> > #end
> >
> This is the way POV-Ray works with "Boolean" values (and IIRC, so do other
> computer languages) O is false, and any non-zero value is true.
> Send the str value of true to debug and see what it is. It's a
> common shorthand to use 0 and 1 for t&f or the setting of "flags" in code.
Yep, I get that-- if the #ifdef is seeing it as boolean, that is. But here's a
weird thing (well, weird to me at this point of my fuzzy understanding):
#ifdef(true)
is apparently seen as NOT defined, and falls through to the #else. Of course,
I'm not even sure if that construct makes any sense code-wise or syntax-wise.
>
>
> (And to head off your purely theoretical complaint, 7.6 IS a number, and so it
> IS defined when that ) closes the #ifdef statement.
> You might try that with 0 and see what happens...
Strangely(?), this has the same result as above: #ifdef(0) falls through to the
first clause. So maybe the 'boolean' explanation doesn't hold for #ifdef?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> Strangely(?), this has the same result as above: #ifdef(0) falls through to the
> first clause. So maybe the 'boolean' explanation doesn't hold for #ifdef?
oops, sorry---
"Strangely(?), this does NOT have the same result as above: #ifdef(0) falls
through to the first clause" (and so is seen as defined.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> Yep, I get that-- if the #ifdef is seeing it as boolean, that is. But here's a
> weird thing (well, weird to me at this point of my fuzzy understanding):
> #ifdef(true)
> is apparently seen as NOT defined, and falls through to the #else. Of course,
> I'm not even sure if that construct makes any sense code-wise or syntax-wise.
And you get that to work without a warning?
My few test cases resulted in:
#ifdef ("String") returns true.
#ifdef (1) returns true.
#ifdef (0) returns true.
"C:\Users\Mini\Documents\POV-Ray\v3.8-beta\scenes\DefinedValues.pov" line 13:
Parse Warning: Tried to test whether a reserved keyword is defined. Test result
may not be what you expect, and may fundamentally differ in future
versions.
#ifdef (true) returns false.
#ifdef (tau) returns false.
#ifdef (pi) returns false.
#ifdef (pigment) returns false.
#ifdef (if) returns false.
"C:\Users\Mini\Documents\POV-Ray\v3.8-beta\scenes\DefinedValues.pov" line 15:
Parse Warning: Tried to test whether a reserved keyword is defined. Test result
may not be what you expect, and may fundamentally differ in future
versions.
"C:\Users\Mini\Documents\POV-Ray\v3.8-beta\scenes\DefinedValues.pov" line 17:
Parse Warning: Tried to test whether a reserved keyword is defined. Test result
may not be what you expect, and may fundamentally differ in future
versions.
"C:\Users\Mini\Documents\POV-Ray\v3.8-beta\scenes\DefinedValues.pov" line 19:
Parse Warning: Tried to test whether a reserved keyword is defined. Test result
may not be what you expect, and may fundamentally differ in future
versions.
"C:\Users\Mini\Documents\POV-Ray\v3.8-beta\scenes\DefinedValues.pov" line 21:
Parse Warning: Tried to test whether a reserved keyword is defined. Test result
may not be what you expect, and may fundamentally differ in future
versions.
-
"C:\Users\Mini\Documents\POV-Ray\v3.8-beta\scenes\DefinedValues.pov" line 32:
Note that, "Test result may not be what you expect...." because it's a keyword,
not a proper variable.
I also tried:
#ifdef (0a) #debug concat ("#ifdef (", "0a", ") returns true. \n") #else #debug
concat ("#ifdef (", "0a", ") returns false. \n") #end
and get "No matching ), undeclared identifier found instead."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/18/23 10:19, William F Pokorny wrote:
>> To me, this would seem to be an unexpected trap, waiting to be
>> 'exploited' by
>> mistake. I'm not sure how such a mistake might be made by a user, but
>> still...
>>
>> My two-cents 😉
>
> I agree with three-cents - and now we have five! 😄
>
> I took a quick look just now and v3.7 works as expected in some quick
> testing in that only identifiers are OK - which I do believe is the intent.
>
> So, I'd say this is another v3.8 beta 2 bug.
>
> It's something with the changes in parsing, but it must have happened
> prior to Christoph's back off point for the v3.8 parser too.
Alright.
A long time ago I created a bunch of statically linked(a) versions of
POV-Ray going back through time. Anyhow. Used these to trace the
introduction of the str/num OK in #ifdef test bug.
Bill P.
(a) - This the old timer's container alternative.
---
commit 58d51f4911dce5e9021c62b30983902b0aab8b04 str,num OK
Author: Christoph Lipka <c-l### [at] usersnoreplygithubcom>
Date: Sun Mar 1 02:05:39 2015 +0100
Fixed scrambled warning messages.
// There are only five commits between the one up top and the bottom
// one below. My BIG bet is on the following commit being the problem,
// but I don't have a static compile of it or the one prior to it to
// be sure.
commit a94c1ab61aeb2aa483aa3636736ff1e24ebd8b78
Author: Christoph Lipka <c-l### [at] usersnoreplygithubcom>
Date: Sun Mar 1 02:03:14 2015 +0100
Implemented tuple extensions to #declare and #local.
...
commit 3f56c5fb8a54998067a217e54101c799756510b4 Complains.
Author: Christoph Lipka <c-l### [at] usersnoreplygithubcom>
Date: Tue Feb 3 16:48:11 2015 +0100
Fixed Unix build errors.
---
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > Yep, I get that-- if the #ifdef is seeing it as boolean, that is. But
> > here's a weird thing (well, weird to me at this point of my fuzzy
> > understanding):
> > #ifdef(true)
> > is apparently seen as NOT defined, and falls through to the #else.
>
> And you get that to work without a warning?
>
I didn't think to look. But you're right, I get the same warning:
"Parse Warning: Tried to test whether a reserved keyword is defined..." etc.
So with a *properly*-working #ifdef instead of the current flaw in v3.8.0 beta 1
or 2 'official' versions, I'm still curious about something you mentioned: Is it
supposed to indeed be a simple boolean comparison? Or is it's operation more
complex than that?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> So with a *properly*-working #ifdef instead of the current flaw in v3.8.0 beta 1
> or 2 'official' versions, I'm still curious about something you mentioned: Is it
> supposed to indeed be a simple boolean comparison? Or is it's operation more
> complex than that?
Wellll.......
I suppose it depends upon what one wants the language to do or thinks it
properly "ought" to do...
One could argue that a keyword is, in some sense, "defined", and as the warning
message states, reserved.
My example (probably me reading the whole post in a haze) of 0 / 1 was really
for _#if_, not #ifdef.
I'm sure that "Real programmers" have a better take on this, and sounder reasons
than I could present.
Aside:
Rather than having to write a whole ifdef/else/end statement for every case I
wanted to test, I had the strong urge to write a macro and maybe use ParseString
to make it work, but we don't have a way to test for data type, isolate
keywords, or any of the tools to write that sort of "meta" code.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
>
> Alright.
>
> A long time ago I created a bunch of statically linked(a) versions of
> POV-Ray going back through time. Anyhow. Used these to trace the
> introduction of the str/num OK in #ifdef test bug.
> [clip]
> My BIG bet is on the following commit being the problem,
> but I don't have a static compile of it or the one prior to it to
> be sure.
>
Given the current mix of flaws, the use of a string literal still has me
scratching my head...
#ifdef("...string...")
Alain's and JR's explanation of the expected behavior seems valid; but with a
properly-working #ifdef, should the comparison fail outright (fatal error)? Or
should it still be seen as defined? I'm mostly just curious ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> Given the current mix of flaws, the use of a string literal still has me
> scratching my head...
> #ifdef("...string...")
>
> Alain's and JR's explanation of the expected behavior seems valid; but with a
> properly-working #ifdef, should the comparison fail outright (fatal error)? Or
> should it still be seen as defined? I'm mostly just curious ;-)
One might suggest:
"Expected variable name, literal value found instead."
-or- "It is what is is." ;)
The correct answer for me has always been OPTIONS.
When everything gets locked into a one-right-answer only format, it usually just
creates new problems in the process of "solving" the old.
I was just reading some old threads concerning this type of thing, and the
degenerate triangle warning vs 0-length fatal error for cylinders was brought
up.
For some scenes it could be a critical thing to stop the render. For others,
you might want to just ignore them all. Usually these things are addressed by
the users with workarounds, but why not have a configuration file that states
how to handle these cases, an additional argument for the object instantiation
that provides for individual control, or an error-trapping mechanism (with error
code) that allows the user to write their own programmatic/logical solution
based on further testing and flow control, and allows the user to issue better
warnings that the cryptic ones currently hard-coded in source?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/19/23 10:14, Kenneth wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>>
>> Alright.
>>
>> A long time ago I created a bunch of statically linked(a) versions of
>> POV-Ray going back through time. Anyhow. Used these to trace the
>> introduction of the str/num OK in #ifdef test bug.
>> [clip]
>> My BIG bet is on the following commit being the problem,
>> but I don't have a static compile of it or the one prior to it to
>> be sure.
>>
>
> Given the current mix of flaws, the use of a string literal still has me
> scratching my head...
> #ifdef("...string...")
>
> Alain's and JR's explanation of the expected behavior seems valid; but with a
> properly-working #ifdef, should the comparison fail outright (fatal error)? Or
> should it still be seen as defined? I'm mostly just curious ;-)
>
I'm a little further along in looking at this. It's looking messy.
I think we need to start with the fact #ifdef, #ifndef and #undef have
ALWAYS been #ifIdDefined, #ifIdNotDefined and #undefineId. Going back to
the v3.6 documentation we have:
---------------
2.2.2.6.2 The #ifdef and #ifndef Directives
The #ifdef and #ifndef directive are similar to the #if directive
however they are used to determine if an identifier has been previously
declared.
IFDEF_DIRECTIVE:
#ifdef ( IDENTIFIER ) TOKENS... [#else TOKENS...] #end
IFNDEF_DIRECTIVE:
#ifndef ( IDENTIFIER ) TOKENS... [#else TOKENS...] #end
If the IDENTIFIER exists then the first group of tokens is parsed
normally and the second set is skipped. If false, the first set is
skipped and the second set is parsed. ...
----------------
So... The up front, not so good, news is the behavior of at least the
#ifdef and #ifndef keywords was partly changed back in March of 2015.
Intentional or accidental? It's not mentioned as an intended change
anywhere I have seen - and I still don't understand how it happened even
with some time reviewing the changes when it happened.
Christoph went on to add a bunch of inbuilt keywords to be considered
'defined' sometime after late November 2018 - which makes me begin to
think he too might have been considering these *def keywords in the
c/c++ coding, macro test sense.
The few 'keywords' I've tested these generate a warning in at least some
versions of POV-Ray. But it's weird, keywords NOT returning immediate
numbers or strings are also considered 'defined' in these versions
though they are in fact arbitrary SDL keywords.
Even this worked in the pre-backed off v3.8 release parser:
#ifdef(#declare V=99;#undef V)
...
Though without some other mistake it would usually die with a later
unmatched something parsing fail. That said it's not hard to get it to
parse clean - say with an added #if(). I will always die if somebody
tries use the undef'd V.
So, much more was being supported as testing true in povr/v4.0, but
still not some things like raw vectors. Though things like x,y,z are OK.
Christoph backed up the v3.8 parser and again lost the inbuilt keywords
as "defined". I do not know the reasons for the parser backup, but
perhaps this issue it - or big part of it. I don't know.
I do know, I've got a mess with these in the povr parser given my branch
point... :-(
When I test v3.7, v3.8b2 and my povr(v4.0?) code I get:
v3.7
----------------------
GOOD_ID --> This is a valid ID. (ifdef returning true)
GOOD_ID --> This is a valid ID. (ifndef returning false)
BAD_ID --> This is NOT a valid ID. (ifdef returning false)
BAD_ID --> This is NOT a valid ID. (ifndef returning true)
"STRING" --> Other than an ID. (ifdef returning false)
"STRING" --> Other than an ID. (ifndef returning true)
"" --> Other than an ID. (ifdef returning false)
"" --> Other than an ID. (ifndef returning true)
1.23456 --> Other than an ID. (ifdef returning false)
1.23456 --> Other than an ID. (ifndef returning true)
0 --> Other than an ID. (ifdef returning false)
0 --> Other than an ID. (ifndef returning true)
pi --> Other than an ID. (ifdef returning false)
pi --> Other than an ID. (ifndef returning true)
--> Other than an ID. (ifdef returning true)
--> Other than an ID. (ifndef returning true)
v3.8b2
-----------------------
GOOD_ID --> This is a valid ID. (ifdef returning true)
GOOD_ID --> This is a valid ID. (ifndef returning false)
BAD_ID --> This is NOT a valid ID. (ifdef returning false)
BAD_ID --> This is NOT a valid ID. (ifndef returning true)
"STRING" --> Other than an ID. (ifdef returning true) ***
"STRING" --> Other than an ID. (ifndef returning false) ***
"" --> Other than an ID. (ifdef returning true) ***
"" --> Other than an ID. (ifndef returning false) ***
1.23456 --> Other than an ID. (ifdef returning true) ***
1.23456 --> Other than an ID. (ifndef returning false) ***
0 --> Other than an ID. (ifdef returning true) ***
0 --> Other than an ID. (ifndef returning false) ***
pi --> Other than an ID. (ifdef returning false)
pi --> Other than an ID. (ifndef returning true)
--> Other than an ID. (ifdef returning true)
--> Other than an ID. (ifndef returning true)
povr & likely v4.0 and other misc releases before parser backup
-------------------------
GOOD_ID --> This is a valid ID. (ifdef returning true)
GOOD_ID --> This is a valid ID. (ifndef returning false)
BAD_ID --> This is NOT a valid ID. (ifdef returning false)
BAD_ID --> This is NOT a valid ID. (ifndef returning true)
"STRING" --> Other than an ID. (ifdef returning true) ***
"STRING" --> Other than an ID. (ifndef returning false) ***
"" --> Other than an ID. (ifdef returning true) ***
"" --> Other than an ID. (ifndef returning false) ***
1.23456 --> Other than an ID. (ifdef returning true) ***
1.23456 --> Other than an ID. (ifndef returning false) ***
0 --> Other than an ID. (ifdef returning true) ***
0 --> Other than an ID. (ifndef returning false) ***
pi --> Other than an ID. (ifdef returning true) ###
pi --> Other than an ID. (ifndef returning false) ###
--> Other than an ID. (ifdef returning true)
--> Other than an ID. (ifndef returning true)
The last case with empty parens is an exposure back to v3.7. In a lot of
code the effective fall through at the #if____ will cause later parsing
problems, but the error are of the more unhelpful sort. It would be best
if the empty parens were themselves a parse error. I 'think' it's
probably also possible to fix the following parsing issues with another,
cleaning syntax (actual bad-syntax) sort of mistake.
My feeling is the right thing to do would be to take the behavior back
to what it has always been with the nearer term v3.8 release. If we want
the most backward compatibility this it. Further, the extra now being
changed currently in the v3.8 code is not consistent with respect to
things like pi - which to the parser is an immediate value of pi. And
datetime would be an example of an immediate string which would test
true, you'd think, if "string" does.
What to do... I could spend a lot of time trying to figure out the
history here, but I think the current state not completely tenable since
2015...
We need functionality which deals only with IDs.
We, perhaps, need some sort of what is in the parenthesis is 'defined'
functionality too, but the generic sort being allowed or not seems
questionable to me. Are people already using this functionality?
With povr I might do something drastic like create 'id' versions and and
'defined' versions - with all new keyword names so users would be forced
to look at potential problems with interpretation and behavior given the
old keywords wouldn't work!
Hmm... We do have new to v3.8 the local and global dictionaries. Could I
just dump the #ifdef and #ifndef keyword for something based on those. I
can't remember at the moment how they work.
Don't know... Whatever it is in povr, afraid at the moment it'll be a
lot of work - because I'll need to digest a lot of the parser code.
Guess it's time to do my taxes... :-)
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
