ratpoison-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RP] [PATCH] limit memory consumption on snprintf errors.


From: Bernhard R. Link
Subject: [RP] [PATCH] limit memory consumption on snprintf errors.
Date: Tue, 14 Aug 2007 21:31:31 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

* Bernhard R. Link <address@hidden> [070814 10:35]:
> 1) I'd guess it is better to saveguard this and add some maximum number
>    of characters to test for (at least with negative return values).
>    This would help against other possible future problems causing -1
>    returns.

Attached is a patch that limits memory consumption to at most 200K is
such sitations and returns "<FAILURE>" then. Downside is that it will
limit strings effectively to something between 100K annd 200K on old
systems.
(Which should be reasonable large, I guess the largest things will
be fdump and windows, and with those reaching 10K is already not that easy).
Where "old systems" means glibc from before 1999 or something similary
old.

> 2) It might be some problem with giving invalid utf-8 characters into
>    this function. While searching for the reason of this bug I found
>    some problems when both ratpoison and the clients use a UTF-8
>    locale (though that causes only misdisplays for me).

That is indeed the case. The reason for the -1 is the input string not
being valid UTF-8. And that is already fixed.

> 3) finally vsnprinf might indeed the wrong function for that. I've not
>    yet looked into that. But looking at the manpage I'd guess that that
>    should only generate displaying problems (as the number means bytes
>    and not characters). I guess this needs someone knowing this issues
>    to look into it.

>From what I've found out, the only problem with vsnprintf in
format_string is it's counting bytes and not characters, so %<num>t will
have a cosmetical problem with multi-byte sequences. Otherwise it works
well (at least glibc2.3.6 I tested with takes care not to split multi-
byte sequences).

Hochachtungsvoll,
        Bernhard R. Link

Attachment: patchx
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]