On Sat, Jul 15, 2017 at 07:43:09AM +0900, Mike Hommey wrote:
> > - There were occasional cases where we wished if variable-length
> >arrays, flexible array members and variadic macros were available
> >in our codebase during the course of this project. We would
> >probably want to ad
On Fri, Jul 14, 2017 at 09:11:33AM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Oh, absolutely.
> >
> > Here is another possible test balloon, that may actually be useful
> > as an example. I think there is a topic in flight that touches this
> > array, unfortunately, so I probabl
Ævar Arnfjörð Bjarmason writes:
> On Fri, Jul 14 2017, Junio C. Hamano jotted:
>
>> Junio C Hamano writes:
>>
>> - This may be showing I am not just old fashioned but also am
>>ignorant, but I do not see much point in using the following in
>>our codebase (iow, I am not aware of places
On Fri, Jul 14 2017, Junio C. Hamano jotted:
> Junio C Hamano writes:
>
> - This may be showing I am not just old fashioned but also am
>ignorant, but I do not see much point in using the following in
>our codebase (iow, I am not aware of places in the existing code
>that they can b
Junio C Hamano writes:
> Do we need to have a check to detect a buggy compiler that takes the
> syntax but produces an incorrectly initialized array? I could add a
> test to ensure that HEADER comes out BOLD, etc. (or we may already
> have such a test) and then reorder these lines in this patch,
Jeff King writes:
>> +static int clean_use_color = -1;
>> +static char clean_colors[][COLOR_MAXLEN] = {
>> +[CLEAN_COLOR_RESET] = GIT_COLOR_RESET,
>> +[CLEAN_COLOR_PLAIN] = GIT_COLOR_NORMAL,
>> +[CLEAN_COLOR_PROMPT] = GIT_COLOR_BOLD_BLUE,
>> +[CLEAN_COLOR_HEADER] = GIT_COLOR_BOLD,
On Fri, Jul 14, 2017 at 09:11:33AM -0700, Junio C Hamano wrote:
> As to other things that we currently not allow in our codebase that
> newer compilers can grok, here is what *I* think. It is *not* meant
> to be an exhaustive "what's new in C99 that is not in C89? what is
> the final verdict on e
On Fri, Jul 14, 2017 at 9:11 AM, Junio C Hamano wrote:
> - I prefer to keep decl-after-statement out of our codebase. I
>view it as a big plus in code-readability to be able to see a
>complete list of variables that will be used in a block upfront
>before starting to read the code t
Junio C Hamano writes:
> Oh, absolutely.
>
> Here is another possible test balloon, that may actually be useful
> as an example. I think there is a topic in flight that touches this
> array, unfortunately, so I probably would find another one that is
> more stable for a real follow-up patch to t
Am 12.07.2017 um 21:12 schrieb Ævar Arnfjörð Bjarmason:
I think in the context of this desire Johannes Sixt's "Actually, I'm
serious [about let's compile with c++]"[1] should be given some more
consideration.
Thank you for your support.
I've just compiled Git with it and it passes all tests.
Ævar Arnfjörð Bjarmason writes:
> On Tue, Jul 11 2017, Junio C. Hamano jotted:
>
>> Just so that people do not misunderstand, it is not our goal to
>> declare that now you need a fully C99 compiler to build Git.
>> ...
>
> I think in the context of this desire Johannes Sixt's "Actually, I'm
> ser
On Tue, Jul 11 2017, Junio C. Hamano jotted:
> Ben Peart writes:
>
>>> If this patch can survive a few releases without complaint,
>>> then we can feel more confident that designated initializers
>>> are widely supported by our user base. It also is an
>>> indication that other C99 features may
Am 12.07.2017 um 03:26 schrieb brian m. carlson:
On Tue, Jul 11, 2017 at 07:24:07AM +0200, Johannes Sixt wrote:
I can revive the patches if there is interest.
I'd be interested in at least a pointer to them if you have one. I
think it might allow us to take advantage of desirable features tha
On Tue, Jul 11, 2017 at 07:24:07AM +0200, Johannes Sixt wrote:
> Am 11.07.2017 um 02:05 schrieb brian m. carlson:
> > I have tried compiling Git with a C++ compiler, so that I could test
> > whether that was a viable alternative for MSVC in case its C++ mode
> > supported features its C mode did no
Ben Peart writes:
>> If this patch can survive a few releases without complaint,
>> then we can feel more confident that designated initializers
>> are widely supported by our user base. It also is an
>> indication that other C99 features may be supported, but not
>> a guarantee (e.g., gcc had d
Am 11.07.2017 um 02:05 schrieb brian m. carlson:
On Mon, Jul 10, 2017 at 09:57:40PM +0200, Johannes Sixt wrote:
It's a pity, though, that you do not suggest something even more useful,
such as C++14.
I have tried compiling Git with a C++ compiler, so that I could test
whether that was a viable
On Mon, Jul 10, 2017 at 10:57:57AM -0400, Ben Peart wrote:
> Correct. MSVC also supports designated initializers but does not fully
> support C99.
Precision: *recent versions* of MSVC support designated initializer.
2013 introduced them, but there were bugs until 2015, see e.g.
https://stackoverf
On Mon, Jul 10, 2017 at 11:11:35PM +0200, Johannes Sixt wrote:
> > I am not sure what negative impact you think the macro-ness would
> > have to the validity of the result from this test balloon. An old
> > compiler that does not understand designated initializer syntax
> > would fail to compile
On Mon, Jul 10, 2017 at 05:07:43PM -0700, Stefan Beller wrote:
> On Mon, Jul 10, 2017 at 5:05 PM, brian m. carlson
> wrote:
> > On Mon, Jul 10, 2017 at 09:57:40PM +0200, Johannes Sixt wrote:
> >> It's a pity, though, that you do not suggest something even more useful,
> >> such as C++14.
> >
> > I
On Mon, Jul 10, 2017 at 5:05 PM, brian m. carlson
wrote:
> On Mon, Jul 10, 2017 at 09:57:40PM +0200, Johannes Sixt wrote:
>> It's a pity, though, that you do not suggest something even more useful,
>> such as C++14.
>
> I have tried compiling Git with a C++ compiler, so that I could test
> whether
On Mon, Jul 10, 2017 at 09:57:40PM +0200, Johannes Sixt wrote:
> It's a pity, though, that you do not suggest something even more useful,
> such as C++14.
I have tried compiling Git with a C++ compiler, so that I could test
whether that was a viable alternative for MSVC in case its C++ mode
suppor
masse for the remainder of the system?
> >
> > That way, we will see if there are people who need pre-C99 soon
> > enough, and we won't have to scramble reverting too many changes
> > when it happens.
>
> Neat idea. Something like this?
>
> -- >8 --
&g
Stefan Beller writes:
> On Mon, Jul 10, 2017 at 9:44 AM, Junio C Hamano wrote:
>
> Credit goes to Brandon for spotting it, but the introduction of
> "trailing comma at the end of enum definition is allowed in c99"
> is e1327023ea (grep: refactor the concept of "grep source" into
> an object, 201
Johannes Sixt writes:
>> I am not sure what negative impact you think the macro-ness would
>> have to the validity of the result from this test balloon. An old
>> compiler that does not understand designated initializer syntax
>> would fail to compile both the same way, no?
>>
>> struct str
Actually, I'm serious.
Subject: [PATCH] strbuf: use designated initializers in STRBUF_INIT
-#define STRBUF_INIT { 0, 0, strbuf_slopbuf }
+#define STRBUF_INIT { .alloc = 0, .len = 0, .buf = strbuf_slopbuf }
While this may serve as a test balloon, changing STRBUF_INIT, or any
of those _INIT
Johannes Sixt writes:
> It's a pity, though, that you do not suggest something even more
> useful, such as C++14.
I cannot tell if this part is tongue-in-cheek (especially the "++"),
so I will ignore it to avoid wasting time.
>> Subject: [PATCH] strbuf: use
ore modern build
environment.
by starting to use some of the useful
features like designated initializers,
It's a pity, though, that you do not suggest something even more useful,
such as C++14.
Subject: [PATCH] strbuf: use designated initializers in STRBUF_INIT
-#define STRB
On 7/10/2017 12:04 PM, Jeff King wrote:
On Mon, Jul 10, 2017 at 10:57:57AM -0400, Ben Peart wrote:
If this patch can survive a few releases without complaint,
then we can feel more confident that designated initializers
are widely supported by our user base. It also is an
indication that oth
On Mon, Jul 10, 2017 at 9:44 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>>> That way, we will see if there are people who need pre-C99 soon
>>> enough, and we won't have to scramble reverting too many changes
>>> when it happens.
>>
>> Neat idea. Something like this?
>
> Yes, your log messag
On Jul 10 2017, Jeff King wrote:
> If this patch can survive a few releases without complaint,
> then we can feel more confident that designated initializers
> are widely supported by our user base. It also is an
> indication that other C99 features may be supported, but not
> a guarantee (e.g.,
t;grep: add
submodules as a grep source type", 2016-12-16).
> -- >8 --
> Subject: [PATCH] strbuf: use designated initializers in STRBUF_INIT
>
> There are certain C99 features that might be nice to use in
> our code base, but we've hesitated to do so in order to
> avoi
On Mon, Jul 10, 2017 at 10:57:57AM -0400, Ben Peart wrote:
> > If this patch can survive a few releases without complaint,
> > then we can feel more confident that designated initializers
> > are widely supported by our user base. It also is an
> > indication that other C99 features may be suppor
ed pre-C99 soon
enough, and we won't have to scramble reverting too many changes
when it happens.
Neat idea. Something like this?
-- >8 --
Subject: [PATCH] strbuf: use designated initializers in STRBUF_INIT
There are certain C99 features that might be nice to use in
our code base, but
people who need pre-C99 soon
> enough, and we won't have to scramble reverting too many changes
> when it happens.
Neat idea. Something like this?
-- >8 --
Subject: [PATCH] strbuf: use designated initializers in STRBUF_INIT
There are certain C99 features that might be nice to us
34 matches
Mail list logo
