echoerr truncates long lines

May 31, 2008
382
2
#1
When an output line includes some Unicode characters U+FF01 through U+FF5E, ECHOERR truncates the line at width %_COLUMNS while ECHO doesn't. Look at the missing dangling 81st character in the ECHOERR line below.
Code:
C:\>ver

TCC LE 13.04.52 Windows 7 [Version 6.1.7601]
 
C:\>chcp
Active code page: 437 
 
C:\>option //ErrorColors=207

C:\>echo %@repeat[x,%@inc[%_COLUMNS]]
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
x
 
 C:\>echo %@repeat[%@char[%@eval[%@ascii[x]+0xfee0]],%@inc[%_COLUMNS]]   
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
x
 
 C:\>ECHOERR %@repeat[%@char[%@eval[%@ascii[x]+0xfee0]],%@inc[%_COLUMNS]] 
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

C:\>
 
Jan 19, 2011
581
10
Norman, OK
#3
JP Software does not provide any support for TCC/LE.
Same thing happens in
Code:
TCC  13.04.57  Windows XP [Version 5.1.2600]
Oh... and another thing! Why didn't anybody ever tell me about that
Code:
option //ErrorColors=207
thing.

That's freekin' cool!
 
#4
Same TCC 13.04.57, same WinXP SP3 home, I created an environment variable longer than 1000 characters, ECHOERR displays it correctly. On my laptop (XP pro SP3) I went over 2222 character, nicely wrapped.
 
Jan 19, 2011
581
10
Norman, OK
#5
Same TCC 13.04.57, same WinXP SP3 home, I created an environment variable longer than 1000 characters, ECHOERR displays it correctly. On my laptop (XP pro SP3) I went over 2222 character, nicely wrapped.
Did you make it a high range unicode string like in post 1?

This works fine
Code:
ECHOERR %@repeat[%@char[%@eval[%@ascii[x]+0xfee0]],80]
This doesn't
Code:
ECHOERR %@repeat[%@char[%@eval[%@ascii[x]+0xfee0]],1000]
 

rconn

Administrator
Staff member
May 14, 2008
10,606
97
#6
Nothing to do with TCC; it's a bug in the Windows WriteConsoleOutputCharacter API. It also has nothing to do with Unicode characters in a specific range; it's any non-ASCII (>127) character. (Though it gets somewhat odd-looking trying to use one of those 0xFEE0+n characters, since Windows interprets that as a double-wide character. I can't imagine what the OP was trying to do here ...)

IMO it's not significant enough to merit kludging up a (much slower) workaround.
 
Jan 19, 2011
581
10
Norman, OK
#7
It also has nothing to do with Unicode characters in a specific range; it's any non-ASCII (>127) character.
I can live with that. Kinda makes sense too; by sticking to only low ASCII characters, the chance of the terminal failing to interpret it drops to almost zero. Also changes it from a bug to a design feature.
 
May 29, 2008
533
3
Groton, CT
#8
I can live with that. Kinda makes sense too; by sticking to only low ASCII characters, the chance of the terminal failing to interpret it drops to almost zero. Also changes it from a bug to a design feature.
But not a TCC design feature (nor a TCC design error). I'd still call it a bug, but a Microsoft bug.

Dave C.
former tracker and classifier of bugs in a previous life
 
May 31, 2008
382
2
#9
it gets somewhat odd-looking trying to use one of those 0xFEE0+n characters, since Windows interprets that as a double-wide character. I can't imagine what the OP was trying to do here ...)
Charle's SAFECHARS plugin uses that encoding. That's the context where I noticed this issue.