parser-devel Mailing List for Configuration File Parser (Page 2)
Status: Beta
Brought to you by:
jineshkj
Menu
▾
▴
parser-devel — The parser library developers mailing list
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(23) |
Nov
(4) |
Dec
|
|---|
|
From: Jinesh K J <jin...@gm...> - 2006-10-04 02:17:05
|
> Ok, I uploaded my first attempt, but I'm wondering whether the input
> always has '[' and ']'? Can there be stuff outside the brackets? eg
> @[group 1] hello@ -> @group 1@
If anything comes outside the box, let us ignore that. What do you
say? Could there be a better way?
Also, note that I've updated the test cases. I hope the assertion can
be avoided and I've updated the test cases to include those cases.
116 char * getgroup(const char *string)
117 {
118 assert(string[0] == '[');
> > I wish if we can just do an exit(-1), whenever such an error occurs.
> >
> I put that in, but isn't there any better way to signal errors?
Yes ! This policy must be changed. But, let's keep it aside, since
memory allocation is least likely to fail in Linux. We can clean this
stuff as soon as we get our functionalities right.
Regards,
Jinesh.
|
|
From: Noam P. <npo...@uw...> - 2006-10-03 03:33:46
|
Jinesh K J wrote: > Hi Noam, > > As I've mentioned in the previous mail, I'm working on integrating > gettoken() and puttoken() into the trunk. Mean while I would like to > have one more functionality as given below: > > char *groupname(char *input) > > Here, input would be a string which containts a group name within > '[]'. Examples for input are given below: > > @[group1]@ -> @group1@ > @[group 1]@ -> @group 1@ > > Please note that '[' and ']' are included in the input(so that i've > used '@' as cover). ie, What ever that comes in between those square > brackets are to be extracted as a single token. But, even inside the > square brackets, quoted values must be possible. For example: > > @["group"]@ -> @group@ > @["group 1"]@ -> @group 1@ > @["group [H]"]@ -> @group [H]@ > @[group "[H]"]@ -> @group [H]@ > @[group "[H\\T]"]@ -> @group [H\T]@ > ... > > All the rules for quoted values we used for gettoken() are valid here > also. So, I wish if we could use gettoken here too. > Ok, I uploaded my first attempt, but I'm wondering whether the input always has '[' and ']'? Can there be stuff outside the brackets? eg @[group 1] hello@ -> @group 1@ > Also, in token.c, all the memory allocation functions' return value > are unchecked. For example, in puttoken() after calling calloc(), str > is not checked for NULL. > > char *str = calloc(2+1, sizeof(char)); > str[0] = str[1] = '"'; > str[2] = '\0'; > return str; > > > I wish if we can just do an exit(-1), whenever such an error occurs. > I put that in, but isn't there any better way to signal errors? Noam |
|
From: Noam P. <npo...@uw...> - 2006-09-27 23:19:55
|
Jinesh K J wrote: >> I think the next thing to do is handle invalid input: eg unclosed >> quotes, right now that causes a segfault. I'm not sure what the >> appropriate way of signalling an error would be. > Ohh! That's a very serious issue. Good that you reminded me. Don't worry. > If the quote doesn't close, let the '\0' at the end of string be taken for granted. Done > >> >> Noam > > BTW, I've added -Wall to cc and some warnings have been removed. One is still left, > which is in token.c. See below: > > [jinesh@jinesh np]$ make > cc -Wall -g -D DETAILED=0 token.c > > main.c > token.c: In function 'gettoken': > token.c:78: warning: ignoring return value of 'realloc', declared with attribute warn_unused_result > > I hope that the realloc return value could be used. What so you say? > > > > Jinesh. > I say: oops, I should read the docs on realloc more carefully :P I fixed all the test cases except one I think is wrong: [Hello ' World ] -> ["Hello ' World " ] The extra space at the end is just a typo, right? Noam. |
|
From: Jinesh K J <jin...@gm...> - 2006-09-27 08:18:55
|
> Ok, I guess I was confused because I was looking at the test cases with > the shell, (using echo "foo") to get rid of the backslashes. I've > updated the repository so all the test cases now work. > Yes! Now everthing is fine. I'll now start working on test cases for puttoken(). > I think the next thing to do is handle invalid input: eg unclosed > quotes, right now that causes a segfault. I'm not sure what the > appropriate way of signalling an error would be. Ohh! That's a very serious issue. Good that you reminded me. Don't worry. If the quote doesn't close, let the '\0' at the end of string be taken for granted. > > Noam BTW, I've added -Wall to cc and some warnings have been removed. One is still left, which is in token.c. See below: [jinesh@jinesh np]$ make cc -Wall -g -D DETAILED=0 token.c main.c token.c: In function 'gettoken': token.c:78: warning: ignoring return value of 'realloc', declared with attribute warn_unused_result I hope that the realloc return value could be used. What so you say? Jinesh. |
|
From: Jinesh K J <jin...@gm...> - 2006-09-27 07:01:39
|
> Ok, I guess I was confused because I was looking at the test cases with > the shell, (using echo "foo") to get rid of the backslashes. I've > updated the repository so all the test cases now work. > Yes! Now everthing is fine. I'll now start working on test cases for puttoken(). > I think the next thing to do is handle invalid input: eg unclosed > quotes, right now that causes a segfault. I'm not sure what the > appropriate way of signalling an error would be. Ohh! That's a very serious issue. Good that you reminded me. Don't worry. If the quote doesn't close, let the '\0' at the end of string be taken for granted. > > Noam BTW, I've added -Wall to cc and some warnings have been removed. One is still left, which is in token.c. See below: [jinesh@jinesh np]$ make cc -Wall -g -D DETAILED=0 token.c main.c token.c: In function 'gettoken': token.c:78: warning: ignoring return value of 'realloc', declared with attribute warn_unused_result I hope that the realloc return value could be used. What so you say? Jinesh. |
|
From: Noam P. <npo...@uw...> - 2006-09-27 03:20:21
|
Jinesh K J wrote: >> So you're saying escapes only occur within quotes? I'm not sure that >> this makes sense: what if you wanted to put in a quote at then end of a >> token, eg [hello\" world] -> [hello"] > If someone want to use a quote, then let them use them inside a quote. > For the above case that you've mentioned, the solution would be: > > ["hello\""] -> [hello"] > or > ['hello"'] -> [hello"] > > What do you think? > Ok, I guess I was confused because I was looking at the test cases with the shell, (using echo "foo") to get rid of the backslashes. I've updated the repository so all the test cases now work. I think the next thing to do is handle invalid input: eg unclosed quotes, right now that causes a segfault. I'm not sure what the appropriate way of signalling an error would be. Noam |
