echoerr truncates long lines

May 31, 2008
382
2
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
614
15
Norman, OK
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!
 
May 20, 2008
3,515
4
Elkridge, MD, USA
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
614
15
Norman, OK
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
12,556
167
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
614
15
Norman, OK
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
572
4
Groton, CT
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
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.
 
May 31, 2008
382
2
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.
Thanks for having added a workaround in version 13.04.59, it works fine.
 

Similar threads