Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

echoerr truncates long lines

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:\>
 
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!
 
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.
 
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]
 
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.
 
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.
 
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
 
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.
 
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

Back
Top