On (02/09/09 16:45), Peter Memishian wrote: > > > * Throughout: there are a number of places where "?" is currently > > > returned, which basically indicates a failure (e.g., 489). > > > Shouldn't these cases now return some failure to the output engine, > > > which then elects to display this information however it sees fit? > > > > I don't know, do we want to display "?" or nothing at all? > > Returning an error would display nothing at all. Also dladm(1m) says > > > > (for show-linkprop) > > The current (or persistent) property value. If > > the value is not set, it is shown as --. If it > > is unknown, the value is shown as ?. Persistent > > values that are not set or have been reset will > > be shown as -- and will use the system DEFAULT > > value (if any). > > I'm not sure if ipmpstat makes such distinctions. > > It does. Specifically, it uses "unknown" to mean "the value could not be > retrieved"; there is a separate possible definition of "unknown" which > means "the value was retrieved, but actually had the value "unknown" which > it will report as "unknown"). > > I view the use of "?" as a way to represent an unknown value (such as > using "--" to represent an empty value in non-parsable mode) as an > output policy choice which should be handled by the output engine you've > built, not hardcoded into ipmpstat and others. > > I will file a bug to have "?" documented in ipmpstat(1M).
Ok. So "?" is actually always an error for ipmpstat? > The libdladm header collection was a bit of a compromise and in retrospect > a confusing one -- but at least everything beings with "libdl". Ok, I shall change the name of libprintutil.[ch] to ofmt.[ch] > > > * 315: Unclear why OFMT_NOMEM is needed; isn't that what a NULL > return > > > from ofmt_open() means? > > > > OFMT_NOMEM could also be encountered if we ran out of memory at > > line 174 of libprintutil.c, and we don't return a NULL handle > > for that case.. > > Why not? I could. I will. > > > > * 1295: Formatting here is now odd. Suggest adding a tabstop after > > > "0," on all the lines so that everything aligns again. > > > > yes, I noticed this too. and I can add the tabstop, though group_fields > will > > stick out longer than the other *fields[] rows. > > If you pad things out per my recommendation above, I think everything > should line up. You want me to tab out all the *fields[] to get the `}' to line up? (I don't care myself, it's really an aesthetic preference). --Sowmini
