The example command line application (cmdr) expects alpha strings for the parameters and runs it through a macro processor (m4) with the definitions in enums.m4.
John g0orx/n6lyt -- John Melton SunIT CTO x21708 (+44 1252 421708) Jim Lux wrote: > Most of the action routines in update.c do not check that the right number > of parameters were presented in the command. What does the parser put into > the array of parameter strings if a parameter is missing? A null string? I > assume that the library atof() handles a null string gracefully (return a > zero, for instance?), but is a zero a legal value for the action routine in > all cases? > > Example: say I issued the command setMode with no parameters. setMode > would get called, and since n would be zero, it would fall through to the > else clause and both tx.mode and rx[RL].mode would get set to zero, which I > believe would map to LSB (although, really, you're depending on the > enumeration in defs.h) > > From a down the road interface specification standpoint, explicit values > should be assigned in the enumeration for things like modes, and zero > probably shouldn't be a legal value. One can't depend on the source of the > commands (which might be a process on a different computer, or written in a > different language, etc.) to have used the same defs.h AND the compiler to > have assigned enumerated values in the same order. (I can't recall if the > spec for the language specifies a default enumeration value sequence. It > would be a convenience, and is sort of antithetical to the idea of "strong > typing" to actually depend on the numerical value of a enumerated type, > anyway.) > > I suppose that if we have some sort of more rigorous command parser (XML or > otherwise) it would translate between the "interface specification > representation of an enumerated value", e.g. a text string like USB, and > the internal representation, and since the parser would be compiled as part > of the dttsp code, then they would be using the same defs.h, and it would > all work. > > In any case, relying on variable and type declarations in .h files to > define the external interface specification is probably dicey. > > Jim > > > > _______________________________________________ > FlexRadio mailing list > FlexRadio@flex-radio.biz > http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz > Archive Link: http://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/ > FlexRadio Homepage: http://www.flex-radio.com
