On Mon, 2018-04-09 at 13:44 +0200, Petr Mladek wrote:
> What exactly is wrong?
I doubt the need.
Adding complexity doesn't seem useful.
> What you would suggest instead?
A static analysis on the source code instead
of runtime checking.
Perhaps a gcc plugin to validate extension to
pointer type
On Fri 2018-04-06 07:19:15, Joe Perches wrote:
> On Fri, 2018-04-06 at 15:12 +0200, Petr Mladek wrote:
> > On Wed 2018-04-04 07:26:07, Joe Perches wrote:
> > > On Wed, 2018-04-04 at 10:58 +0200, Petr Mladek wrote:
> > > > Move the code from the long pointer() function. We are going to add a
> > >
On Fri, 2018-04-06 at 15:12 +0200, Petr Mladek wrote:
> On Wed 2018-04-04 07:26:07, Joe Perches wrote:
> > On Wed, 2018-04-04 at 10:58 +0200, Petr Mladek wrote:
> > > Move the code from the long pointer() function. We are going to add a
> > > check
> > > for the access to the address that will mak
On Wed 2018-04-04 07:26:07, Joe Perches wrote:
> On Wed, 2018-04-04 at 10:58 +0200, Petr Mladek wrote:
> > Move the code from the long pointer() function. We are going to add a check
> > for the access to the address that will make it even more complicated.
> >
> > This patch does not change the e
On Wed, 2018-04-04 at 10:58 +0200, Petr Mladek wrote:
> Move the code from the long pointer() function. We are going to add a check
> for the access to the address that will make it even more complicated.
>
> This patch does not change the existing behavior.
But it might increase stack consumptio
Move the code from the long pointer() function. We are going to add a check
for the access to the address that will make it even more complicated.
This patch does not change the existing behavior.
Signed-off-by: Petr Mladek
---
lib/vsprintf.c | 23 ++-
1 file changed, 14 ins
6 matches
Mail list logo
