On Fri, Feb 16, 2018 at 11:19 AM, Martin Sebor wrote:
> On 02/16/2018 05:43 AM, Nick Clifton wrote:
>>
>> Hi David,
>>
>> Attached is a revised version of the patch which I hope addresses all
>> of your (very helpful) comments on the v3 patch.
>>
>> OK to apply once the sources are back on s
Hi Martin,
> I'm getting a bootstrap failure:
*sigh* yes - my bad. Fortunately a patch has already been posted:
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01039.html
And I think that it has now been approved.
Cheers
Nick
Hi Nick,
On Fri, Feb 16 2018, Nick Clifton wrote:
> Hi David,
>
> Attached is a revised version of the patch which I hope addresses all
> of your (very helpful) comments on the v3 patch.
>
> OK to apply once the sources are back on stage 1 ?
>
> Cheers
> Nick
>
> gcc/ChangeLog
> 2018-02-0
On 05/03/2018 03:55 AM, Nick Clifton wrote:
> Hi Jeff,
>
> Thanks for the review.
>
>> The docs still say "Control characters in the string will be replaced
>> with spaces", but they're being escaped now. That needs to be fixed.
>
> Done.
>
>> I note you overload the cast operator in your ne
Hi Jeff,
Thanks for the review.
> The docs still say "Control characters in the string will be replaced
> with spaces", but they're being escaped now. That needs to be fixed.
Done.
> I note you overload the cast operator in your new class. Why not just
> use an accessor? Was this style som
On Wed, May 02, 2018 at 11:00:20AM -0600, Jeff Law wrote:
> + escaped = (char *) xmalloc (len * 2 + 1);
> I believe that generally we want a slower growth pattern. You'll find
> that we regularly do something like len * 3 / 2 + 1. Seems wise here too.
We don't want to use xmalloc in
On 02/16/2018 05:43 AM, Nick Clifton wrote:
> Hi David,
>
> Attached is a revised version of the patch which I hope addresses all
> of your (very helpful) comments on the v3 patch.
>
> OK to apply once the sources are back on stage 1 ?
>
> Cheers
> Nick
>
> gcc/ChangeLog
> 2018-02-09
On 02/20/2018 05:48 AM, Nick Clifton wrote:
Hi Martin,
Since the class manages a resource it should ideally make sure it
doesn't try to release the same resource multiple times. I.e., its
copy constructor and assignment operators should either "do the right
thing" (whatever you think that is)
Hi Martin,
> Since the class manages a resource it should ideally make sure it
> doesn't try to release the same resource multiple times. I.e., its
> copy constructor and assignment operators should either "do the right
> thing" (whatever you think that is) or be made inaccessible (or declared
On 02/16/2018 05:43 AM, Nick Clifton wrote:
Hi David,
Attached is a revised version of the patch which I hope addresses all
of your (very helpful) comments on the v3 patch.
OK to apply once the sources are back on stage 1 ?
Thanks (also) for adding the documentation!
I have just one mi
On Fri, 2018-02-16 at 07:14 -0500, Trevor Saunders wrote:
> On Thu, Feb 15, 2018 at 04:04:45PM -0500, David Malcolm wrote:
> > On Fri, 2018-02-09 at 13:01 +, Nick Clifton wrote:
> > > +class escaped_string
> > > +{
> > > + public:
> > > + escaped_string () { m_owned = false; m_str = NULL; };
>
On Fri, 2018-02-16 at 12:43 +, Nick Clifton wrote:
> Hi David,
>
> Attached is a revised version of the patch which I hope addresses
> all
> of your (very helpful) comments on the v3 patch.
>
> OK to apply once the sources are back on stage 1 ?
Yes.
Thanks!
Dave
> Cheers
> Nick
>
Hi David,
Attached is a revised version of the patch which I hope addresses all
of your (very helpful) comments on the v3 patch.
OK to apply once the sources are back on stage 1 ?
Cheers
Nick
gcc/ChangeLog
2018-02-09 Nick Clifton
PR 84195
* tree.c (escaped_string):
On Thu, Feb 15, 2018 at 04:04:45PM -0500, David Malcolm wrote:
> On Fri, 2018-02-09 at 13:01 +, Nick Clifton wrote:
> > +class escaped_string
> > +{
> > + public:
> > + escaped_string () { m_owned = false; m_str = NULL; };
> > + ~escaped_string () { if (m_owned) free (m_str); }
> > + operato
On Fri, 2018-02-09 at 13:01 +, Nick Clifton wrote:
> Hi David, Hi Martin,
>
> OK, take 3 of the patch is attached. In this version:
>
> * The escaping is handled by a new class.
> * Self-tests have been added (and they helped find a bug - yay!)
> * The documentation has been extended
Hi David, Hi Martin,
OK, take 3 of the patch is attached. In this version:
* The escaping is handled by a new class.
* Self-tests have been added (and they helped find a bug - yay!)
* The documentation has been extended to mention -fmessage-length's
effect on the #-directives, and to
On 02/08/2018 04:04 AM, Nick Clifton wrote:
Hi David,
+ /* PR 84195: Replace control characters in the message with their
+escaped equivalents. Allow newlines if -fmessage-length has
+been set to a non-zero value.
I'm not quite sure why we allow newlines in th
Hi David,
>> + /* PR 84195: Replace control characters in the message with their
>> + escaped equivalents. Allow newlines if -fmessage-length has
>> + been set to a non-zero value.
>
> I'm not quite sure why we allow newlines in this case, sorry.
Because the documentation
On Wed, 2018-02-07 at 17:26 +, Nick Clifton wrote:
> Hi Martin, Hi David,
>
> OK - attached is a new patch that:
>
> * Replaces control characters with their escape equivalents.
> * Includes a testcase.
>
> I was not sure what to do about the inconsistencies between the
> behaviour of #w
Hi Martin, Hi David,
OK - attached is a new patch that:
* Replaces control characters with their escape equivalents.
* Includes a testcase.
I was not sure what to do about the inconsistencies between the
behaviour of #warning and #pragma GCC warning, (and the error
equivalents), so I decided
On 02/06/2018 05:39 AM, Nick Clifton wrote:
Hi Martin,
My only suggestions are to consider how control characters and
excessively messages are handled in other contexts and adopt
the same approach here.
Are there other places where user-supplied messages are displayed by gcc ?
There are a f
On Tue, 2018-02-06 at 12:39 +, Nick Clifton wrote:
> Hi Martin,
>
> > My only suggestions are to consider how control characters and
> > excessively messages are handled in other contexts and adopt
> > the same approach here.
>
> Are there other places where user-supplied messages are display
Hi Martin,
> My only suggestions are to consider how control characters and
> excessively messages are handled in other contexts and adopt
> the same approach here.
Are there other places where user-supplied messages are displayed by gcc ?
> In the tests I did, control characters
> were mostly
On 02/05/2018 10:07 AM, Nick Clifton wrote:
Hi Martin, Hi Dodji, Hi David,
PR 84195 makes the point that deprecation messages do not follow the
formatting guidelines set out by the -fmessage-length option, and that
they could even contain unwanted control characters:
https://gcc.gnu.org/b
Hi Martin, Hi Dodji, Hi David,
PR 84195 makes the point that deprecation messages do not follow the
formatting guidelines set out by the -fmessage-length option, and that
they could even contain unwanted control characters:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84195
Below is my
25 matches
Mail list logo
