Thread: Why is this statement being skipped?

Look at this piece of code:

Code:

1071                    {
1072                            b = strchr(a, '\0');
1073                            finished = 1;
1074                    }
1075
1076                    strncpy(temp, a, (b-a));
1077                    strcat(temp, ""); /* add a null at the end */
1078
1079                    a = b + 1;
1080

When I was debugging the program I noticed that lie 1077 was being skipped for no reason at all.

Check out the GDB output:

1076 strncpy(temp, a, (b-a));
4: b = 0x5042b5 "/../test"
3: a = 0x5042b1 "test/../test"
2: simple_path = 0x5042b0 "/test/../test"
1: temp = '\0' <repeats 79 times>
(gdb) next
1079 a = b + 1;
4: b = 0x5042b5 "/../test"
3: a = 0x5042b1 "test/../test"
2: simple_path = 0x5042b0 "/test/../test"
1: temp = "test", '\0' <repeats 75 times>

Yes I did have the correct version of the program compiled...


On a side note:
when I'm dynamically allocating space for a string, which one of these pieces of code is correct?

Code:

new_string = malloc(strlen(old_string) + 1);

or

Code:

new_string = malloc( (strlen(old_string) + 1) * sizeof(char));

Originally Posted by TalonStriker

Code:

new_string = malloc(strlen(old_string) + 1);

or

Code:

new_string = malloc( (strlen(old_string) + 1) * sizeof(char));

it is better to go for the 2nd one as the size of a data type is not guranteed to be same on every system that you compile or use it

You do realize that the code

Code:

strcat(x, "");

doesn't actually DO ANYTHING, don't you? The reason is that strcat() searches for the end of the string (NUL character), then appends the string. But since the string is empty, all it would actually do is replace the NUL that it found with the new NUL that came from the empty string. Since all NUL's are equal, there is no point in replacing one with another - it won't change anything.

If you want to guarantee that there is a NUL on the end of your string, you CAN NOT use strcat to achieve that, because strcat itself relies on the NUL being there. You could do

Code:

temp[b-a] = 0;

By the way, if you want to find the end of the string, using strchr() is most likely less efficient than:

Code:

b = &a[strlen(a)];

THis is because strlen() is one of the more frequent string operations, and it's much more likely to be highly optimized than any other string operation. strcpy and strcat are obviously also very frequent and highly optimized, but neither really does what you want here.

--
Mats

Originally Posted by robatino

> it is better to go for the 2nd one as the size of a data type is not guranteed to be same on every system that
> you compile or use it

sizeof(char) is guaranteed to be 1 byte by the Standard, so portability is not an issue (the number of bits IN a byte, on the other hand, is implementation-defined, but malloc() doesn't need to know about that).

I dont know if its standard to be 1 byte on all systems or not..
as I am not sure.. I always use sizeof() for all that stuff..
I am sure this cant be wrong

Originally Posted by gibsosmat

I dont know if its standard to be 1 byte on all systems or not..
as I am not sure.. I always use sizeof() for all that stuff..
I am sure this cant be wrong

Indeed it's never WRONG to use sizeof(char) - but it's GUARANTEED by the C standard that a char is of size 1 - whatever size 1 means is up to the implementation - technically, it could be 16 bits, 9 bits, 7 bits or any other number of bits. Commonly it is 8 bits. But the only thing that is guaranteed is that "sizeof(char) == 1".

--
Mats

hmm..
ok.. I will use it to be one..

http://c-faq.com/malloc/sizeofchar.html

Writing
p = malloc ( numRequired * sizeof *p );
always works, and saves you having to remember what to do. Plus, if the type of p changes, it will continue to do the right thing!

The problem with thinking "oh, it's a char, therefore I can leave the sizeof off" is that sooner or later, you'll make the wrong choice and then start to ponder the nature of the random crashing.

Writing good code is in part adopting styles and habits which are less error prone than other approaches (like always using braces even when they might be considered optional).

The point the link makes about introducing a size_t is interesting (I have some code where I explicitly cast one of the terms to size_t to make sure the argument is calculated correctly, so I should have thought of it). But doesn't this mean that the sizeof() should always be the first term in the expression, to make sure the whole thing gets evaluated as a size_t, instead of the last, which is conventional? For example, if n1 and n2 are type int, then

Code:

p = malloc(n1 * n2 * sizeof *p);

would first evaluate n1 * n2 as int, since multiplication associates left to right, and possibly overflow. Putting the "sizeof *p" first makes the whole thing evaluate as size_t.

Edit: Of course, with size_t, overflow is still possible, but at least it won't happen unless the value won't fit in a size_t, in which case the allocation would be impossible anyway.

I was going to agree with you, then I tried this and got the right answer with gcc and VC6.

On the face of it, a*b should overflow.

Code:

#include <stdio.h>
#include <stdlib.h>
int main (int argc, char** argv)
{
    short int a = 0x4000;
    short int b = 0x0010;
    size_t    c = a * b * sizeof a;
    printf("&#37;lx\n", (unsigned long)c );
    return 0;
}

$ gcc foo.c
$ ./a.exe
80000

I don't know whether this is just implementation luck, or whether there is some rule which states that a sequence of identical operations are automatically cast to the largest type to begin with.