fwrite to stdout bug

Post Reply
Mysoft
Posts: 19
Joined: Thu Jun 09, 2011 11:56 am

fwrite to stdout bug

Post by Mysoft » Wed Jun 15, 2011 3:17 am

ok i was writting routines for freebasic runtime lib... and when i was adding the PrintString, i noticed
that _write \ fwrite to console is stopping when a null is found...

maybe it was hardcoded to "puts" when the target file is stdout?

Code: Select all

fwrite("Hello\0World\n",1,12,stdout);
_write(STDOUT_FILENO,"Hello\0World\n",12);
my current workaround is use to putc / fputc, but that's probabily much slower than what _write should do at low level... so anyway, that's a bug since it doesnt happen when compiling for my PC. :)

WinterMute
Site Admin
Posts: 1478
Joined: Tue Aug 09, 2005 3:21 am
Location: UK
Contact:

Re: fwrite to stdout bug

Post by WinterMute » Wed Jun 15, 2011 8:30 pm

Why are you trying to print strings with an included null character anyway, this is a normal termination character.

I can change the way the console functions in libnds work but it'll be a while before I release a new one - still testing the next devkitARM and that will be released first.
Help keep devkitPro toolchains free, Donate today

Personal Blog

Mysoft
Posts: 19
Joined: Thu Jun 09, 2011 11:56 am

Re: fwrite to stdout bug

Post by Mysoft » Thu Jun 16, 2011 6:56 pm

WinterMute wrote:Why are you trying to print strings with an included null character anyway, this is a normal termination character.

I can change the way the console functions in libnds work but it'll be a while before I release a new one - still testing the next devkitARM and that will be released first.
is because i don't code in C/C++ i only code in freebasic, so i'm porting the freebasic runtime lib... to ARM, (it generates C code in the end anyway...)

but so the String Class... can deal with strings that contains null chars, even that we avoid using those for obvious reasons... but yeah no hurry... i just wanted to inform about the bug, i will for now use the workaround with putc... and checking for 0 (since even putc fails when trying to write a null) ;p

Thanks :)

User avatar
Izhido
Posts: 107
Joined: Fri Oct 19, 2007 10:57 pm
Location: Costa Rica
Contact:

Re: fwrite to stdout bug

Post by Izhido » Fri Jun 17, 2011 12:22 am

Even so... why are you actually including \0 characters in your string ? What is the intended effect of sending a \0 character to the screen? What do you expect to see there, in the place of that \0 character?

Mysoft
Posts: 19
Joined: Thu Jun 09, 2011 11:56 am

Re: fwrite to stdout bug

Post by Mysoft » Fri Jun 17, 2011 1:29 pm

Izhido wrote:Even so... why are you actually including \0 characters in your string ? What is the intended effect of sending a \0 character to the screen? What do you expect to see there, in the place of that \0 character?
i'm not... i just want it to be compatible with such things... and what i expected to see on screen is probabily a space or just ignore that char... i remember sometimes when coding i test things by printing the buffer in ASCII format... and so freebasic allow me todo that since the string class itself support /0, but then got it chopped off would be bad...

like i said, isnt a big problem, since it's easy to workaround it... but if the CRT functions want the size is because /0 is ok... so i don't want to see a program that use lists with /0 on the middle to stop working (remember windows have those for filename dialog? normally on FB i store those on a string, and so you can check it just by prinrting... wchich would fail... but fail ONLY to print, just cause confusion, so unlikely to break any APP, but still a bug :)

tueidj
Posts: 40
Joined: Thu Dec 10, 2009 9:26 am

Re: fwrite to stdout bug

Post by tueidj » Fri Jun 17, 2011 6:05 pm

It's not a bug, it's perfectly valid C behaviour - '\0' signifies the end of a string.

Mysoft
Posts: 19
Joined: Thu Jun 09, 2011 11:56 am

Re: fwrite to stdout bug

Post by Mysoft » Fri Jun 17, 2011 7:38 pm

tueidj wrote:It's not a bug, it's perfectly valid C behaviour - '\0' signifies the end of a string.
first \0 means the end of a C string (Zstring in freebasic)... in C++ you have also the string class that suppose to not be affected by \0.. anyway, but, so...

it's a BUG.. fwrite / write doesnt expect zstrings they expect a void *BUFFER, so the internals is passing that probabily as a string to the console functions when it's output handle is stdout, by mistake, or just to get it working and nobody had reported the behavior or ignored until... but it works if i compile with GCC for windows,linux and djcpp for DOS... so yeah BUG! :P

also if DS had a system or pipes... this could may cause more trouble... (probabily not because then it would be proper handled to work with pipes that can't be hardcoded like that).

tueidj
Posts: 40
Joined: Thu Dec 10, 2009 9:26 am

Re: fwrite to stdout bug

Post by tueidj » Sat Jun 18, 2011 11:09 am

It works fine when outputting to a file and there's no rules defining how a standard output device has to behave - if you haven't set up a console it throws away everything, are you going to call that a bug too?
Newsflash: undefined operations may produce different results on different systems. Doesn't mean there's an error involved.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest