bug Reentrancy bug in Write Key (Variant) VI?

[Stobber]

I've been playing around with the variant configuration palette this week, and I think I found a bug in the Write Key (Variant) VI. The VI will insert escape characters into the section and key name strings to conform with INI file syntax. I've noticed, though, that if I use a file path as the name of a section that holds a cluster, it inserts multiple escape characters at each point, instead of just one. The image below explains it (hopefully).

It looks like this bug only shows up when two conditions are met:

1. The section name contains escaped characters, like ‘\’. My section names are file paths to .lvclass files.

2. The variant key contains a cluster or an array of unknown type, causing the VI to be called reentrantly.

Since the VI has to be called reentrantly, I haven't thought of a workaround yet. (Well, I guess I could restructure my file to stop putting paths into the section name, but I'd rather not have to.)

I can think of two approaches to fix it, though. One is to add logic that counts the recursion in the VI and ensures that only the first instance executes the Encode subVI. Another is to encapsulate the multiply executing logic into a reentrant subVI, leaving out things like the Encode subVI so they're only called once from the main Write Key (Variant) VI.

[GregSands]

Yes, I'd noticed that too. A fairly easy way to fix it would be to pass the unencoded strings into the recursive calls, rather than the encoded ones.

It does seem a little unusual that this VI was written to be called recursively - I would have thought that creating a queue of keys would be a simpler way to go, though perhaps a little more overhead in the case of only having a single key.

[Ed Dickens]

Good catch. We'll look into it and post an update.

[Ed Dickens]

I've been playing with this a bit and I am able to duplicate your issue. A cluster of clusters as the "key-value" increases the number of extra slashes added to the Section name.

However the "Read Key (Variant).vi" still handles reading all the extra slashes correctly.

Can you give us a use case where the extra slashes are causing an issue?

Do you have a need to read the config file with something other than the "Read Key (Variant).vi"?

[Stobber]

I'm trying to write an abstract class for serializable (to disk) objects, and I'd hoped to use the open-g VIs to do it. One design constraint is that I want to be able to write an object description by hand or from another application/language, given prior knowledge of the object (from a design document, etc.). If the number of escape characters in the section name varies, that becomes a lot harder to do.

[Ed Dickens]

I'm trying to write an abstract class for serializable (to disk) objects, and I'd hoped to use the open-g VIs to do it. One design constraint is that I want to be able to write an object description by hand or from another application/language, given prior knowledge of the object (from a design document, etc.). If the number of escape characters in the section name varies, that becomes a lot harder to do.

Just to make sure I understand, you are looking to be able to write the INI file by hand that will define the cluster?

[Stobber]

I think so, yes. I haven't seen another general-use serialization class floating around NI or LAVA, so I thought I'd make my own. This is mainly a thought exercise. If it pans out well, I'll probably try to use this base class in some side projects to see how I like it.

[Jim Kring]

I would definitely call this a bug. How I typically deal with such things is to create an argument called "in recursive call?" and warn the user to leave it unwired, but wire up a TRUE whenever calling it recursively. If this input needs to be hidden (which is probably a good idea), then the actual recursive VI can be moved into a private subVI with the public VI being a thin wrapper around the private, recursive subVI that only passes through all the inputs/outputs (except for the private "in recursive call?" input).

[Ton Plomp]

I'm not sure but what is call stack of a recursive VI? Wouldn't that show the same VI name (except for the instance number)?

So we can autodetect it's in a recursive call.

Ton

[Jim Kring]

I'm not sure but what is call stack of a recursive VI? Wouldn't that show the same VI name (except for the instance number)?

So we can autodetect it's in a recursive call.

Ton

I think that "call stack" means the "call chain" -- if the caller's name is the same as the current VI's name, then it's recursion.

I threw a small VI together that does this:

Recursive Call.vi

Perhaps this could be a useful OpenG VI. Note that it should probably be improved to test for A >> B >> [C >> [..]] A recursion (by checking for the callers name in any location in the call chain), rather than just A >> A recursion (by only comparing the caller with the caller's caller).

My guess is that passing in a parameter indicating that it's a recursive call is probably a bit faster than programmatically inspecting the call chain.

[Ed Dickens]

For some reason, I'm no longer getting emails about replies to this thread. Not sure sure why, it shows I'm monitoring it.

I like the "in recursive call?" terminal option, but in the case of using a path for a section name (or anything that already has a '\' in it) the section name will still end up with double slashes in the config file. Though this is probably needed due to the '\' being the ini file escape character. But at least it would be predictable.

[Stobber]

Hey Ed. Double slashes are good; as you said, they're part of the INI syntax. Triple, quadruple, etc. slashes are bad, and that's what's showing up in the VI's output right now.

[jgcode]

You can track this bug here: ID: 3409853