Op Tue, 30 Aug 2005 11:33:16 +0100 schreef Dave Korn in <[EMAIL PROTECTED]>: : ----Original Message---- : > From: Corinna Vinschen
[dropping NUL from strings returned by RegQueryValueEx] : > trailing \0. First, the \0 is part of the "file content" in a way. : : To me this is the even more important reason. Some registry strings do : include the trailing zero, some don't; I don't see how this could be. The (MS) windows API-reference (win32api.hlp) entry for RegQueryValueEx states (a.o.) | REG_EXPAND_SZ A null-terminated string that contains unexpanded | references to environment variables (for example, "%PATH%"). It will | be a Unicode or ANSI string depending on whether you use the Unicode | or ANSI functions. [...] | REG_MULTI_SZ An array of null-terminated strings, terminated by | two null characters. [..] | REG_SZ A null-terminated string. It will be a Unicode or ANSI string | depending on whether you use the Unicode or ANSI functions. [...] | If the data has the REG_SZ, REG_MULTI_SZ or REG_EXPAND_SZ type, then | lpData will also include the size of the terminating null character. : cygwin shouldn't tamper with it. And : it would seem _very_ wrong to me if by querying a value, and then using the : result returned to re-set the value, the value should change in length. If/when writing to the registry becomes a fact, closing the file should cause the terminating \0 to be added, IMO. : And since the patch unconditionally chops one off the size without : verifying whether or not the nul terminator is actually present, it would do : the wrong thing for some strings. No. (See above.) L8r, Buzz. -- ) | | ---/ ---/ Yes, this | This message consists of true | I do not -- | | / / really is | and false bits entirely. | mail for ) | | / / a 72 by 4 +-------------------------------+ any1 but -- \--| /--- /--- .sigfile. | |perl -pe "s.u(z)\1.as." | me. 4^re
