Input bug ?

New to FreeBASIC? Post your questions here.
VANYA
Posts: 1287
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Input bug ?

Postby VANYA » Jun 20, 2012 15:37

Save File UTF-8

Code: Select all

#define UNICODE
dim as string*100 S
Print "Новая программа"
Input "Введите текст", S
Print "Вы ввели " ; s
sleep

'Windows Console
'Новая программа
'??????? ????? Новый текст
'Вы ввели Новый текст

'Linux Console
'Новая программа
'Введите текст  � � � � �  � � � � �
'Вы ввели Новый текст


If you use the type Wstring, in Linux it would be wrong to return value. Print command in the console is working properly. Why is it not working Input?
TJF
Posts: 3386
Joined: Dec 06, 2009 22:27
Location: N47°, E15°

Re: Input bug ?

Postby TJF » Jun 20, 2012 17:06

First a question:

Code: Select all

#define UNICODE

is not FB related. Why do you use this symbol?

I also found your (and other) problem(s) and IMO it's too much effort to work around them. This is why I use toolkits to handle it:

  • Cairo (or PangoCairo) for output,
  • GLib is for conversation betweem different character encodings and
  • GTK+ is for input (single line TextEntry or complex TextView)

All this tools are connected to gettext tools so you can simply translate your application to many languages.
VANYA
Posts: 1287
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: Input bug ?

Postby VANYA » Jun 20, 2012 17:28

TJF wrote:First a question:

Code: Select all

#define UNICODE

is not FB related. Why do you use this symbol?

I also found your (and other) problem(s) and IMO it's too much effort to work around them. This is why I use toolkits to handle it:

  • Cairo (or PangoCairo) for output,
  • GLib is for conversation betweem different character encodings and
  • GTK+ is for input (single line TextEntry or complex TextView)

All this tools are connected to gettext tools so you can simply translate your application to many languages.


You see my friend, for me personally, it has little value, but other Russian users are interested in working with the console. Now, some Russian school facilities use FreeBasic for teaching programming. Therefore, there unacceptable additional libraries, and very much needed Easy to work operators such as:
PRINT, INPUT ....
TJF
Posts: 3386
Joined: Dec 06, 2009 22:27
Location: N47°, E15°

Re: Input bug ?

Postby TJF » Jun 20, 2012 17:53

VANYA wrote:You see my friend, for me personally, it has little value, but other Russian users are interested in working with the console. Now, some Russian school facilities use FreeBasic for teaching programming. Therefore, there unacceptable additional libraries, and very much needed Easy to work operators such as:
PRINT, INPUT ....

Fine! English is the language to use with PRINT and INPUT ...
VANYA
Posts: 1287
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: Input bug ?

Postby VANYA » Jun 21, 2012 11:45

Here is an example:

Code: Select all

#Define Unicode
#Include "crt/stdio.bi"
Dim As ZString*100 S
Print "Input text:"
gets(@S)
Print S
Sleep


1) Works correctly under windows

2)Under Linux, not working properly. Why not see the characters as you type?

3)Example in C works fine under Linux:

Code: Select all

#include <stdio.h>
int main(){
char mass[100]="";
printf("Input text\n");
gets(mass);
printf("You entered:  %s !",mass);
return 0;
}
TJF
Posts: 3386
Joined: Dec 06, 2009 22:27
Location: N47°, E15°

Re: Input bug ?

Postby TJF » Jun 21, 2012 12:54

Code: Select all

#INCLUDE "crt/stdio.bi"
DIM AS ZSTRING*100 S
DIM AS UBYTE c
VAR i = 0
printf (!"Новая программа\nВведите текст ")
WHILE (c <> ASC(!"\n"))
  c = getchar()
  putchar(c)
  S[i] = c
  i += 1 : IF i > 98 THEN EXIT WHILE
WEND : S[i] = 0

printf (!"Вы ввели %s", @S)

Note: Be careful with the buffer lenght: this code may exit the WHILE loop while scanning a multi-byte UTF-8 charater.
VANYA
Posts: 1287
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: Input bug ?

Postby VANYA » Jun 21, 2012 13:41

TJF wrote:

Code: Select all

#INCLUDE "crt/stdio.bi"
DIM AS ZSTRING*100 S
DIM AS UBYTE c
VAR i = 0
printf (!"Новая программа\nВведите текст ")
WHILE (c <> ASC(!"\n"))
  c = getchar()
  putchar(c)
  S[i] = c
  i += 1 : IF i > 98 THEN EXIT WHILE
WEND : S[i] = 0

printf (!"Вы ввели %s", @S)

Note: Be careful with the buffer lenght: this code may exit the WHILE loop while scanning a multi-byte UTF-8 charater.


Thank you for the example. I am still interested in why the RTL C functions (gets and scanf) does not work properly under Linux?
TJF
Posts: 3386
Joined: Dec 06, 2009 22:27
Location: N47°, E15°

Re: Input bug ?

Postby TJF » Jun 21, 2012 16:11

VANYA wrote:I am still interested in why the RTL C functions (gets and scanf) does not work properly under Linux?

IMO the LINUX version works OK and there's a problem with the echo on windows.

gets() or scanf() receive a stream from stdin. They should only receive the stream and should not echo the result to stdout (just think about passwords). It's up to the code to echo on stdout if required.
VANYA
Posts: 1287
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: Input bug ?

Postby VANYA » Jun 21, 2012 17:35

TJF wrote:
VANYA wrote:I am still interested in why the RTL C functions (gets and scanf) does not work properly under Linux?

IMO the LINUX version works OK and there's a problem with the echo on windows.

gets() or scanf() receive a stream from stdin. They should only receive the stream and should not echo the result to stdout (just think about passwords). It's up to the code to echo on stdout if required.


Above I have given two pieces of code in C and FreeBasic. By their nature they are the same, have the same functions, but work on Linux in different ways. While on Windows, they work the same right. Try to run them, and you'll see the difference. That's the question: why FreeBasic RTL C handles differently?
TJF
Posts: 3386
Joined: Dec 06, 2009 22:27
Location: N47°, E15°

Re: Input bug ?

Postby TJF » Jun 21, 2012 18:35

VANYA wrote:Above I have given two pieces of code in C and FreeBasic. By their nature they are the same, have the same functions, but work on Linux in different ways. While on Windows, they work the same right. Try to run them, and you'll see the difference. That's the question: why FreeBasic RTL C handles differently?

I think we agree that the FB version doesn't work well, neither on LINUX nor on windows -- either the question or the answer isn't shown correct. (But they don't call the same functions. There is no expression for INPUT in C.)

In contrast the CRT version works well, but only on one system. From my point of view it's OK on LINUX and it's faulty on windows, since gets() should only get the stream and shouldn't echo the result to stdout.
Gonzo
Posts: 722
Joined: Dec 11, 2005 22:46

Re: Input bug ?

Postby Gonzo » Jun 21, 2012 20:03

wouldnt it be possible to #undef Input and make your own unicode version?
VANYA
Posts: 1287
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: Input bug ?

Postby VANYA » Jun 22, 2012 2:45

TJF wrote:From my point of view it's OK on LINUX and it's faulty on windows, since gets() should only get the stream and shouldn't echo the result to stdout.


And why then (gets , scanf) of C++(minGW) is displayed in the console? It is clear that the dark matter :)

In any case, thanks for the help
dkl
Site Admin
Posts: 3202
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Input bug ?

Postby dkl » Jun 22, 2012 19:27

The main issue with Input and wstrings is that it's not yet properly implemented (neither the first argument, the prompt text, nor the second argument, the target variable, support wstrings). There's a TODO entry about it and maybe it can be looked at for a future FB version.

Note that if you save the .bas file with Unicode BOM, string literals are treated as wstrings instead of zstrings. This means you may have unexpected wstring -> zstring conversions in some places, and the FB rtlib does not implement these properly (it does not do a Unicode -> codepage conversion, but essentially just a simple char = wchar assignment that copys wchars <= 255 1:1 and replaces anything > 255 with question marks. You can see that here:

Code: Select all

'' Save as UTF8 with BOM

#if typeof( wstring ) <> typeof( "Новая программа" )
   #error "Missing BOM"
#endif

#define TEXT "Новая программа"

dim as wstring * 50 w = TEXT

'' Print wstring
print w
print TEXT

'' Print zstring
print str( w )     '' (run-time conversion)
print str( TEXT )  '' (compile-time conversion)


This is also something where I'm not sure how much work a fix would require.
VANYA
Posts: 1287
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: Input bug ?

Postby VANYA » Jun 23, 2012 3:26

dkl wrote:The main issue with Input and wstrings is that it's not yet properly implemented (neither the first argument, the prompt text, nor the second argument, the target variable, support wstrings). There's a TODO entry about it and maybe it can be looked at for a future FB version.

Note that if you save the .bas file with Unicode BOM, string literals are treated as wstrings instead of zstrings. This means you may have unexpected wstring -> zstring conversions in some places, and the FB rtlib does not implement these properly (it does not do a Unicode -> codepage conversion, but essentially just a simple char = wchar assignment that copys wchars <= 255 1:1 and replaces anything > 255 with question marks. You can see that here:

Code: Select all

'' Save as UTF8 with BOM

#if typeof( wstring ) <> typeof( "Новая программа" )
   #error "Missing BOM"
#endif

#define TEXT "Новая программа"

dim as wstring * 50 w = TEXT

'' Print wstring
print w
print TEXT

'' Print zstring
print str( w )     '' (run-time conversion)
print str( TEXT )  '' (compile-time conversion)


This is also something where I'm not sure how much work a fix would require.


Clearly, thanks dkl

Return to “Beginners”

Who is online

Users browsing this forum: No registered users and 2 guests