devkitPro

\t is generating 4 spaces instead of tab... which means that on the generated output should had B aligned but it doesnt
(outputting to the console)

Perhaps you'd like to point us to the standards documentation that states unequivocally that the tab character should align to a multiple of 8 spaces ...

WinterMute wrote:Perhaps you'd like to point us to the standards documentation that states unequivocally that the tab character should align to a multiple of 8 spaces ...

it does say that they are ascii chars, and ascii reference says that controls 0 to 31 are reserved for meta info
and so for example this http://www.faqs.org/rfcs/rfc20.html RFC will define 9 as being horizontal tab
which moves the cursor to next predefined point... (which IS the purpose of TABULATION anyway).

i didnt said it must be 8 chars.... since there isnt really an amount of chars to define that.... since on text editors
a TAB can be measured in pixels....

but it's common knowledge what a TAB must do, and since i didnt even saw any other library that parse ascii not parsing TAB with the purpose of alignment.... i state that is a bug....

so in any case not fixing TAB just means you're rebelling against it (laziness? O.o) (not priority? ok, but i didnt said 'I WANT IT FIXED NOW', just reported a bug)

and if you want to get literal to the BUG definition i can change it to something else... so either way
the "Whatever you wanna call it" is reported... have fun

I'm not rebelling against anything, having 8 character tab stops on a 32 character wide screen seemed rather pointless & we decided on 4.

It's not a bug, it's simply something not working how you expected it to, much like the null character termination in the console code. These are both undefined behaviours and expecting things to work exactly like your desktop PC is unrealistic and naive.

WinterMute wrote:I'm not rebelling against anything, having 8 character tab stops on a 32 character wide screen seemed rather pointless & we decided on 4.

It's not a bug, it's simply something not working how you expected it to, much like the null character termination in the console code. These are both undefined behaviours and expecting things to work exactly like your desktop PC is unrealistic and naive.

i told you it's not about the 4... in freebasic is 12 instead of 8, because for 80 columns 12 seems better.... but, what i mean is
that \t is generating always EXACTLY 4 spaces instead of align by 4, so even if it's 4 the B on my initial example should be aligned, that is the problem
like this: (no matter which size it is... what matter is the alignment) anyway sorry if i sounded harsh in the last post, i just wanted to cover all possible misunderstandings... but so still a bug

ah, ok, that's definitely a bug then, sorry I misunderstood.