Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Strange behaviour

Reply
Thread Tools

Strange behaviour

 
 
gamehack
Guest
Posts: n/a
 
      04-25-2006
Hi all,

I've been testing out a small function and surprisingly it does not
work okay. Here's the full code listing:
#include "stdlib.h"
#include "stdio.h"

char* escaped_byte_cstr_ref(char byte);

int main (int argc, const char * argv[])
{
char* t = escaped_byte_cstr_ref('!');
printf(t);
free(t);

return 0;
}

char* escaped_byte_cstr_ref(char byte)
{
char buff[3];
sprintf(buff, "%X", byte);

char* str = malloc(4);

str[0] = '%';
str[1] = buff[0];
str[2] = buff[1];
str[3] = 0x0;

return str;
}

The program does not print anything - neither in bash nor in gdb.
Although I do remember getting it running on XP with migw(currently I'm
testing on OS X).

Thanks for your help,
gamehack

 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      04-25-2006
gamehack wrote:
> Hi all,
>
> I've been testing out a small function and surprisingly it does not
> work okay. Here's the full code listing:
> #include "stdlib.h"
> #include "stdio.h"
>
> char* escaped_byte_cstr_ref(char byte);
>
> int main (int argc, const char * argv[])
> {
> char* t = escaped_byte_cstr_ref('!');
> printf(t);


printf ("%s\n", t);

Otherwise you don't flush stdout.

--
Ian Collins.
 
Reply With Quote
 
 
 
 
Andrew Poelstra
Guest
Posts: n/a
 
      04-25-2006
gamehack wrote:
> Hi all,
>
> I've been testing out a small function and surprisingly it does not
> work okay. Here's the full code listing:
> #include "stdlib.h"
> #include "stdio.h"
>


To ensure that you are using standard headers and not ones in your
working directory, use
#include <stdio.h>
#include <stdlib.h>

> char* escaped_byte_cstr_ref(char byte);
>
> int main (int argc, const char * argv[])
> {
> char* t = escaped_byte_cstr_ref('!');
> printf(t);
> free(t);
>
> return 0;
> }
>

All good so far.

> char* escaped_byte_cstr_ref(char byte)
> {
> char buff[3];
> sprintf(buff, "%X", byte);
>

To simply copy a string, use strcpy(char *dest, char *source);
I'm not sure that you used the correct printf argument (%X).
> char* str = malloc(4);
>
> str[0] = '%';
> str[1] = buff[0];
> str[2] = buff[1];
> str[3] = 0x0;
>

This is okay, but the intermediate variable buff is unneccessary, unless
you need to validate the input.
> return str;
> }
>
> The program does not print anything - neither in bash nor in gdb.
> Although I do remember getting it running on XP with migw(currently I'm
> testing on OS X).


Try inserting my modifications, and see if that fixes it.
 
Reply With Quote
 
Andrew Poelstra
Guest
Posts: n/a
 
      04-25-2006
Ian Collins wrote:
> gamehack wrote:
>> Hi all,
>>
>> I've been testing out a small function and surprisingly it does not
>> work okay. Here's the full code listing:
>> #include "stdlib.h"
>> #include "stdio.h"
>>
>> char* escaped_byte_cstr_ref(char byte);
>>
>> int main (int argc, const char * argv[])
>> {
>> char* t = escaped_byte_cstr_ref('!');
>> printf(t);

>
> printf ("%s\n", t);
>
> Otherwise you don't flush stdout.
>


Disregard my last post; it appears that

printf (t);

should be

printf ("%s", t);
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      04-25-2006
Andrew Poelstra wrote:
> gamehack wrote:
>
>> char* escaped_byte_cstr_ref(char byte)
>> {
>> char buff[3];
>> sprintf(buff, "%X", byte);
>>

> To simply copy a string, use strcpy(char *dest, char *source);
> I'm not sure that you used the correct printf argument (%X).
>

The OP wants the value in hex, not a copy. It would have been clearer
if the function had a sensible name!

>> char* str = malloc(4);
>>
>> str[0] = '%';
>> str[1] = buff[0];
>> str[2] = buff[1];
>> str[3] = 0x0;
>>

> This is okay, but the intermediate variable buff is unneccessary, unless
> you need to validate the input.
>

See above.

--
Ian Collins.
 
Reply With Quote
 
cane
Guest
Posts: n/a
 
      04-25-2006
gamehack ha scritto:

> The program does not print anything - neither in bash nor in gdb.
> Although I do remember getting it running on XP with migw(currently I'm
> testing on OS X).


this works:

#include <stdlib.h>
#include <stdio.h>

char* escaped_byte_cstr_ref(char byte);

int main (int argc, const char * argv[])
{
char* t = escaped_byte_cstr_ref('!');
printf("%s",t);
free(t);

return 0;
}

char* escaped_byte_cstr_ref(char byte)
{
char buff[3];
char* str = malloc(4);

sprintf(buff, "%X", byte);

str[0] = '%';
str[1] = buff[0];
str[2] = buff[1];
str[3] = 0x0;

return str;
}
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      04-25-2006
Ian Collins wrote:
> gamehack wrote:
>
>>Hi all,
>>
>>I've been testing out a small function and surprisingly it does not
>>work okay. Here's the full code listing:
>>#include "stdlib.h"
>>#include "stdio.h"
>>
>>char* escaped_byte_cstr_ref(char byte);
>>
>>int main (int argc, const char * argv[])
>>{
>> char* t = escaped_byte_cstr_ref('!');
>> printf(t);

>
>
> printf ("%s\n", t);
>
> Otherwise you don't flush stdout.
>

Right fix, wrong explanation, sorry.

The first argument to printf is a format string.

--
Ian Collins.
 
Reply With Quote
 
Old Wolf
Guest
Posts: n/a
 
      04-26-2006
gamehack wrote:
> char* escaped_byte_cstr_ref(char byte)
> {
> char buff[3];
> sprintf(buff, "%X", byte);


Undefined behaviour -- %X expects an unsigned int, but you
pass it a char. Also, you cause a buffer overflow if byte has
any value other than 0 - 99 (ie. values greater than 99, and
values less than 0). In the case of negative bytes, the
buffer overflow will be particularly bad, as -1 will output
FFFFFFFF if you are on IA32 architecture.

Either use snprintf, or this:

char buff[50];
sprintf(buff, "%X", (unsigned int)byte);

where '50' is larger than any int will be in the foreseeable future.

 
Reply With Quote
 
Andrew Poelstra
Guest
Posts: n/a
 
      04-26-2006
Old Wolf wrote:
> gamehack wrote:
>> char* escaped_byte_cstr_ref(char byte)
>> {
>> char buff[3];
>> sprintf(buff, "%X", byte);

>
> Undefined behaviour -- %X expects an unsigned int, but you
> pass it a char. Also, you cause a buffer overflow if byte has
> any value other than 0 - 99 (ie. values greater than 99, and
> values less than 0).
> In the case of negative bytes, the
> buffer overflow will be particularly bad, as -1 will output
> FFFFFFFF if you are on IA32 architecture.
>
> Either use snprintf, or this:
>
> char buff[50];
> sprintf(buff, "%X", (unsigned int)byte);
>
> where '50' is larger than any int will be in the foreseeable future.
>


Let's assume that we have an unsigned char (which is a false assumption
in most cases).

A 3-element array can take a 2-digit string, which in this case will be
a hex number. All the values that fit into uchar (0x00-0xFF) fit this
criteria.

It is true, however, that negative numbers will expand very uncleanly.
 
Reply With Quote
 
Andrew Poelstra
Guest
Posts: n/a
 
      04-26-2006
Andrew Poelstra wrote:
> Old Wolf wrote:
>> gamehack wrote:
>>> char* escaped_byte_cstr_ref(char byte)
>>> {
>>> char buff[3];
>>> sprintf(buff, "%X", byte);

>>
>> Undefined behaviour -- %X expects an unsigned int, but you
>> pass it a char. Also, you cause a buffer overflow if byte has
>> any value other than 0 - 99 (ie. values greater than 99, and
>> values less than 0).
>> In the case of negative bytes, the
>> buffer overflow will be particularly bad, as -1 will output
>> FFFFFFFF if you are on IA32 architecture.
>>
>> Either use snprintf, or this:
>>
>> char buff[50];
>> sprintf(buff, "%X", (unsigned int)byte);
>>
>> where '50' is larger than any int will be in the foreseeable future.
>>

>
> Let's assume that we have an unsigned char (which is a false assumption
> in most cases).
>
> A 3-element array can take a 2-digit string, which in this case will be
> a hex number. All the values that fit into uchar (0x00-0xFF) fit this
> criteria.
>
> It is true, however, that negative numbers will expand very uncleanly.


Note: no standard-ASCII character will exceed 0x7F, and therefore the
negative number problem is practically nonexistant. Of course, in theory
it is possible that this function will be passed bad data, and so
precautions should be taken (in this case, simply using an unsigned char
will eliminate all issues, because anything bigger than 255 will be
wrapped).
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
debugger behaviour different to execution behaviour Andy Chambers Java 1 05-14-2007 09:51 AM
a strange behaviour of FF Maurice Firefox 2 03-11-2005 11:53 PM
Strange mouse behaviour with flash in Mozilla 1.3.7 hpoppe Firefox 0 11-07-2004 12:16 PM
Strange taskbar behaviour (notification area) Falcon Wireless Networking 0 08-17-2004 09:03 AM
[mozilla1.6] strange behaviour with newsgroup joost68 Firefox 5 04-03-2004 03:48 AM



Advertisments