This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB 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 to support spaces in filenames & paths


I made some experiments with parse_to_comma_and_eval, but I think I must be sure to understand what you need before going further in my implementation, and summarize the situation
My original proposal (http://sourceware.org/ml/gdb-patches/2008-12/msg00029.html) allows spaces in dump/restore/append command arguments, having the constraint for user to quote its arguments that contains spaces, but that doesn't break actual gdb behavior.


Then Doug said

While perhaps not applicable in Denis' case (since the command accepts

"a b c" instead of "a, b, c" (though I wonder if it could accept

both), for completeness' sake there is also parse_to_comma_and_eval.


In the current implementation, space is considered as a separator for all arguments, except for the last that can contains any spaces and will be evaluated entirely.
Accepting "a, b, c" as 3 argument consists in making comma the separator for arguments, and that will break existing front-ends, it's an API change.


The patch I have proposed accepts "a, b, c" but considers it's a single argument, like it could be for any expression with coma (ie "max(a, b)").

Please enlighten me on what kind of syntax you'd like dump/restore/append to accept, knowing that a, b and c could also be complex expressions with comma and spaces as well.

Thanks for your feedback
--
Denis



Daniel Jacobowitz wrote:
On Thu, Dec 04, 2008 at 10:37:39AM +0100, Denis PILAT wrote:
Actual implementation of append/dump/restore does not accept spaces at all, except in the last argument, and I think it's just a side effect.
To me comma must not be considered as a separator since dump command accepts expression and the calculation of START , END address or OFFSET is often a function call like sizeof (), but can be more than that like a function that takes more than one parameters, "max(a,b)" or whatever.

I don't think it applies here, but take a peek at the function Doug mentioned - it does handle nested commas. It's not perfect, but it's pretty good.



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