Jeff King writes:
> Thanks for an interesting (and exotic) counter-point. For strcpy(), you
> always have to run strlen() anyway to know you're not going to overflow,
> so you might as well memcpy() at that point. But if you really are OK
> with truncation, then using strncpy() lets you copy whil
On Fri, Jul 20, 2018 at 10:48:37AM -0700, Elijah Newren wrote:
> > Is it possible to extend this to ban variables as well? I'm still
> > going to delete the_index from library code. Once that work is done I
>
> Or perhaps constants, such as PATH_MAX to avoid problems like this one
> from 2.18.0 t
On Fri, Jul 20, 2018 at 04:41:34PM +0200, Duy Nguyen wrote:
> > Let's start by banning strcpy() and sprintf(). It's not
> > impossible to use these correctly, but it's easy to do so
> > incorrectly, and there's always a better option.
>
> Is it possible to extend this to ban variables as well? I'
On Fri, Jul 20, 2018 at 09:22:41AM -0400, Theodore Y. Ts'o wrote:
> On Thu, Jul 19, 2018 at 09:08:08PM -0400, Jeff King wrote:
> > Ditto for sprintf, where you should _always_ be using at least xsnprintf
> > (or some better tool, depending on the situation). And for strncpy,
> > strlcpy (or again
On Fri, Jul 20, 2018 at 7:41 AM, Duy Nguyen wrote:
> On Thu, Jul 19, 2018 at 10:40 PM Jeff King wrote:
>>
>> There are a few standard C functions (like strcpy) which are
>> easy to misuse. We generally discourage these in reviews,
>> but we haven't put advice in CodingGuidelines, nor provided
>>
On Fri, Jul 20, 2018 at 02:32:29AM -0700, Junio C Hamano wrote:
> > Contrast this with memcpy(). This is on Microsoft's SDL banned list[1],
> > but I think it's silly for it to be. I would never add it to this list.
>
> A tangent, but is that because they want you to use memmove()
> instead so th
On Thu, Jul 19, 2018 at 10:40 PM Jeff King wrote:
>
> There are a few standard C functions (like strcpy) which are
> easy to misuse. We generally discourage these in reviews,
> but we haven't put advice in CodingGuidelines, nor provided
> any automated enforcement. The latter is especially
> impor
On Thu, Jul 19, 2018 at 09:08:08PM -0400, Jeff King wrote:
> Ditto for sprintf, where you should _always_ be using at least xsnprintf
> (or some better tool, depending on the situation). And for strncpy,
> strlcpy (or again, some better tool) is strictly an improvement.
Nitpick: this may be true
On 7/19/2018 4:39 PM, Jeff King wrote:
There are a few standard C functions (like strcpy) which are
easy to misuse. We generally discourage these in reviews,
but we haven't put advice in CodingGuidelines, nor provided
any automated enforcement. The latter is especially
important because it's more
Jeff King writes:
>> Is it a downside that it is cumbersome to override? This is not a
>> rhetorical question. I am not convinced there will not be a legit
>> circumstance that calling strcpy (or whatever we are going to ban)
>> is the best solution and it is safe. By "best", what I mean is "y
On Thu, Jul 19, 2018 at 09:08:08PM -0400, Jeff King wrote:
> Contrast this with memcpy(). This is on Microsoft's SDL banned list[1],
> but I think it's silly for it to be. I would never add it to this list.
I forgot my footnote, which was going to be:
I'm bringing up that list not because I th
On Thu, Jul 19, 2018 at 03:46:08PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > For enforcement, we can rely on the compiler and just
> > introduce code which breaks compilation when it sees these
> > functions. This has a few advantages:
> >
> > 1. We know it's run as part of a buil
On Thu, Jul 19, 2018 at 05:59:47PM -0400, Eric Sunshine wrote:
> > The one I brainstormed (but forgot to mention) is that it might be
> > possible for a platform to have strcpy as a macro already? In which case
> > we'd need to #undef it or risk a compilation error (even if the macro
> > isn't act
On Thu, Jul 19, 2018 at 02:47:35PM -0700, Stefan Beller wrote:
> > But that may be overly paranoid. Once upon a time there was some rules
> > lawyering around CodingGuidelines, but I think that was successfully
> > shut down and hasn't reared its head for several years.
>
> Heh; My preference wo
On July 19, 2018 6:46 PM, Junio wrote:
> Jeff King writes:
>
> > For enforcement, we can rely on the compiler and just introduce code
> > which breaks compilation when it sees these functions. This has a few
> > advantages:
> >
> > 1. We know it's run as part of a build cycle, so it's
> >
Jeff King writes:
> For enforcement, we can rely on the compiler and just
> introduce code which breaks compilation when it sees these
> functions. This has a few advantages:
>
> 1. We know it's run as part of a build cycle, so it's
> hard to ignore. Whereas an external linter is an extra
On Thu, Jul 19, 2018 at 5:27 PM Jeff King wrote:
> On Thu, Jul 19, 2018 at 05:11:15PM -0400, Eric Sunshine wrote:
> > On Thu, Jul 19, 2018 at 4:39 PM Jeff King wrote:
> > > + * This header lists functions that have been banned from our code base,
> > > + * because they're too easy to misuse (and
On Thu, Jul 19, 2018 at 2:32 PM Jeff King wrote:
>
> On Thu, Jul 19, 2018 at 02:15:54PM -0700, Stefan Beller wrote:
>
> > > Documentation/CodingGuidelines | 3 +++
> >
> > I'd prefer to not add more text to our documentation
> > (It is already long and in case you run into this problem
> > the er
On Thu, Jul 19, 2018 at 02:15:54PM -0700, Stefan Beller wrote:
> > Documentation/CodingGuidelines | 3 +++
>
> I'd prefer to not add more text to our documentation
> (It is already long and in case you run into this problem
> the error message is clear enough IMHO)
I'm fine with that too. I jus
On Thu, Jul 19, 2018 at 05:11:15PM -0400, Eric Sunshine wrote:
> On Thu, Jul 19, 2018 at 4:39 PM Jeff King wrote:
> > [...]
> > Let's start by banning strcpy() and sprintf(). It's not
> > impossible to use these correctly, but it's easy to do so
> > incorrectly, and there's always a better option
On Thu, Jul 19, 2018 at 1:39 PM Jeff King wrote:
>
> There are a few standard C functions (like strcpy) which are
> easy to misuse. We generally discourage these in reviews,
> but we haven't put advice in CodingGuidelines, nor provided
> any automated enforcement. The latter is especially
> import
On Thu, Jul 19, 2018 at 4:39 PM Jeff King wrote:
> [...]
> Let's start by banning strcpy() and sprintf(). It's not
> impossible to use these correctly, but it's easy to do so
> incorrectly, and there's always a better option.
> [...]
> Signed-off-by: Jeff King
> ---
> diff --git a/banned.h b/bann
22 matches
Mail list logo
