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