This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals


Bernd Edlinger <bernd.edlinger@hotmail.de> writes:

>>> Using -- on a value that goes out of scope looks
>>> awkward IMHO.
>>
>> I don't understand this sentence. What do you mean by "Using -- on a
>> value that goes out of scope"?
>>
>
> I meant the operator -- in *line_len = --len;

Sorry, I don't see how that is an issue.  This looks like a classical
way of passing an output parameter to me.

> Maybe, You could also avoid the copying completely, if you just hand out
> a pointer to the line buffer as const char*, and use the length instead of the
> nul-char as end delimiter ?

I thought about avoiding the copying of course.  But the issue with that
is that that ties the lifetime of the returned line to the time between
two invocations of read_next_line.  IOW, you'd have to use the line
"quickly" before calling read_next_line again.  Actually that
non-copying API that you are talking about exists in the patch; it's
get_next_line.  And you see that it's what we use when we want to avoid
the copying, e.g, in goto_next_line.  But when we want to give the
"final" user the string, I believe that copying is less surprising.  And
from what I could see from the tests I have done, the copying doesn't
make the thing slower than without the patch.  So I'd like to keep this
unless folks have very strong feeling about it.

-- 
		Dodji


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]