Some patches to compile with gcc-next

[Matthias Dieter Wallnöfer]

Just asking: Has there been a follow-up on this issue? Seems to be a
valid bug, fortunately not a security one.

Matthias

Jeremy Allison schrieb:
> On Wed, Nov 02, 2016 at 05:03:42PM -0700, Jeremy Allison wrote:
>> On Thu, Nov 03, 2016 at 09:52:07AM +1300, Douglas Bagnall wrote:
>>>
>>> The real bug is in smbclient, which I think I have fixed. There it was
>>> trying to overwrite a string like "stdin-<pid>" onto the considerably
>>> shorter string "-", but the snprintf limit was actually set to
>>> sizeof(char *) - 1.
>>>
>>> ../source4/client/client.c: In function ‘cmd_print’:
>>> ../source4/client/client.c:1545:45: error: output truncated before the last format character [-Werror=format-length=]
>>>    slprintf(rname, sizeof(rname)-1, "stdin-%d", (int)getpid());
>>>                                      ~~~~~~~~^
>>> In file included from ../source4/include/includes.h:23:0,
>>>                  from ../source4/client/client.c:32:
>>> ../lib/replace/../replace/replace.h:510:18: note: format output between 8 and 18 bytes into a destination of size 7
>>>  #define slprintf snprintf
>>> ../source4/client/client.c:1545:3: note: in expansion of macro ‘slprintf’
>>>    slprintf(rname, sizeof(rname)-1, "stdin-%d", (int)getpid());
>>>    ^~~~~~~~
>>
>> Yeah, that's in the smbclient4 which isn't used as a production
>> tool. Good catch though.
>>
>> I'll take a look at PATCH 4/4 tomorrow and review !
> 
> Douglas - slprintf has been deprecated (as you see above
> with the #define slprintf snprintf).
> 
> Can you rewrite patch 4/4 to use snprintf instead with
> the correct size_t lengths ? Let me know if you don't
> have time and I'll take a look at doing it.
> 
> Slowly we should be getting rid of slprintf from
> our code.
> 
> Cheers,
> 
> 	Jeremy.
>