views:

53

answers:

2

Background: I am receiving a array as char* as a part of socket session. Now we have to match the Tokens (HTTP headers) out of it.Code here is that we have created a UBYTE* and getting the value from the char array after typecasting with UBYTE. Later same UBYTE pointer we are passing to other function which accepts char* after typecasting it to char*.

Problem here is this works in release build and not in debug build (with -g and different optimization). Not only this adding few prints in debug mode hide the problem.

So my queestion here, What is the difference between UByte pointer(which is essentially a unsigned char) and char pointer. Changing UByte to char is solving my problem in all modes but I dont have any explaination for the same? Any thoughts ?

+2  A: 

There is nothing wrong with casting between char * and unsigned char *. If you're getting unexpected behavior which varies depending on optimization levels, there's certainly a bug in your code, but it probably has little to do with discarding signedness in the cast.

Aside from that, UBYTE is a pretty ridiculous typedef since there exists a standard C type, uint8_t, which is identical and defined in stdint.h.

R..
@R., a little correction, existence of `unit8_t` is enforced by POSIX, not by C.
Jens Gustedt
C guarantees it exists if an 8bit integer type exists. If no 8bit type exists, then it's also impossible to define your own "UBYTE". Since this question is about processing HTTP headers, the target is almost surely platforms equipped to deal with network data units (bytes). `CHAR_BIT!=8` is really a pathology not worth mentioning. It will never occur except on DSPs and grandfathered-in legacy machines which will never be targets for portable programs.
R..
@R, that they named it UBYTE does not imply that it has the width of 8. It only shows what they expect it to be.
Jens Gustedt
If it doesn't have a width of 8, then naming it "UBYTE" is 1000x more brain-damaged than I already thought it was...
R..
A: 

Perhaps you could explain in the first place, why you though you had to use an unsigned char in the first place? And what doesn't work means?

void*, char* and unsigned char* have different semantics and you should use them according to that:

  • void* points to unspecific data with which you can't do anything unless you cast it to some real type
  • char* unfortunately has two different meanings, either as text string, or as unspecific data but which may be addressed (patched) at a low (byte) level
  • signed char and unsigned char are small width integers on which you want to perform arithmetics
Jens Gustedt
why I choose to use char * is to use a same data type through out. Function 1 Calls function2 (passing char* parameter).Function 2 copies it to local Ubyte*.Function 2 calls Function 3 (which accepts char*).So In my Opinion function2 acts as a pass through from Function1 - Function3 and unnecessarily changes it to UBYTE adding overhead of typecasting or referencing/de-referencing the pointers.PS: I dont see any logical problem with my Code as the current code works in both release (O2) and debug (O3,g) + extra prints in problematic function.
Aryan
@Ayan, my question was rather why someone uses this weird `typedef` `UBYTE`. AFAICS It makes not much sense here. To your statement that your are satisfied that the production code works, you simply shouldn't. If some compilation options provoke a fault of your program, most likely there is a severe bug somewhere. What I tried to indicate here is that you should not cast signedness back and forth without a reason. Semantics of `for` loops e.g can drastically change when having false assumptions about the loop counter. But since we don't know much more of your program, you are on your own.
Jens Gustedt
Thanks Jen for replies and insight.Just to make myself clear, its not I am satisfied or so. I have with me old written code where people over the time has changed it on their comfort.With Production Code, I meant there is no logical problem with the Parse functions as it is being running for so long.I am just trying to figure out the rational difference between Char* and UBYTE*.Probably I am wrong sticking to it only and should look into some other aspects of code. :-(
Aryan
@Ayan, I imagine that it is difficult to find out something in such a setup. But if you are supposed to clean up that code, starting with more reasonable type scheme would be a good idea. If seen a lot of nasty bugs disappear just by tidying code in that way. Good luck in any case.
Jens Gustedt