Thread: Weird errors

If it's not returning -1, it's not actually entering the catch blocks. The fact it continues on with the function after that is proof. It's going past the try...catch successfully, meaning no exception was thrown.

Also, unless your compiler has a switch to catch access violations as C++ exceptions, there's nothing which can generate an exception, it's all memory copying which is guaranteed not to throw a (C++) exception. Even if you can tell your compiler to catch an access violation, you'd need to catch with a catch(...), so the catch statements you have are useless, they'll never actually catch anything. Those catch statements are effectively unreachable code, in fact your compiler may have completely removed them.


Whatever your bug is, it's not in the code you pasted.

And yes, the bug is in your code somewhere, but it's not in the code you listed.

thats the thing, i could use standard defined ones but that would be much slower, this is a strlen and strcpy in one and the whole application is based on speed.

Again, premature optimization is the root of all evil (Hoare, Knuth). (Think I'll need to dump this in my sig sometime.) For all you know, the strlen() and strcpy() provided by your compiler libs might be implemented in pure optimized assembly, tuned to the last clock cycle by tens of developers with years of experience in assemblers and compiler design. For all you know they are written as seperate micro-functions to fit completely into your platform's pipeline cleanly so as not to require additional instruction fetches by the processor. For all you know...

First profile (to the millisecond) strcpy and strlen running 1,000,000 times each in adverse conditions, also profiling the kernel, cache, swap and other side-effect processes. Then repeat for various optimization levels of your compiler and for various target platforms. Then profile your entire application to see if the bottlenecks are in these functions. Then, and only then, do you go to the trouble of coding your own buggy, less-portable replacements.

you might think that with buffer+=3, i have a overflow but thats not. bufptr points to the very beginning of a large large array of chars named buffer.

How large? This large? This large? This large? Can you be sure that the buffer is large enough? What if a user (including other processes and automated clients) enter a very large string for one of the fields? Why not just use std::string, which is all fast, easy and safe? I think there are some fundemental doo-wizzahs about your overall code design.

Which compiler are you actually using?

I've tried your code with 3 compilers (gcc, vc6, vc7) and I don't see the effect you're seeing.

I see that -1 seems "special" in microsoft compilers, so that may be confusing you.

With different return results, I see very different paths. The "jump" to what looks like an exception eventually leads to the return 0, which I figure is the "there is no exception" code being executed.

Code:

#include <iostream>
using namespace std;

	inline int my_strcpy(char* source, char* target){
		int counter(0);
		while (*target!=0){
			*source++=*target++;
			++counter;
		}
		*source = 0;
		return counter+1;
	}

struct x {
    char ServerName[10];
    char MapName[10];
    char Game[10];
    char GameType[10];
    unsigned short PlayerCount;
    unsigned short MaxPlayers;
};

int foo ( char *bufptr, x *target ) {
		try{
			bufptr += my_strcpy(target->ServerName, bufptr);
			bufptr += my_strcpy(target->MapName, bufptr);
			bufptr += my_strcpy(target->Game, bufptr);
			bufptr += my_strcpy(target->GameType, bufptr);
			bufptr += 2; //Skip appid because it is no use to us
			target->PlayerCount = static_cast<unsigned short>(*bufptr++);
			target->MaxPlayers = static_cast<unsigned short>(*bufptr++);
			bufptr+=3;
		}
		catch (std::bad_alloc&){
			return -2;
		}
		catch(void *){
			return -3;
		}
    return 0;
}

int main ( ) {
    return 0;
}

// VC6 ASM
// cl /Fafoo.s /GX foo.cpp
; Line 32
	mov	eax, DWORD PTR _bufptr$[ebp]
	add	eax, 3
	mov	DWORD PTR _bufptr$[ebp], eax
; Line 34
	jmp	SHORT $L7372
$L8456:
; Line 35
	mov	DWORD PTR $T8453[ebp], -2		; fffffffeH
	mov	eax, $L8458
	ret	0
$L8458:
	mov	eax, DWORD PTR $T8453[ebp]
	jmp	SHORT $L7371
$L8457:
; Line 38
	mov	DWORD PTR $T8454[ebp], -3		; fffffffdH
	mov	eax, $L8459
	ret	0
$L8459:
	mov	eax, DWORD PTR $T8454[ebp]
	jmp	SHORT $L7371
$L7372:
; Line 40
	mov	DWORD PTR __$EHRec$[ebp+12], -1
	xor	eax, eax
$L7371:
; Line 41
	mov	ecx, DWORD PTR __$EHRec$[ebp+4]
	mov	DWORD PTR fs:__except_list, ecx
	pop	edi
	pop	esi
	pop	ebx
	mov	esp, ebp
	pop	ebp
	ret	0

// VC7 ASM
; Line 32
	mov	eax, DWORD PTR _bufptr$[ebp]
	add	eax, 3
	mov	DWORD PTR _bufptr$[ebp], eax
	jmp	SHORT $L9570
$L9571:
; Line 35
	mov	DWORD PTR $T9568[ebp], -2		; fffffffeH
	mov	eax, $L9574
	ret	0
$L9572:
; Line 38
	mov	DWORD PTR $T9569[ebp], -3		; fffffffdH
	mov	eax, $L9576
	ret	0
$L9570:
; Line 39
	mov	DWORD PTR __$EHRec$[ebp+12], -1
; Line 40
	jmp	SHORT $L9575
$L9576:
; Line 38
	mov	eax, DWORD PTR $T9569[ebp]
	jmp	SHORT $L8439
$L9575:
; Line 40
	jmp	SHORT $L9573
$L9574:
; Line 35
	mov	eax, DWORD PTR $T9568[ebp]
	jmp	SHORT $L8439
$L9573:
; Line 40
	xor	eax, eax
$L8439:
; Line 41
	mov	ecx, DWORD PTR __$EHRec$[ebp+4]
	mov	DWORD PTR fs:__except_list, ecx
	pop	edi
	pop	esi
	pop	ebx
	mov	esp, ebp
	pop	ebp
	ret	0

PS
Your English seems pretty reasonable to me

The dude was commenting on your spelling, not english in general. Just don't try to be l33t, c00l or vry bsy n huried.

You should make it a point to write safe code and make as few assumptions as possible. If you use a fixed size buffer, make sure you don't try put in more than a fixed number of characters. Simple as that, but my_strcpy() seems to have a different agenda. C/C++ is very helpful in allowing you to trip up on seemingly trivial things, so it's really really important that you get things right the first time and not take any "shortcuts".