From: Ralph on

"mayayana" <mayayana1a(a)> wrote in message
> > > 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
> > the block. It looks like 'scope', but is slightly different. The
> > 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.


First  |  Prev  | 
Pages: 1 2 3 4
Prev: VB6 vs DirectX
Next: VB6 - Vista - Mouse wheel