On Fri, Jan 10, 2014 at 03:19:07PM +0100, Jakub Hrozek wrote:
> On Fri, Jan 10, 2014 at 02:56:42PM +0100, Stef Walter wrote:
> > On 10.01.2014 12:11, Jakub Hrozek wrote:
> > > On Thu, Jan 09, 2014 at 09:32:00PM +0100, Stef Walter wrote:
> > >> On 08.01.2014 23:27, Jakub Hrozek wrote:
> > >>> On Wed
On Fri, Jan 10, 2014 at 02:56:42PM +0100, Stef Walter wrote:
> On 10.01.2014 12:11, Jakub Hrozek wrote:
> > On Thu, Jan 09, 2014 at 09:32:00PM +0100, Stef Walter wrote:
> >> On 08.01.2014 23:27, Jakub Hrozek wrote:
> >>> On Wed, Jan 08, 2014 at 09:02:52PM +0100, Stef Walter wrote:
> On 08.01.2
On 10.01.2014 12:11, Jakub Hrozek wrote:
> On Thu, Jan 09, 2014 at 09:32:00PM +0100, Stef Walter wrote:
>> On 08.01.2014 23:27, Jakub Hrozek wrote:
>>> On Wed, Jan 08, 2014 at 09:02:52PM +0100, Stef Walter wrote:
On 08.01.2014 17:59, Simo Sorce wrote:
> On Wed, 2014-01-08 at 11:21 +0100, S
On Thu, Jan 09, 2014 at 09:32:00PM +0100, Stef Walter wrote:
> On 08.01.2014 23:27, Jakub Hrozek wrote:
> > On Wed, Jan 08, 2014 at 09:02:52PM +0100, Stef Walter wrote:
> >> On 08.01.2014 17:59, Simo Sorce wrote:
> >>> On Wed, 2014-01-08 at 11:21 +0100, Stef Walter wrote:
> On 07.01.2014 22:21
On 08.01.2014 23:27, Jakub Hrozek wrote:
> On Wed, Jan 08, 2014 at 09:02:52PM +0100, Stef Walter wrote:
>> On 08.01.2014 17:59, Simo Sorce wrote:
>>> On Wed, 2014-01-08 at 11:21 +0100, Stef Walter wrote:
On 07.01.2014 22:21, Simo Sorce wrote:
> Sorry I forgot another, I think you should ei
On Wed, Jan 08, 2014 at 09:02:52PM +0100, Stef Walter wrote:
> On 08.01.2014 17:59, Simo Sorce wrote:
> > On Wed, 2014-01-08 at 11:21 +0100, Stef Walter wrote:
> >> On 07.01.2014 22:21, Simo Sorce wrote:
> >>> Sorry I forgot another, I think you should either set errno on errors,
> >>> or return an
On 08.01.2014 17:59, Simo Sorce wrote:
> On Wed, 2014-01-08 at 11:21 +0100, Stef Walter wrote:
>> On 07.01.2014 22:21, Simo Sorce wrote:
>>> Sorry I forgot another, I think you should either set errno on errors,
>>> or return an errno_t instead of -1. Just returning -1 for all errors is
>>> a poor
On Wed, 2014-01-08 at 11:21 +0100, Stef Walter wrote:
> On 07.01.2014 22:21, Simo Sorce wrote:
> > On Tue, 2014-01-07 at 21:31 +0100, Stef Walter wrote:
> >> On 07.01.2014 20:34, Simo Sorce wrote:
> >>> Ok fine, makes sense once explained (need this explanation in the
> >>> docs/headers), but then
On 07.01.2014 22:21, Simo Sorce wrote:
> On Tue, 2014-01-07 at 21:31 +0100, Stef Walter wrote:
>> On 07.01.2014 20:34, Simo Sorce wrote:
>>> Ok fine, makes sense once explained (need this explanation in the
>>> docs/headers), but then use a different name.
>>>
>>> If I see safe_snprintf, I assume t
On Tue, 2014-01-07 at 21:31 +0100, Stef Walter wrote:
> On 07.01.2014 20:34, Simo Sorce wrote:
> > Ok fine, makes sense once explained (need this explanation in the
> > docs/headers), but then use a different name.
> >
> > If I see safe_snprintf, I assume the full format capabilities of
> > snprin
On 07.01.2014 20:34, Simo Sorce wrote:
> Ok fine, makes sense once explained (need this explanation in the
> docs/headers), but then use a different name.
>
> If I see safe_snprintf, I assume the full format capabilities of
> snprintf, the name in this case is misleading.
>
> That said I am not s
On Tue, 2014-01-07 at 20:20 +0100, Stef Walter wrote:
> On 07.01.2014 19:55, Simo Sorce wrote:
> > A few notes:
> >
> > 1. style
> > although we allow things like
> > if (condition)
> > statement;
> > I do not think we accpet for or while loops w/o braces
>
> Nod.
>
> > 2. the functions are
On 07.01.2014 19:55, Simo Sorce wrote:
> A few notes:
>
> 1. style
> although we allow things like
> if (condition)
> statement;
> I do not think we accpet for or while loops w/o braces
Nod.
> 2. the functions are incomplete and lack documentation that states so
> in particular the only acc
A few notes:
1. style
although we allow things like
if (condition)
statement;
I do not think we accpet for or while loops w/o braces
2. the functions are incomplete and lack documentation that states so
in particular the only accepted format type is 's' (string).
I think we want a complete r
On 07.01.2014 14:57, Stef Walter wrote:
> On 07.01.2014 14:07, Stef Walter wrote:
>> Anyhow, here's a patch which aims to make the full_name_format printf
>> handling both correct and safe.
>
> ...
>
>> I'll be happy to split the patch into two, if desired. One which adds
>> safe-printf.[ch] + te
On 07.01.2014 14:07, Stef Walter wrote:
> Anyhow, here's a patch which aims to make the full_name_format printf
> handling both correct and safe.
...
> I'll be happy to split the patch into two, if desired. One which adds
> safe-printf.[ch] + tests, and the second which fixes the fully qualified
full_name_format is documented as a printf(3) compatible format string,
and the util.c implementation passes that string to snprintf after some
sneaky hacks to make it actually work ...
It's not good practice to pass user input (even admin input) to printf
directly. Doing so leads to crashes and a
17 matches
Mail list logo
