Reply to thread

Message: [QUOTE="Barry Schwarz, post: 2487397"] Your code does not compile cleanly. It is riddled with constraint violations, undefined behavior, and obvious logical errors. In the spirit of learning to walk before running, I suggest you start with simpler projects. If it doesn't compile cleanly, working is a forlorn hope. A non-standard header. We need to see it if we are going to help. Didn't your compiler complain about incompatible pointer types here? Even if u_int8_t is a typedef for unsigned char, pStr is not a pointer to this type. At each iteration of this loop, the pointer final is incremented to point some number of bytes further beyond the end of dummy. Since final no longer points to dummy or to any memory you have the right to write to, this invokes undefined behavior. Since final points to an integer type, why are you using character notation? You went to some trouble in the preceding while loop to have temp point one beyond the '\0' that terminates pStr. You have now lost that address and replaced it with the address of a string literal. You obviously don't care about the string literal either. temp now points to the start of the input string. Those of us with C89 compilers can't help you if you define objects after executable statements. This is a C99 feature. This also invokes undefined behavior. Even if you hadn't altered final in the while loop, it would still not point to an area large enough to receive a string of length greater than 0. Didn't your compiler complain here. The second argument to fgetpos must have type fpos_t*. Your code has type fpos_t**. What is the purpose of the first statement? offset is changed immediately. offset needs to be an int (see below). offset is a char. NULL could be defined as (void*)0. If so, this is another constraint violation. As your code stands now, there is no guarantee that EOF can be represented in a char. More undefined behavior. %u is for unsigned int. Your argument has type fpos_t*. buflen is a size_t. There is no guarantee that either EXIT_FAILURE or EXIT_SUCCESS can be represented as a size_t. Furthermore, you seem to think these values have some significance in relation to length of a buffer. They don't; though it might appear that way on your system. Another constraint violation. Don't cast the return from malloc. It can't help and could cause the compiler to suppress a diagnostic you would really want to see. More undefined behavior. strlen returns a size_t which will be unsigned but not necessarily int. %d requires a signed int. Why are you bothering to assign to automatic variables that will disappear after the next statement. Sorry, there didn't seem to be any point to going beyond these two functions. Remove del for email [/QUOTE]

Verification