[<prev] [next>] [day] [month] [year] [list]
Message-ID: <Z_yyUmYoihvpP0_5@smile.fi.intel.com>
Date: Mon, 14 Apr 2025 09:59:30 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Rasmus Villemoes <linux@...musvillemoes.dk>
Cc: Remo Senekowitsch <remo@...nzli.dev>, Petr Mladek <pmladek@...e.com>,
Steven Rostedt <rostedt@...dmis.org>,
Sergey Senozhatsky <senozhatsky@...omium.org>,
linux-kernel@...r.kernel.org
Subject: Re: Exporting functions from vsprintf.c for Rust
On Fri, Apr 11, 2025 at 03:43:12PM +0200, Rasmus Villemoes wrote:
> On Fri, Apr 11, 2025, 13:36 Remo Senekowitsch <remo@...nzli.dev> wrote:
> > On Fri Apr 11, 2025 at 11:42 AM CEST, Petr Mladek wrote:
...
> > > Honestly, I do not have a good feeling about exporting the internal
> > > vsprintf() functions. They have a very specific semantic.
> > >
> > > Especially, they return pointer to the next-to-write character.
> > > And it might be even beyond the given *end pointer. It is because, for
> > > example, vsnprintf() returns the number of characters which would
> > > have been written to the buffer when it was big enough.
> > >
> > > Instead, I suggest to create a wrapper which would have a sane
> > > semantic and call scnprintf() internally. Something like:
> > >
> > > int fwnode_full_name_to_string(char *buf, size_t size,
> > > struct fwnode_handle *fwnode)
> > > {
> > > return scnprintf(buf, size, "%pfwf", fwnode);
> > > }
> >
> > That makes sense. I tried your suggestion and it works, thank you!
> >
> >
> But is a wrapper even needed for this? Can't the appropriate sprintf
> variant just be called from Rust with that %pfwf format string?
+1 here. But if really really need that wrapper, it should go to property.h.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists