Ethan Quach wrote: > Tim, > > libbe.c - 781 - needs update. >
Actually that describes what is passed in to beVerifyBEName() just like the other functions in libbe.c since that info is hard to determine from the generic parameters (PyObject *self, PyObject *args). > Another thing that just occurred to me is that there are many > places in beadm.py that parse a beName as a commandline argument. > Is there any particular reason why you only added the beName verify > check to those two places? > Yes. All the other functions that accept beName as an argument use a beName that has already been created or verified. e.g. beadm destroy <beName> the beName has already been created so checking it after the fact isn't needed. "rename" and "create" are the only beNames that work with a freshly devised name from the user. > > Other than that it looks fine now. Thanks Tim > > > thanks, > -ethan > > > Tim Knitter wrote: >> >> Ethan Quach wrote: >>> >>> Tim Knitter wrote: >>>> >>>>> beadm.py - 193,649 - why does the '%' symbol have to be >>>>> passed in as a variable into the error message string? >>>> It wasn't possible to escape it in the message string so I had to >>>> pass it in. Python kept interpreting it to be a format character. >>> The message isn't correct anyway. A BE name cannot contain many other >>> characters that you don't have listed there. A BE name may consist of >>> alphanumeric characters, plus any of [-_.:] >>> >>> Without better error information from the library, I think this message >>> would be better left generic for now --getting rid of the second >>> sentence altogether, or summarizing the above. >>> >> >> OK. I got rid of the second sentence. >> >>>> >>>>> libbe.c - 799 - should this somehow be a boolean >>>>> function instead? >>>> There isn't a way to pass back a true boolean. Or put another way, >>>> there isn't a boolean format specifier when using Py_BuildValue(). >>>> There is the "b" specifier but when used it doesn't produce a Python >>>> "True" or "False". It returns an int so I left this as is. >>> Returning an int is fine. I just want us consider what we're >>> returning here since this interface is being consumed by others, >>> and we don't have an api defined. So right now you've got the >>> function returning 0 == Success, 6007 == Failure Why not just >>> return 0 and 1 ? >> >> Yeah I thought about that too and came to the conclusion that as long >> as the success case was zero the readability of using a a defined enum >> outweighed using 0 or 1. However 0 and 1 is clearer for consumers so I >> changed it to that. >> >>> libbe.c - 795 - Its returning a string instead of an int here. >>> Isn't that going to be a pain for consumers of this function? >>> Why not just return the failure int code here instead? >>> >> >> fixed. >> >> WR updated. >> >> Thanks >> Tim >> >>> >>> thanks, >>> -ethan >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
