Am 02.03.2016 um 08:25 schrieb clipka:
> Wanna bet that "#write" does the very same thing?

uh, I meant "#read".

Post a reply to this message

Am 01.03.2016 um 23:08 schrieb Le_Forgeron:

> ab-using code like
> #write( .... #write( ...
> is a call for lightning from Zeus and the opening of the multidimensional portal for
Chtulhu.

Actually - no. There's no abuse in there /per se/. The nested `#write`
might be part of a macro invocation, such as in:

#write(File,SomeMacro())

where `SomeMacro` might be part of a 3rd party include file that itself
makes heavy use of file operations, e.g. to persist some random number
generator's state across frames or the like.

Most notably, `Parse_String` is implemented as a macro that uses `#write`.

Post a reply to this message

Le 02/03/2016 08:25, clipka a écrit :
> Am 01.03.2016 um 23:08 schrieb Le_Forgeron:
>
>> The heap is exhausted
>
> I presume you mean "stack", right?


yes... and I was tired also, because it's 4 functions calls per 
iteration, not 2, so the stack size would need a x10...

>
>> NAAAAHHH, Parse_Write should use a pattern already use elsewhere, no more than one
recursion... or even none at all.
>
> That would plug up only one of a guesstimated 4711 ways to coax the
> POV-Ray parser into recursive calls.
>
> Wanna bet that "#write" does the very same thing?
>
> I think it would be more sensible to impose some arbitrary upper limit
> to the nesting of Get_Token() calls; that would at least catch one
> entire family of those 4711 ways.
>

Beware to not stop code that stacks #local and other in the middle of 
valid statement, including themself. limiting to #write (and #read) at 
least have a smaller impact.

OTOH, I never was fan of "smart" code.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

> ab-using code like
> #write( .... #write( ...
> is a call for lightning from Zeus and the opening of the multidimensional portal for
Chtulhu. The first to kill the a
buser wins. In case of tie, Poseidon can make the life of perpetrator an hell to which
the saga of Ulysse[s] would look
 like a pleasant walk on Sunday afternoon.

I'm laughing so hard that I'm losing coffee.
Thanks for that  :)

Post a reply to this message

Looks good from here.

The only error I get on my machine,
Running 3.7.0.msvc10.win64 is a parse error for "kolors.inc"


Trivial, all things considered.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 01.03.2016 um 23:08 schrieb Le_Forgeron:
>
> > ab-using code like
> > #write( .... #write( ...
> > is a call for lightning from Zeus and the opening of the multidimensional portal
for Chtulhu.
>
> Actually - no. There's no abuse in there /per se/. The nested `#write`
> might be part of a macro invocation, such as in:
>
> #write(File,SomeMacro())
>
That sounds like a break in scoping rules.  It's not like the code is just
dropped inline as it is with c macros, though that's how it works with the
result.

Sounds like we need a proper function system in the new language.  Assuming it
ever takes shape.

but if you think that's bad, take a look at this little Gem, I found a few days
ago.

while ( --argc > - && (*++argv)[0] == '-' )
{
  for ( s = argv[0]+1; *s; s++ )
  {
    switch( *s )
    {
      default:
        usage ( progname );
        exit ( -1 );
        break;
    }
  }
}

Typing it out makes me want to go scrub my hands with steel wool.

Regards,
A.D.B.

> where `SomeMacro` might be part of a 3rd party include file that itself
> makes heavy use of file operations, e.g. to persist some random number
> generator's state across frames or the like.
>
> Most notably, `Parse_String` is implemented as a macro that uses `#write`.

Post a reply to this message

Am 03.03.2016 um 00:15 schrieb Anthony D. Baye:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 01.03.2016 um 23:08 schrieb Le_Forgeron:
>>
>>> ab-using code like
>>> #write( .... #write( ...
>>> is a call for lightning from Zeus and the opening of the multidimensional portal
for Chtulhu.
>>
>> Actually - no. There's no abuse in there /per se/. The nested `#write`
>> might be part of a macro invocation, such as in:
>>
>> #write(File,SomeMacro())
>>
> That sounds like a break in scoping rules.  It's not like the code is just
> dropped inline as it is with c macros, though that's how it works with the
> result.

Actually that's /exactly/ what it's like: Invoking a macro simply makes
the parser jump to the macro body, continue its parsing job there until
it reaches the `#` of the macro's `#end`, and then jump back to the
place where it left off.

The following, for instance, is perfectly legal:

    #macro CloseParenthesis()
        (
    #end
    #macro CloseParenthesis()
        )
    #end
    #write OpenParenthesis() File, ... CloseParenthesis()

Virtually the only thing you can't "drop in" with a macro are unbalanced
block directives (anything that ultimately requires an `#end`, because
these would interfere with the way a macro's end is marked), `#local`
directives (because macros open a new context for local variables) and,
IIRC, macro definitions (because nesting macro definitions is simply
forbidden).

Post a reply to this message

Le 02/03/2016 11:15, clipka a écrit :
> Am 01.03.2016 um 23:08 schrieb Le_Forgeron:
>
>> ab-using code like
>> #write( .... #write( ...
>> is a call for lightning from Zeus and the opening of the multidimensional portal
for Chtulhu.
>
> Actually - no. There's no abuse in there /per se/. The nested `#write`
> might be part of a macro invocation, such as in:
>
> #write(File,SomeMacro())
>
> where `SomeMacro` might be part of a 3rd party include file that itself
> makes heavy use of file operations, e.g. to persist some random number
> generator's state across frames or the like.

Ok, a counter cannot be used, but I hope you would agree that performing 
a write in a write *on the same file* is a bug.

Which mean the protection mechanism could be a (static) container of 
file (descriptor), push on entry of write as soon as value is parsed, 
popped on exit of write. And just before the push, search the container 
if already present... unless the container performs that check during 
the push for us.

Same goes for read during a read *on the same file*.

Or do you see a legit usage for such perversion ?

Post a reply to this message

Am 03.03.2016 um 13:09 schrieb Le_Forgeron:

>> Actually - no. There's no abuse in there /per se/. The nested `#write`
>> might be part of a macro invocation, such as in:
>>
>> #write(File,SomeMacro())
>>
>> where `SomeMacro` might be part of a 3rd party include file that itself
>> makes heavy use of file operations, e.g. to persist some random number
>> generator's state across frames or the like.
> 
> Ok, a counter cannot be used, but I hope you would agree that performing
> a write in a write *on the same file* is a bug.

Again I disagree.

Some people like to copy macros from .inc files to the main .pov file
for performance reasons.

> Which mean the protection mechanism could be a (static) container of
> file (descriptor), push on entry of write as soon as value is parsed,
> popped on exit of write. And just before the push, search the container
> if already present... unless the container performs that check during
> the push for us.
> 
> Same goes for read during a read *on the same file*.
> 
> Or do you see a legit usage for such perversion ?

No, I do not see a legit usage for the perversion you propose as a
solution :P

Really, think of it: You're proposing to introduce yet another stack
data structure, just to prevent a special case of nested "#write"
invocation. What about nested "#read" invocations? Do you want to add
yet another stack for that one? What about nested "#debug"? Nested
Whatthefuckever?

That's shooting sparrows with cannons, as we say in German.

There is no fundamental reason to disallow nesting of "#write" /except/
for call stack size. Note that this limit actually applies to the
nesting of /any/ directives. Exceeding this limit leads to a crash which
isn't desired, but there's a very simple and straightforward solution to
the problem: Just impose a more stringent arbitrary nesting limit, in a
way that leads to a more graceful failure.

Post a reply to this message