parser-devel Mailing List for Configuration File Parser
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-11-24 14:24:12
|
Hi Noam, I hope you might remember what I had mentioned about a UI for the parser library. I've planned and started work on a CLI for the same. The first commit has added the trunk/ui/cli directory that contains the files to start with. Just let me know if any suggestions you have abt the same. This CLI will ultimately form the backend for Curses/Gtk/Qt based UI. Jinesh. |
|
From: Jinesh K J <jin...@gm...> - 2006-11-06 04:14:32
|
On 11/4/06, Noam Postavsky <npo...@uw...> wrote: > "Jinesh K J" <jin...@gm...> writes: > > > > hi, > > > > BTW, do you think having a configuration file editor will be an added > > advantage? I was thinking about creating a curses/gtk/qt based UI > > using this library. What do you think? > > Well, I am interested in writing such a thing: I've been wanting to > learn a UI besides the Java awt/swing for a while, just haven't had a > motivating project for it. I hope we can make it more useful than the I hope this can be a good start for you then. BTW, which UI library would you like to use - I prefer you chose one from Curses, Gtk, Qt. > firefox about:config type editor, that's not much better than a > standard text editor. But then we'd probably need meta-information > about each config option to be stored somewhere, which gets > complicated... I think we can use comments for that. What do you think? I that way anyone who opens the config file will also get to know what each option means. |
|
From: Noam P. <npo...@uw...> - 2006-11-04 01:33:36
|
"Jinesh K J" <jin...@gm...> writes: > > hi, > > BTW, do you think having a configuration file editor will be an added > advantage? I was thinking about creating a curses/gtk/qt based UI > using this library. What do you think? Well, I am interested in writing such a thing: I've been wanting to learn a UI besides the Java awt/swing for a while, just haven't had a motivating project for it. I hope we can make it more useful than the firefox about:config type editor, that's not much better than a standard text editor. But then we'd probably need meta-information about each config option to be stored somewhere, which gets complicated... |
|
From: Jinesh K J <jin...@gm...> - 2006-11-03 13:09:27
|
On 10/27/06, Noam Postavsky <npo...@uw...> wrote: > "Jinesh K J" <jin...@gm...> writes: > > > Hi Noam, > > > > I'm happy to inform you that parser version 0.6 has been released. > > BTW, I was thinking about adding unicode support for library. Do you > > think it is possible? > > Not sure what you mean by unicode support exactly. Write now the > library will work fine, as far as I can tell, if the .conf file has > some multilingual stuff, as long as then encoding is utf-8. In utf-8 > the encodings for =, [, ], ', and " remain the same as ascii, and > there are no 0x00 bytes(NULL) in any normal printable characters. For > any other characters it doesn't matter since the library only operates > on the bytes. I guess it might not work for other encodings > though. Perhaps the library doesn't need to support other encodings > though, we could simply require programs to convert input to utf-8 > using iconv (http://www.gnu.org/software/libiconv/) for instance. > hi, I was out of town for the past week, sorry for the delayed reply. Yes, I found your updates in test.conf. I think UTF-8 support is working sufficiently well - no issues that I can find. BTW, do you think having a configuration file editor will be an added advantage? I was thinking about creating a curses/gtk/qt based UI using this library. What do you think? Jinesh. |
|
From: Noam P. <npo...@uw...> - 2006-10-27 00:16:31
|
"Jinesh K J" <jin...@gm...> writes: > Hi Noam, > > I'm happy to inform you that parser version 0.6 has been released. > BTW, I was thinking about adding unicode support for library. Do you > think it is possible? Not sure what you mean by unicode support exactly. Write now the library will work fine, as far as I can tell, if the .conf file has some multilingual stuff, as long as then encoding is utf-8. In utf-8 the encodings for =, [, ], ', and " remain the same as ascii, and there are no 0x00 bytes(NULL) in any normal printable characters. For any other characters it doesn't matter since the library only operates on the bytes. I guess it might not work for other encodings though. Perhaps the library doesn't need to support other encodings though, we could simply require programs to convert input to utf-8 using iconv (http://www.gnu.org/software/libiconv/) for instance. |
|
From: Jinesh K J <jin...@gm...> - 2006-10-24 12:09:47
|
Hi Noam, I'm happy to inform you that parser version 0.6 has been released. BTW, I was thinking about adding unicode support for library. Do you think it is possible? Jinesh. |
|
From: Noam P. <npo...@uw...> - 2006-10-20 19:44:11
|
"Jinesh K J" <jin...@gm...> writes: > Hi Noam, > > We've not been in contact for the past few days. I observed inactivity > in svn in the recent times and think that your modifications are over. > If that is the case then may be I can go forward with the next > release. What do you say? > > Regards, > Jinesh. Yes I'm finished the changes. I was trying out some other possible ideas but they were all dead ends. I've merged my changes to the trunk, along with some cosmetic changes to the documentation, although there I got an error when committing it seems to have gone through. svn: MERGE request failed on '/svnroot/parser/trunk' svn: MERGE of '/svnroot/parser/trunk': 500 Internal Server Error (https://svn.sourceforge.net) Noam |
|
From: Jinesh K J <jin...@gm...> - 2006-10-20 13:06:29
|
Hi Noam, We've not been in contact for the past few days. I observed inactivity in svn in the recent times and think that your modifications are over. If that is the case then may be I can go forward with the next release. What do you say? Regards, Jinesh. |
|
From: Jinesh K J <jin...@gm...> - 2006-10-17 15:06:22
|
On 10/17/06, Noam Postavsky <npo...@uw...> wrote: > "Jinesh K J" <jin...@gm...> writes: > > > I didn't really understand what you meant by 'out if date'; which is > > the updated one? So, you wish to work only on your functions(in > > branches/np/) or the entire trunk/ ? > > 'out of date' means not updated, or old. Basically I want to work on > the version of my functions from the trunk/ because they are the > updated ones, but I want to use the testcases from branches/np/ Then what you may do is: svn copy trunk/file.c branches/np/ svn copy trunk/transform.c branches/np/ file.c contains puttoken() whereas the rest are in transform.c You may then change the branches/np/Makefile to use these files instead of token.c and comment.c. After each satisfactory modifications you make, we will merge these files back into the trunk/. > > > Also, kindly see whether your code can be made more readable - coz > > that's very important as far as collaborative efforts are concerned. > > I would like to make my code more readable, but the problem is that it > looks readable to me because I wrote it. I would greatly appreciate it > if you could tell me what makes it less readable and/or ways to make > it more readable. Yes. I'll try to find out what all things could be done. > > >> > >> I was also wondering if there is an important reason to use char * > >> instead of const char * in my functions. I always though that a > >> function should declare char pointers const if it doesn't modify the > >> string... > >> > > Yes. you're right. I just changed them to char * to remove a few > > warnings (I dont really remember where they were). But we can surely > > re-introduce the 'const' before the next release. > > > > Also, in the mean time, I'm doing some serious rework over the > > transform() function in the transform.c. > > Actually after I sent that, I thought of a reason to keep it as char*: > it would allow changing the implementation to one that modifies the > string. I guess we should figure out if transform() requires that the > string remains constant, after you finish your reworking of course. My work is now almost over - All my planned tasks have been completed. Re-introduction of 'const' can be done along this process. Let me know when you want the changes(in file.c and transform.c) to be merged. Regards, Jinesh. |
|
From: Noam P. <npo...@uw...> - 2006-10-17 12:22:47
|
"Jinesh K J" <jin...@gm...> writes: > I didn't really understand what you meant by 'out if date'; which is > the updated one? So, you wish to work only on your functions(in > branches/np/) or the entire trunk/ ? 'out of date' means not updated, or old. Basically I want to work on the version of my functions from the trunk/ because they are the updated ones, but I want to use the testcases from branches/np/ > Also, kindly see whether your code can be made more readable - coz > that's very important as far as collaborative efforts are concerned. I would like to make my code more readable, but the problem is that it looks readable to me because I wrote it. I would greatly appreciate it if you could tell me what makes it less readable and/or ways to make it more readable. >> >> I was also wondering if there is an important reason to use char * >> instead of const char * in my functions. I always though that a >> function should declare char pointers const if it doesn't modify the >> string... >> > Yes. you're right. I just changed them to char * to remove a few > warnings (I dont really remember where they were). But we can surely > re-introduce the 'const' before the next release. > > Also, in the mean time, I'm doing some serious rework over the > transform() function in the transform.c. Actually after I sent that, I thought of a reason to keep it as char*: it would allow changing the implementation to one that modifies the string. I guess we should figure out if transform() requires that the string remains constant, after you finish your reworking of course. Noam |
|
From: Jinesh K J <jin...@gm...> - 2006-10-17 04:04:39
|
On 10/17/06, Noam Postavsky <npo...@uw...> wrote: > "Jinesh K J" <jin...@gm...> writes: > > > If you think you can make more optimisations over the stuff, then we > > can make a different branch for you to work on. After your tweaks, we > > can merge it to the main trunk. What do you say? > > Yes, I want to do a few things, but already the old branch with the > test cases I was using is slightly out of date. So is there an > easy way to bring it up to date? I didn't really understand what you meant by 'out if date'; which is the updated one? So, you wish to work only on your functions(in branches/np/) or the entire trunk/ ? Also, kindly see whether your code can be made more readable - coz that's very important as far as collaborative efforts are concerned. > > I was also wondering if there is an important reason to use char * > instead of const char * in my functions. I always though that a > function should declare char pointers const if it doesn't modify the > string... > Yes. you're right. I just changed them to char * to remove a few warnings (I dont really remember where they were). But we can surely re-introduce the 'const' before the next release. Also, in the mean time, I'm doing some serious rework over the transform() function in the transform.c. Jinesh. |
|
From: Noam P. <npo...@uw...> - 2006-10-17 02:52:20
|
"Jinesh K J" <jin...@gm...> writes: > If you think you can make more optimisations over the stuff, then we > can make a different branch for you to work on. After your tweaks, we > can merge it to the main trunk. What do you say? Yes, I want to do a few things, but already the old branch with the test cases I was using is slightly out of date. So is there an easy way to bring it up to date? I was also wondering if there is an important reason to use char * instead of const char * in my functions. I always though that a function should declare char pointers const if it doesn't modify the string... Noam |
|
From: Jinesh K J <jin...@gm...> - 2006-10-14 11:41:48
|
On 10/14/06, Noam Postavsky <npo...@uw...> wrote: > "Jinesh K J" <jin...@gm...> writes: > > > I'm resending the mail - I believe your mail server did not accept the > > original one as given below: > Yes, I had a core dump file filling my quota. > > > On 10/12/06, Jinesh K J <jin...@gm...> wrote: > >> Hi Noam, > >> > >> So in the end, the parser library is ready to go. You might wanna go > >> to trunk/ and modify some stuff yourself. May be you wanna add your > >> name into the MAINTAINERS file or something else too. > >> > >> One thing that you've not yet done is the documentation of the new > >> functions. If you like to do it, may be you can start learning > >> Doxygen. Let me know if you want me do it for you - if you are not > >> comfortable with code documentation. > > I'll see if I can handle it, doesn't look too different from TeX. Its very simple. You can see the existing code for example. > > >> Since all the functionalities are in place you might also wanna make > >> it (new functions) more modularised. Its up to you. > > I guess there is a bit of duplication with copy stuff up to char X... > > Do you think it would be worth making a gettoken_noalloc? It would > save one memory allocation in getgroup. It doesn't matter(atleast for the time being), even if we do unnecessary memory allocations - what do need is to make sure that there is no memory leak. We all know that getgroup() returns an malloc'ed string upon success - but if gettoken() is called by getgtroup(), then its the responsibility of getgroup() to free() it before returning. If such things are made sure then I believe there's nothing to worry. If you think you can make more optimisations over the stuff, then we can make a different branch for you to work on. After your tweaks, we can merge it to the main trunk. What do you say? PS : I have a major overhaul for the library in my mind - the API's will change then. But your code will still remain the same(coz that's the core) - so you can do your tweaking without affecting my work ! > > >> I'm waiting for your reply so that the next release can be made. Don't > >> worry, I'm not in a hurry. > >> > >> Regards, > >> > >> Jinesh. > >> > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Parser-devel mailing list > Par...@li... > https://lists.sourceforge.net/lists/listinfo/parser-devel > |
|
From: Noam P. <npo...@uw...> - 2006-10-14 02:19:48
|
"Jinesh K J" <jin...@gm...> writes: > I'm resending the mail - I believe your mail server did not accept the > original one as given below: Yes, I had a core dump file filling my quota. > On 10/12/06, Jinesh K J <jin...@gm...> wrote: >> Hi Noam, >> >> So in the end, the parser library is ready to go. You might wanna go >> to trunk/ and modify some stuff yourself. May be you wanna add your >> name into the MAINTAINERS file or something else too. >> >> One thing that you've not yet done is the documentation of the new >> functions. If you like to do it, may be you can start learning >> Doxygen. Let me know if you want me do it for you - if you are not >> comfortable with code documentation. I'll see if I can handle it, doesn't look too different from TeX. >> Since all the functionalities are in place you might also wanna make >> it (new functions) more modularised. Its up to you. I guess there is a bit of duplication with copy stuff up to char X... Do you think it would be worth making a gettoken_noalloc? It would save one memory allocation in getgroup. >> I'm waiting for your reply so that the next release can be made. Don't >> worry, I'm not in a hurry. >> >> Regards, >> >> Jinesh. >> |
|
From: Jinesh K J <jin...@gm...> - 2006-10-12 11:52:13
|
Hi Noam, So in the end, the parser library is ready to go. You might wanna go to trunk/ and modify some stuff yourself. May be you wanna add your name into the MAINTAINERS file or something else too. One thing that you've not yet done is the documentation of the new functions. If you like to do it, may be you can start learning Doxygen. Let me know if you want me do it for you - if you are not comfortable with code documentation. Since all the functionalities are in place you might also wanna make it (new functions) more modularised. Its up to you. I'm waiting for your reply so that the next release can be made. Don't worry, I'm not in a hurry. Regards, Jinesh. |
|
From: Jinesh K J <jin...@gm...> - 2006-10-11 05:19:12
|
On 10/10/06, Noam Postavsky <npo...@uw...> wrote: > Jinesh K J wrote: > > I think we can proceed either of two ways: > > > > 1. Modify gettoken() as I had mentioned previously to get the > > key/value pairs too. > > 2. Write another function getkeyval() that utilise gettoken() to do > > our job. The prototype I suggested remains the same. > Okay, I've done that. Almost over. I have made a few changes to the test cases. Please go through it. Jinesh. |
|
From: Jinesh K J <jin...@gm...> - 2006-10-10 04:37:36
|
> > I feel like this it too much functionality to be putting into gettoken. > It's true I don't really have much of the big picture, ie how these > functions are going to be used in the library, but I think that > splitting tokens should be a separate task from interpreting those tokens. This is how I thought is gonna work these functions for the library: 1. All the lines in the file will converted to an array of strings 2. cutcomment() operates on a line and extracts/removes the comment part 3. getgroup() checks and extracts the group name if the line represents a group declaration. 4. Lastly, gettoken() will extract each token from the line(if step 3 is failed) till the end of line is reached. All the information obtained is stored in the internal structure called 'entry'. The ability of gettoken() to identify the '=' connected data items together as key/value pair will help very much in reducing the complexity of the function transform() in transform.c. Introducing the additional test for checking the key/value pair is better not to be placed in transform(). So, it need to be done in some other function - if not gettoken(), then something else. I thought since gettoken() has done some much for us, may be we can get this one also be done by it. > > That's what it looks like to me, anyway. I think we can proceed either of two ways: 1. Modify gettoken() as I had mentioned previously to get the key/value pairs too. 2. Write another function getkeyval() that utilise gettoken() to do our job. The prototype I suggested remains the same. Any other option do you think there is? |
|
From: Noam P. <npo...@uw...> - 2006-10-10 03:56:50
|
Jinesh K J wrote: > So, one more functional change(I very well hope so) is all that we > need to merge these changes to the main tree. A behavioural change > with gettoken is needed. I don't really know how hard it would be for > you to make this change. It is as follows: > > ======begin======== > > char *gettoken(char *str, char **kv, char **end); > > str - input string > *end - the next character after our extracted token > *kv - the value part of our token(if its a key/value pair) - malloc'ed > > Returns -> the key/value part - malloc'ed > > ======end========== > I think by now our requirements are almost clear and complete. What is > your opinion? Any suggestions? > > > Jinesh. I feel like this it too much functionality to be putting into gettoken. It's true I don't really have much of the big picture, ie how these functions are going to be used in the library, but I think that splitting tokens should be a separate task from interpreting those tokens. That's what it looks like to me, anyway. Noam |
|
From: Jinesh K J <jin...@gm...> - 2006-10-07 12:47:31
|
On 10/6/06, Noam Postavsky <npo...@uw...> wrote: > OK, I think you mean should NOT be counted, that's what the test cases > seem to indicate. Yup! What I meant was 'NOT BE COUNTED'. Now our cutcomment() is working perfectly. > I've changed the function to pass the test cases, I think this is what > you meant, if not, more thorough explanation is needed. I think we have got it cleared. Good work! So, one more functional change(I very well hope so) is all that we need to merge these changes to the main tree. A behavioural change with gettoken is needed. I don't really know how hard it would be for you to make this change. It is as follows: ======begin======== char *gettoken(char *str, char **kv, char **end); str - input string *end - the next character after our extracted token *kv - the value part of our token(if its a key/value pair) - malloc'ed Returns -> the key/value part - malloc'ed ======end========== Explanation: Our str can contain tokens of two types: - A normal token which we can call a 'value' - A key/value pair which has a 'key' part and a 'value' part are are joined by an '='. Till now we've been worrying only about just a few words in a line. The words could also be grouped by using quotes. Those rules are to remain the same for our keys and values as well. The only change to be made to gettoken() is to make it recognise a key/value pair and return them. For example, below are the examples for - str, function return value, and *kv respectively. The function of *end remain the same. =1= [Hello World] [Hello] NULL Since Hello and World does not form a key/value pair, *kv should be NULL. =2= [Hello=World] [Hello] [World] This is a very simple and clear example of a key value pair. =3= [Hello = World] [Hello] [World] There can be spaces between a key, value and its '=' =4= ["Hello" = "World"] [Hello] [World] Keys and values can also be in tokens =5= ["Hello=World" = "Parser=Library"] [Hello=World] [Parser=Library] Rules for quotes remain the same - they are opaque objects =6= [Hello === World] [Hello] [World] [Hello = = = World] [Hello] [World] More than one '=' can be joined together =7= [Hello = World = Parser = Library] [Hello] [World Parser Library] Cascading of '=' can cause the values to be joined. Can you think of a better behaviour for this case? Should we have it this way: [Hello = World = Parser = Library] [Hello World Parser] [Library] =8= [Hello = ] [Hello] [] I think by now our requirements are almost clear and complete. What is your opinion? Any suggestions? Jinesh. |
|
From: Noam P. <npo...@uw...> - 2006-10-06 12:28:13
|
Jinesh K J wrote: > Both the functions are working fine. While gettoken is perfect there's > a flaw with cutcomment. I think I didn't take much time to explain > what 'str' can contain. 'str' contains a line inside the configuration > file. For example: > > server=192.168.0.1 port=2183 # This is our server > > A line can also contain quoted values like: > > server="192.168.0.1" port="2183" # This is our server > > In any case, the '#' inside the quote should be counted as the start OK, I think you mean should NOT be counted, that's what the test cases seem to indicate. > of the comment. I've added a few test cases for that too. All the > rules for quotes that we've followed till now applies here also. I > hope now things are clear. What do you say? > > Jinesh. I've changed the function to pass the test cases, I think this is what you meant, if not, more thorough explanation is needed. Noam |
|
From: Jinesh K J <jin...@gm...> - 2006-10-06 05:00:18
|
On 10/6/06, Noam Postavsky <npo...@uw...> wrote: > Jinesh K J wrote: > There are a few more work to be done as follows: > > > > =====1===== > > > > So, firstly let us make a modification over our gettoken - there need > > to have a slight change in its prototype: > > > > char * gettoken(const char *str, const char **end); > > > > ======2======= > > > > Secondly, we need a new function to dissect a comment from a line: > > > > char *cutcomment(char *str); > > > > =====end===== > > > > Try these and let me know. > > > > Jinesh. > > Done and Done. Both the functions are working fine. While gettoken is perfect there's a flaw with cutcomment. I think I didn't take much time to explain what 'str' can contain. 'str' contains a line inside the configuration file. For example: server=192.168.0.1 port=2183 # This is our server A line can also contain quoted values like: server="192.168.0.1" port="2183" # This is our server In any case, the '#' inside the quote should be counted as the start of the comment. I've added a few test cases for that too. All the rules for quotes that we've followed till now applies here also. I hope now things are clear. What do you say? > Noam > Jinesh. |
|
From: Jinesh K J <jin...@gm...> - 2006-10-05 07:30:43
|
> Hmm, now I can appreciate the usefulness of exceptions... I really miss that one here. > OK, fixed it, I was returning a non-malloc'd string. The error didn't > show up unless I set the environment variable MALLOC_CHECK_ so I didn't > notice. It seem to be working now. There are a few more work to be done as follows: =====1===== So, firstly let us make a modification over our gettoken - there need to have a slight change in its prototype: char * gettoken(const char *str, const char **end); When gettoken returns, *end need to have the address of the next character after the current token in str. For example, for an input of [Hello World], gettoken would be returning the malloc'ed [Hello], whereas *end should contain the address of the ' ' (space) character after 'Hello'. Even if it has reached the end of line, the address of the last '\0' should be returned. Note: *end need to be assigned only if we have found a valid token. ie, if gettoken() is returning NULL, *end need not be modified. ======2======= Secondly, we need a new function to dissect a comment from a line: char *cutcomment(char *str); The function searches in a string to find a comment (starting with '#'). If one is found, these are the steps to be performed: 1. Replace '#' with a '\0' in the original string (str) 2. Return a malloc'ed string that contains the contents after '#'(whatever it is) If no comment could be found, then the function need to return NULL. PS: The original string in this case get modified if a comment is found. =====end===== Try these and let me know. Jinesh. |
|
From: Noam P. <npo...@uw...> - 2006-10-04 21:54:40
|
Jinesh K J wrote: > Yes. Its true. But we are writing a library. We cannot print any error > or warning message by ourselves. The best way I think is to set the > some global status variable. Even a call-back method won't be that > harmful, I believe. Hmm, now I can appreciate the usefulness of exceptions... > >> > Also, note that I've updated the test cases. >> right, I've updated getgroup to pass them. > > I'm getting some fatal error. Can u go through them. Its given below: > OK, fixed it, I was returning a non-malloc'd string. The error didn't show up unless I set the environment variable MALLOC_CHECK_ so I didn't notice. Noam |
|
From: Jinesh K J <jin...@gm...> - 2006-10-04 09:32:29
|
On 10/4/06, Noam Postavsky <npo...@uw...> wrote: > Jinesh K J wrote: > >> 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? > > > Well, that is consistent with gettoken's behaviour, although if I was > writing a config file and left it invalid I would at least want to be > warned about it... Yes. Its true. But we are writing a library. We cannot print any error or warning message by ourselves. The best way I think is to set the some global status variable. Even a call-back method won't be that harmful, I believe. > > Also, note that I've updated the test cases. > right, I've updated getgroup to pass them. I'm getting some fatal error. Can u go through them. Its given below: [jinesh@jinesh np]$ ./a.out Testing gettoken() VERIFIED : < > VERIFIED : <> VERIFIED : <Hello> VERIFIED : < Hello > VERIFIED : < Hello World > VERIFIED : < "Hello" World> VERIFIED : < "Hello World" > VERIFIED : < " Hello World " > VERIFIED : < "Hello \" World " > VERIFIED : < 'Hello' World> VERIFIED : < 'Hello World' > VERIFIED : < ' Hello World ' > VERIFIED : < 'Hello \' World ' > VERIFIED : < " Hello ' World " > VERIFIED : < ' Hello " World ' > VERIFIED : < " Hello \\ World " > VERIFIED : < ' Hello \\ World ' > VERIFIED : < " Hello World "Pista > VERIFIED : < " Hello World ""Pista" > VERIFIED : < " Hello World " "Pista" > VERIFIED : < Pista" Hello World " > VERIFIED : < " " > VERIFIED : < "" > VERIFIED : < " \z " > VERIFIED : < \ > VERIFIED : < " \ " > VERIFIED : <hello\ world> VERIFIED : <hello\" world"> VERIFIED : <"hello world > Testing puttoken() VERIFIED : <Hello> VERIFIED : < Hello > VERIFIED : <Hello World> VERIFIED : < Hello World > VERIFIED : <Hello " World > VERIFIED : <Hello ' World > VERIFIED : < Hello \ World > VERIFIED : < > VERIFIED : <> VERIFIED : < z > VERIFIED : <\> VERIFIED : < \ > VERIFIED : <hello\> VERIFIED : <hello"> Testing getgroup() VERIFIED : < [] > *** glibc detected *** ./a.out: munmap_chunk(): invalid pointer: 0x0804933e *** ======= Backtrace: ========= /lib/libc.so.6(__libc_free+0x179)[0x4cb744f0] ./a.out[0x80490c9] ./a.out[0x8049226] /lib/libc.so.6(__libc_start_main+0xdc)[0x4cb22724] ./a.out[0x80485f1] ======= Memory map: ======== 08048000-0804a000 r-xp 00000000 03:02 1481 /home/jinesh/work/parser/branches/np/a.out 0804a000-0804b000 rw-p 00001000 03:02 1481 /home/jinesh/work/parser/branches/np/a.out 0804b000-0806c000 rw-p 0804b000 00:00 0 [heap] 4509c000-450a7000 r-xp 00000000 03:03 1240382 /lib/libgcc_s-4.1.1-20060525.so.1 450a7000-450a8000 rw-p 0000a000 03:03 1240382 /lib/libgcc_s-4.1.1-20060525.so.1 4caf0000-4cb09000 r-xp 00000000 03:03 1240355 /lib/ld-2.4.so 4cb09000-4cb0a000 r--p 00018000 03:03 1240355 /lib/ld-2.4.so 4cb0a000-4cb0b000 rw-p 00019000 03:03 1240355 /lib/ld-2.4.so 4cb0d000-4cc3a000 r-xp 00000000 03:03 1240359 /lib/libc-2.4.so 4cc3a000-4cc3c000 r--p 0012d000 03:03 1240359 /lib/libc-2.4.so 4cc3c000-4cc3d000 rw-p 0012f000 03:03 1240359 /lib/libc-2.4.so 4cc3d000-4cc40000 rw-p 4cc3d000 00:00 0 b7f09000-b7f0a000 rw-p b7f09000 00:00 0 b7f28000-b7f2a000 rw-p b7f28000 00:00 0 b7f2a000-b7f2b000 r-xp b7f2a000 00:00 0 [vdso] bffc1000-bffd7000 rw-p bffc1000 00:00 0 [stack] Aborted -------- Regards, Jinesh. |
|
From: Noam P. <npo...@uw...> - 2006-10-04 05:07:50
|
Jinesh K J wrote: >> 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? > Well, that is consistent with gettoken's behaviour, although if I was writing a config file and left it invalid I would at least want to be warned about it... > Also, note that I've updated the test cases. right, I've updated getgroup to pass them. Noam |
