Forums Feature Suggestions addition &binvar support

Reading an earlier post, I had the idea that since &binvars can be filled with plain text (not binary), it would be nice to be able to use /echo and /action and /msg (etc...) to display a &binvars information. Another use for this type of addition would be:

Since hashtables can store binary data, I could store picture within the table and whatnot, so it would be nice if you could use the /draw commands with &binvars. Meaning, instead of doing /drawpic and having to pass a <filename> parameter to it, I could store all my pictures in a hash table, dump them into &binvars and then /drawpic &binvar instead of <filename>. Thanks

I'm in full support of both ideas. (As per my earlier post)

It would be nice if more commands could use &binvars natively, thus allowing it to handle unparsed data that is neither stripped of padded spaces or evaluated in any other way.

I also really like the idea of /drawpic and other File Commands supporting &binvars in lieu of reading from a file, such as /background and /dialog icons. I would like to even see commands like /write /writeini $read $readini $lines, etc all support &binvars in place of a filename. This would be a VERY cool advancement for &binvars, allowing them to quite possibly replace standard %vars in many MANY uses.

- Raccoon

PS. We also need regular expression support for &binvars. $bregex() please. (also KEEP $hregex() if you would.)

Well there is a problem with a $bregex... PCRE doesn't support using regex on binary data. PCRE uses character strings for its data. A character string can not contain the character 0 (NUL) but binary data can.

I presume that means that mIRC's implimentation of RE is based on PCRE and not PerlRE? It seems hard to justify a function written in C that doesn't support the processing of a NUL character, yet has no problem with newline.

- Raccoon

mIRC uses PCRE, it clearly states this, "Regular expression support is provided by the PCRE library package, which is open source software, written by Philip Hazel, and copyright by the University of Cambridge, England."


Well this leads me to believe you don't know how C handles strings. Reading a string passed a NUL character is illegal, it has undefined results because you are reading from memory that is not part of the actual string (a NUL character signals the end of a string). The method of correcting this involves knowing the length of the actual string, but this can be problematic. If the user specifies an incorrect length ie, one that is longer than the actual length, it can again result from reading invalid memory. As for \n, C has NO special handling for \n. There would be no reason whatsoever for there to ever be any problems with \n, \n is a legal character in a string, \0 is not.