Jump to content

Reentrancy bug in Write Key (Variant) VI?


Recommended Posts

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).

writekeybug.png

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.

Link to comment

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.

Link to comment

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"?

Link to comment

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.

Link to comment

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?

Link to comment

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.

Link to comment

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).

post-17-0-60145700-1315675702_thumb.png

Link to comment

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

post-17-0-60693800-1315716650_thumb.png

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.

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.