On 11/27/2013 05:46 AM, Marek Polacek wrote:> On Wed, Nov 27, 2013 at
05:29:22AM -0500, mtewoodb...@gmail.com wrote:
>> From: Max TenEyck Woodbury <max+...@mtew.isa-geek.net>
>
> This patch is badly missing a description. You also want to mention
> the PR number, if this fixes a bug. I guess this is to fix PR58687.
>
I am new to GNU patching. There is some description on Bugzilla. At
least one other group I have worked with disliked bug number references
in patches.
Please point me to the formatting requirements for change log entries...
On 11/27/2013 11:21 AM, Joseph S. Myers wrote:
On Wed, 27 Nov 2013, mtewoodb...@gmail.com wrote:
Copyright 2013 assigned to the Free Software Foundation.
FWIW I don't see this in copyright.list yet. If you sent the paperwork
(whether paper mail or scans) to the FSF over a week ago and haven't had
it acknowledged, please chase up ass...@gnu.org, and keep chasing them up
weekly until it's acknowledged and a maintainer confirms it's now listed
in copyright.list.
I am a new at GNU patching. I had hoped that a simple assignment in
the document would be sufficient. I really do not want to turn
Everything I do over to FSF...
diff --git a/gcc/testsuite/gcc.dg/cpp/line4.c b/gcc/testsuite/gcc.dg/cpp/line4.c
I think it's best to leave this test as-is and add a new test line9.c
specifically for this case of "#line __LINE__". Changing existing tests
unnecessarily complicates establishing whether a newly seen failure is a
regression or not.
HMM? Not sure I understand that line of reasoning. The test is about
setting the line number. This just adds the __LINE__ special case.
I think it would be worth including tests where the __LINE__ expansion
(which as you note should be the line number of the line *after* the
directive) is involved in concatenation or stringized, e.g.
#define xstr(x) #x
#define str(x) xstr(x)
#line 1 str(__LINE__)
which should set __FILE__ to be the stringized number of the line after
the directive. (I hope these cases will just work given your patch, so
this is just a matter of adding more to the testcase.)
This patch would not do that. It only fixes the use of __LINE__ when
used to reset the line number. There are at least two ways this could
be implemented and keep with the standard:
One would be to set the new line value as soon as it is seen in the
'# line' directive and let the normal __LINE__ tracking take care of
the end-of-line increments. That would require a larger change than
this patch and would have implications when it comes to error handling.
The other is to postpone macro expansion until the end of the directive
has been seen. That would require two passes over the token sequence;
one to build the sequence and a second to evaluate it. Doing that is
'the right thing' in my opinion but it should be applied to all the
other directives that permit <pp-token> substitution as well. I tried
to do it that way initially, but that requires a deeper understanding
of the current implementation than I was able to build quickly. I
would like to see a 'theory of operation' document that contained such
details, as some commercial software shops require, but that does not
seem to be how it is done here.
So I punted...
