Prev: VB6 vs DirectX
Next: VB6 - Vista - Mouse wheel
From: Ralph on 10 Feb 2007 23:46 "mayayana" <mayayana1a(a)mindspring.com> wrote in message news:3Omzh.478$Jl.134(a)newsread3.news.pas.earthlink.net... > > > > I got this working finally, but I gave up > > > on the char ** var approach. I think that > > > one problem may have been an odd > > > quirk in the MS code: They had declared > > > a char [256] string inside a loop and I > > > assumed that meant it was going out of > > > scope and being re-initialized with each loop. > > > Not so! Characters copied to the string in > > > one iteration were still there in the next. > > > I needed to clear the variable with nulls on > > > each iteration. So why did they declare it > > > inside the loop? I don't know. > > > > > > > "loops" in C are blocks. Anything declared in a block is not valid outside > > the block. It looks like 'scope', but is slightly different. The variable > > would never be "automatically" anything - little in C ever is. <g> > > > > Would have to take a look a the original code to see what was meant. > > > > I don't want to wander off too far into a C++ > discussion, but this has me curious. The code > goes like this: > > for (i = 0; i < num_files; i++) > { > char stripped_name[256]; > char spath[256]; > strset(stripped_name, 0); > strset(spath, 0); > > strncpy(spath, sPathsIn + i2, sizes[i]); > i2 += sizes[i]; > i2++; > > MessageBox(NULL, spath, "spath op", MB_OK | MB_ICONINFORMATION); > ------------ > > When I first ran the code, before adding the strset > lines to clear the char variables, the cab creation > failed, unable to find a file. The message box showed > first file: > > C:\........wed1-31.txt > > second file: > C:\........fri2-2.txtt > > Then it failed. I realized that the second path had > overwritten the first path, even though the declare > of spath is inside the "For block". Since the second > path was one character shorter, it had a "t" appended. > > The Microsoft code had the declare for stripped_name > inside the "For block", so I assumed they did that because > the variable would clear with each iteration. > (The spath declare is mine.) > > Well you are talking about two separate items here. (I wish you had show the original code.) As noted variables declared in a block (delimited by curly braces) are only valid within that block. True ANSI compilers will return an error if they are used outside the block - earlier compilers may not. They are defined on the stack and their lifetime is controlled by the function block. There are two main reasons for doing this. 1) It makes code a bit more readible by declaring and using variables only where they are needed. 2) It aids the compiler to optimize conditionals. The behavior you describe is exactly what one would expect from strncpy. If the destination string is larger than the source string, then the chars are replaced and no terminating nul is added. Thus any left-over chars up to the original nul char are still there. Considering the fact that stripped_name is just a buffer, and with an auto variable the actual contents are always unknown - it doesn't make much sense to use it in the context you have suggested. Hard to believe it ever worked in the first place. Equally hard to believe any C programmer would write such code. But we would need to see the original code to know what was really suppose to happen. Your patch appears to resolve the problem. You are using some interesting convoluted arithmetic. -ralph |