Menu
▾
▴
[NSIS-Bugs] [ nsis-Bugs-3296051 ] strings too short (1KiB), need more than 10KiB
|
From: SourceForge.net <no...@so...> - 2011-05-03 12:54:53
|
Bugs item #3296051, was opened at 2011-05-02 09:39 Message generated for change (Comment added) made by anders_k You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=373085&aid=3296051&group_id=22049 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Scripting Group: 2.0 Series Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Michaels (jmichae3) Assigned to: Nobody/Anonymous (nobody) Summary: strings too short (1KiB), need more than 10KiB Initial Comment: 2.46 It has already been stated on a web page that the maximum string size compiled into NSIS is 1K. the maximum size for XP SP3 is 8190 characters for the command-line, and I assume it is the same for important environment variables like PATH, which is something a lot of people want to modify, and this requires string manipulations. **SAFE** string manipulations, ie implying not destroying the string partially during an operation due to NSIS truncation. which are not possible if the string size is not longer than the string you are adding (the string you are adding[could be 1K-2k] + the original string (which is 8KiB at least). a safe value for string length is 2x8KiB or 16KiB=16384 bytes, unless the maximum number of characters for the cmd shell in windows 7 or 8 is actually longer than 8KiB, in which case you should increase that accordingly and double it. you can always chop things off yourself, but you can't handle NSIS truncation programmatically that I know of without calculating the length of the string (would be a nice feature to add "StrLen"). jmi...@ya... ---------------------------------------------------------------------- Comment By: Anders (anders_k) Date: 2011-05-03 14:54 Message: Of course NT has a limit, it is 32k in total, MAX_PATH for each path element IIRC NSIS already has a large string build you can use. We don't support the \\?\ prefix so talking about long filesystem paths is pointless. IMHO http://nsis.sourceforge.net/Path_Manipulation is unsafe and could destroy long %PATH% variables. It is funny that you bring up Win9x and long paths in the same post since the really long path support only works for unicode api's and those don't work on Win9x. Switching to dynamic strings would break every plugin. Also, every StrCpy operation would require a out of memory check. You probably don't want that much error checking in your script... ---------------------------------------------------------------------- Comment By: Jim Michaels (jmichae3) Date: 2011-05-03 09:04 Message: define "waste". filepaths that include the virtual store on windows 7 can get pretty long. there is no depth limit that I know of on windows NT family OS's. If you are dealing with that, chances are you need that extra 2K to be safe. it' a good round number. does http://nsis.sourceforge.net/Path_Manipulation use this? because if it doesn't, why are you telling me this? I wouldn't know how to use it. is this some sort of kernel32.dll call that is specific to windows NT family systems? some of my targets are windows 9x machines. another possibility is to make the move to dynamically allocated/reallocated resizeable strings on a heap, instead of compiling in a fixed array size. or at least make it huge enough and handle it properly enough that it's not going to be a problem. be inventive. If this is written in C, have you ever heard of the C++ <string> template? it's dynamic. it's not really flexible, but you can build on it using the BOOST library (which I have successfully compiled using mingw-w64). see http://JesusnJim.com/code/compilers/mingw.html for a boost library building zip file set. ---------------------------------------------------------------------- Comment By: Anders (anders_k) Date: 2011-05-03 02:08 Message: 10k for every string would be a big waste. What you need to do is to use the system plugin and call the lstr* api's directly when you need to create a path string for the registry... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=373085&aid=3296051&group_id=22049 |