[illumos-gate] 16708 SMBIOS 3.8 Support -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 16709 smbios tests should also be built 64-bit -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 16705 Want lifetime extensions for TCP_MD5SIG SAs -- Andy Fiddaman <illumos⊙fn>

um... is there any known reason why mdb_printf("%*s", 8, str); should ignore width 8?

I don't see it listed as an accepted item in the book.

Not a great link, but §10.4.22 in illumos.org/books/mdb/api-5.html#api-5

git grep gound few, like: modules/genunix/leaky.c: mdb_printf("%*s => %lld\n", 30, str, stat);

Hmm, I guess it is in iob_doprnt.

also in genunix etc...

yes, and I did check iob_doprnt. it should work....

Well, then I'm afraid you'll have to debug.

I'm getting output : BPB Volume Label: "NONAME FAT32 and some printable garbage till closing "

the printf itself is: mdb_printf("\"%*s\"", 11, bpb_VolLab32(bpb));

I guess its a bit buggy:)

could it be the string itself? e.g. fixed-length and non-NUL terminated?

the string is not NUL terminated, no

that it's maybe treating as if it was

um.

I can never remember offhand but I thought one of those was just 'pad up to X size if needed'

while the other would truncate

(for printf(3C), not sure about mdb)

yea, i started to wonder if I was mixing things up

'%*s' vs '%.*s'

The * is the minimum field width.

it's one of those things i have to re-read and re-parse the man page

because i never use it frequently enough to remember it before I need it again :)

If you pass %s I don't think there's a get out of termination free card.

The . is the maximum, but again, that's not a promise it won't call strlen.

BPB Volume Label: ".*s" :)

OK, reading POSIX it says something not as clear as you'd like, but "If the precision is not specified or is greater than the size of the array, the application shall ensure that the array contains a null byte.".

Which to me suggests that it means you can get away with what you're doing with no NUL.

# printf "%.*s\n" 5 "qwertyuiop"

qwert

but apparently mdb_printf does not grok %.*s

then probably just need to copy it to a local buffer so you can terminate it...

though in the context of mdb, given that fixed length strings like that aren't _that_ uncommon, it might be worth figuring out something appropriate to help deal with them better (though not sure offhand what that would look like specifically)

'.' can be added to iob_doprnt() - it should not be that hard:)

but yes, quick answer is to use local buffer.

the format parser is huge switch and the annoying part is to walk over all the cases where precision might appear, as its not just about %s

Whether it's a huge switch or not, the precision does impact everything. ;)

yep:)

yea, and while there, it would be nice to have %zu and %zd and friends:)

That's a bit easier.

ok, I better see what is still broken in mkfs_pcfs ...

and it's probably a bit less messy than _doprnt() since it doesn't have to deal with wide characters or %n$

I feel like we have several _doprnt that would be better being as similar as possible

(I doubt they can really be the same)

(and i don't think mdb is utilizing stupid pet^Wva_arg() tricks)

if I remember, we sort of had one of those somewhere

well there was the optimized assembler version in vi

that i think is finally gone

(libc's _doprint() basically relies on being able to iterate to an arbitrary argument number via repeated calls to va_arg(ap, void *))

which I suppose is technically ok, but certainly feels a bit sketchy

I thought it was going to hose me, and it didn't.

if that makes you feel better.

(arm va_list is not a pointer)

i originally was interested in seeing what it'd take to implement something similar in spirit (but definitely _not_ implementation) of ast's ability to extend a format string (IIRC, you could pass something like %! with a corresponding struct and then conversion specifications after it in that call could make use of the extension)

but it acts like a barrier, which makes it hard to work with %n$ style formatting