Bug : LVRT ini file pollution/corruption... (leaves me speechless)

[Ben]

When you get to the point where you are controlling and monitoring thousands of I/O points across multiple platforms, the power will show itself.

Ben

[rom1nux]

Hello Ben,

When you get to the point where you are controlling and monitoring thousands of I/O points across multiple platforms

Lol...You can get a Ferrarie, with a beautifull engine and lot of horst power, if you get squared wheels you not got so far men... 😉.

Best regards

Rom1nux

[Ben]

---

@rom1nux wrote:

Hello Ben,

When you get to the point where you are controlling and monitoring thousands of I/O points across multiple platforms

Lol...You can get a Ferrarie, with a beautifull engine and lot of horst power, if you get squared wheels you not got so far men... 😉.

Best regards

Rom1nux

---

I have been coding in LabVIEW long enough to "know how to change a tire".

I seldom use the tires recomended by NI.

Ben

[rom1nux]

Hello,

Yes you got right, i'm programming C long enougth to change tires too.. but in this case supplier have solde the screew(using main ini), and put something in car that flat the tire(file corruption)...and he say :

"left flated tires on the car, it's not important, you need to mount another tires set if you want your car can roll...what ?...8 wheels(4rth flat)...yes this is normal....this is the power men !..." (ie: change the ini file name) 🙂

yes i'm quiet exagerating 🙂

Rom1nux

[nathand]

I'm having a lot of trouble understanding what you're trying to say, but I'm curious about it... can you post your corrupted INI file?  I do not understand why adding an additional section header should mess up your INI file.  Just adding [LVRT] on a line by itself should not cause problems unless you are not reading the INI file format properly.

[Ben]

---

@nathand wrote:

I'm having a lot of trouble understanding what you're trying to say, but I'm curious about it... can you post your corrupted INI file?  I do not understand why adding an additional section header should mess up your INI file.  Just adding [LVRT] on a line by itself should not cause problems unless you are not reading the INI file format properly.

---

I suspect that is the issue.

The format used i the OP's code is different than the industry standard.

Ben

[rom1nux]

Hello Nathand,

My reproductible source "acquirelvrt.c" show nidaqmxbase takes over(replace a part of) the low level I/O file primitive (fread/fwrite/fprintf & co) access to execute obscures operations (like adding "[LVRT]" & other)

In my real code i use an enhenced .ini file format with big line and quoted string, and specifique part.

This part is not writed correctly (non drawable char & co) when my executable is linked with nidaqmxbase, if not all work correctly.

Look at the sample that show nidaqmx "hook" the low level I/O file access and you understand why i'm scary...

Best regards

"acquirelvrt.c"

[nathand]

THERE ARE NO HOOKS TO FUNCTIONS IN THE FILE IO.  There is no performance problem.  One of the DAQmx Base functions actually opens, writes, and closes the INI file with the name matching your executable.  Due to the format of an INI file, that function must read the entire file, make changes in the section it needs, and write out the entire file.  If you start using non-standard extensions to the INI file format, you may run into problems.  If you must use a non-standard format, you should use an ini file with a different name or different extension.

[rom1nux]

Hello Nathand,

THERE ARE NO HOOKS TO FUNCTIONS IN THE FILE IO

Ok ok, this is clear, There is no performance problem, understood and closed subject, thanks for confirm this point

One of the DAQmx Base functions actually opens, writes, and closes the INI file with the name matching your executable.

hum, Interesting...i assumed this. thanks you for confirm this point cleary too .

Can you tell me where can i found a documentation about this ini support ?

If you start using non-standard extensions to the INI file format, you may run into problems.

ok, i understood now, after tests i can confirm that internal DAQmx Base function cannot handle

- Duplicated key (where key=value) : the last is keep

- Duplicated section (where a section is [section]) : all subkeys are mixed

- Bloc data (multiline bloc only delimited by section header ) : disappear

- Line upper than 32K : create buffer overflow when rewrite

- Comments : disappear

Thanks for clear confirmation, thanks for efforts to understand my bad english

Best regards

[nathand]

---

rom1nux wrote:

One of the DAQmx Base functions actually opens, writes, and closes the INI file with the name matching your executable.

hum, Interesting...i assumed this. thanks you for confirm this point cleary too .

Can you tell me where can i found a documentation about this ini support ?

---

Sorry, I have not seen documentation about this; I've just seen similar behavior from years of using NI software.  It likes to have an INI file available for settings.