devkitPro

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?
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.

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.

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

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?

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

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

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!

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).

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.