Match Regular Expression not allowed with inlining, why?

[TiTou]

Anyone knows why the "Match Regular Expression" primitive is not allowed in a VI on which you enable inlining?

match regular expression

[GerdW]

Hi Antoine,

MatchRegEx uses the (3rd party) PCRE library as written in the LabVIEW help.

I guess that's the reason why it is not allowed for inlining: is that library thread-safe, does it allow for reentrancy, other possible reasons?

[wiebe@CARYA]

I see is no reason for this.

The XNode contains nothing that can't run in an inlined VI. You can literally copy paste the generated XNode code in an inlined VI, and it works.

The DLL is thread save, and doesn't run in user thread. Even if it did, it would run in an inlined VI.

I use a reg.ex. as a subVI all the time. This VI is based on the XNode, but isn't an XNode. It returns the outpus as an array. This was the reason to make it, an array is often more convenient than a resizable function.

In it, I put a note to myself:

NOTE: The dll uses string handles. This will sometimes result in unexpected results (empty strings\crashes) when this VI is run without caller.

Not sure if the string handles are the cause of this, but it was funky.

The XNode has the same interface, and inlining it in a VI basically makes it run without a caller when the inlined VI is run. Perhaps that is why they marked the function as unsafe for inlining?

Anyway, feel free to use the VI. It's on Github:

https://github.com/Carya-Automatisering/Configuration-File-Library/tree/master/Carya%20Config/SubVIs

You might want to set it to run reentrant. That makes sense. Not sure why I didn't. It might crash. 

[wiebe@CARYA]

9: 1 vi2InlinableDiagram: Typeprop says this VI's diagram is safe to Inline (used to be vi2ObjIDChgOK)

The flag says it's save to inline... Not sure why it isn't possible.

[BertMcMahan]

I ran across this today... interestingly enough, you CAN use "Search and Replace String" with "Regular Expression" mode on. It appears to use the same library.

[wiebe@CARYA]

---

@BertMcMahan wrote:

I ran across this today... interestingly enough, you CAN use "Search and Replace String" with "Regular Expression" mode on. It appears to use the same library.

---

I'm sure there's no need for this restriction... Just like expression nodes and property nodes and invoke nodes.

I often use a VI that uses the same dll (plug), but it returns an array of results. This can be more convenient sometimes. This VI does work in a .vim.

[paul_cardinale]

---

wiebe@CARYA wrote:

---

@BertMcMahan wrote:

I ran across this today... interestingly enough, you CAN use "Search and Replace String" with "Regular Expression" mode on. It appears to use the same library.

---

I'm sure there's no need for this restriction... Just like expression nodes and property nodes and invoke nodes.

I often use a VI that uses the same dll (plug), but it returns an array of results. This can be more convenient sometimes. This VI does work in a .vim.

---

Allowing property nodes and invoke nodes in inlined VIs would would create a big hole in the already-weak password protection for block diagrams.

[BertMcMahan]

Forgive the off topic request but Paul could you expound on why that is?

[wiebe@CARYA]

---

@BertMcMahan wrote:

Forgive the off topic request but Paul could you expound on why that is?

---

I'm drawing blanks here too...

[paul_cardinale]

---

@BertMcMahan wrote:

Forgive the off topic request but Paul could you expound on why that is?

---

The LV password protection is a lock, not an encryption.  You can't get to a PW protected BD because the IDE respects the lock and won't let you in.  But a VI always has access to its own BD, even if it's PW protected (essentially that VI is inside the secured area).  When you inline a VI, that VI's code becomes part of the owning VI's BD.  If property & invoke nodes were allowed, then an inlined VI could access the owner's BD, even if it were PW protected.  Thus to break into a BD, you would only have to find a VI that's called by it, temporarily replace that VI on disk with a like-named inlined VI that opens the BD, then run the protected VI and voila, the BD opens.