Re: C string array problems (again)
- From: "Ralph" <nt_consulting64@xxxxxxxxx>
- Date: Sat, 10 Feb 2007 22:46:56 -0600
"mayayana" <mayayana1a@xxxxxxxxxxxxxx> wrote in message
news:3Omzh.478$Jl.134@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
outside
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
variablethe 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.
-ralph
.
- References:
- C string array problems (again)
- From: mayayana
- Re: C string array problems (again)
- From: mayayana
- Re: C string array problems (again)
- From: Ralph
- Re: C string array problems (again)
- From: mayayana
- C string array problems (again)
- Prev by Date: Re: Simple DBMS in VB
- Next by Date: Re: only last line in (Rich) Text box saving
- Previous by thread: Re: C string array problems (again)
- Next by thread: Re: ADO Data Control + Microsoft Support HELP
- Index(es):
Relevant Pages
|
