Re: [GSoC][RFC][PATCH 1/2] STRBUF_INIT_CONST: a new way to initialize strbuf

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 18, 2020 at 8:21 AM Jeff King <peff@xxxxxxxx> wrote:
> Your second patch catches cases where the strbuf functions want to write
> to the buffer. But we've always been pretty open about the fact that
> strbuf.buf is a writeable C-style string. So something like this:
> ...
> would generate no compile-time warnings, but would invoke undefined
> behavior (on my system it segfaults when run, but it could have even
> more confusing outcomes).
Oh right, I didn't think about that. Ignorant of me to expect everyone to just
call the functions and not edit the buf directly.

> If we want to pursue this direction, I think we'd do better to give each
> strbuf a matching array. Something like:
> ...
> So I think there are interesting directions here, but there's a lot of
> stuff to figure out.
I think that got me a bit fired up now.

> I notice you put GSoC in your subject line. If you're looking at this as
> a microproject, IMHO this is _way_ more complicated and subtle than a
> microproject should be. The goal there is to give something so easy that
> you get to focus on getting your patches in and interacting with the
> community. The scope I'd expect is more along the lines of compiling
> with -Wwrite-strings and cleaning up some of the locations that
> complain.
I'm actually planning to keep on contributing to git, so I kind of
didn't want to
do something trivial. Despite the fact that I'm planning to apply to
git for GSoC,
I'm mostly putting the [GSoC] so that reviewers would go easy on me :D. That
said, I might actually do the -Wwrite-strings clean-up after this one
is finished.

Thanks for the help, I guess I'll start editing it ASAP, then.

- mo7sener



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux