After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 722657 - minor OSC 4 handler issues
minor OSC 4 handler issues
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
unspecified
Other Linux
: Normal minor
: ---
Assigned To: VTE Maintainers
VTE Maintainers
[fixed:vteparser]
Depends on: vteparser
Blocks:
 
 
Reported: 2014-01-20 21:51 UTC by Christian Persch
Modified: 2018-03-27 17:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Christian Persch 2014-01-20 21:51:50 UTC 
While looking at the OSC 104 patch, I noticed that the OSC 4 handler
- uses strtoul instead of g_ascii_strtoull, and
- doesn't limit the length of the value array to something sensible (like VTE_PALETTE_SIZE or so; but need to check if xterm limits this or not)
Comment 1 Egmont Koblinger 2014-01-20 22:09:15 UTC 
- Is it because strtoul is locale-dependent? Good point.
- If it's for protection against way too long escape sequences, I guess it should be addressed before matching. If it survives the match (meaning we already see the terminating BEL/ST) I guess it's okay to process them all.
Comment 2 Christian Persch 2014-01-20 22:59:34 UTC 
(In reply to comment #1)
> - Is it because strtoul is locale-dependent? Good point.

Yes.

> - If it's for protection against way too long escape sequences, I guess it
> should be addressed before matching. If it survives the match (meaning we
> already see the terminating BEL/ST) I guess it's okay to process them all.

Right, this should be done pre-matching.
Comment 3 Christian Persch 2018-03-27 17:48:18 UTC 
Fixed on master.