lua-users home
lua-l archive

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


I don't see at all why just this restriction would avoid a buffer overflow, given that there's not even an upper bound for the string length of the variable in parameter. This just limits the numbers of spaces added after strings that are shorter than that with. Use "%s" and you can as well get the buffer overflow if this is not checked. Once you have that check in place, there's no longer any justification to limit the padding. Even in c/c++ the buffer overflow is resolved in snprintf where you separately indicate the size of the target buffer. In lua there's no buffer limits for strings (only memory allocation limits per object or a total quota per process or thread in the supporting vm). So it just indicate that this restriction is just an old dirty trick to passe some tests, just because a full check was still not implémented. If you get a bug without this restriction, then the cause is elsewhere and MUST be fixed, this restriction does not fix anything 

Le jeu. 19 janv. 2023 à 18:45, Mouse <mouse@rodents-montreal.org> a écrit :
>> The width in %45s is used to right-justify the string by padding on
>> the left with spaces.
> My point was that I can well imagine use cases where someone do want
> to right-justify a, say, 150 char string in a 200 char field, [...]

I don't know what Luiz meant to be replying to, but it does occur to me
that Roberto wrote of "a simple a secure way to [...] avoid buffer
overflow", and pointing out that the field width does not limit the
printed string length _is_ a valid point in response to _that_.  The
"avoid buffer overflow" text got lost somewhere in the quoting in what
I saw, though, so even if that was the point it may not have been
apparent.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse@rodents-montreal.org
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B