03:23:21 <twobitsahead> What would be the best way of capturing stderr from GCC? Not sure if I am understanding something incorrectly; the dev I am interacting with suggests capturing stderr from GCC by using dtrace. Has a better way been formulated since the 90s?
10:00:22 <tsoome> ok, I must be blind or something, but why this buffer needs to be 32 bytes?! https://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/zfs/zfs_vfsops.c?r=4763305e#789
10:01:38 <tsoome> I can count 17:)
10:03:44 <Woodstock> uh, that looks nasty
10:04:14 <Woodstock> why does it not use asprintf or expect the actual buffer size as an argument?
10:05:10 <tsoome> asprintf wont work as they are skipping prefix bytes from that buffer ("obj-")
10:05:49 <tsoome> that is, the actual buffer is expected to be + 4 bytes larger
10:06:48 <Woodstock> then the callers should just pass the actual size, and use snprintf in that function :)
10:07:12 <Woodstock> sprintf is so 1985
10:07:20 <tsoome> At first  I took that 32 literally and replaced char *buf by char buf[32], and gained compiler check on buffer size, then I started to look where this size is coming from:)
10:07:47 <andyf> 17? I count 20, or are you taking into account limits on domainid and rid?
10:08:16 <andyf> well, 21 with the null byte
10:09:05 <andyf> Oh, hex.. I'll get some coffee.
10:09:10 <tsoome> eee? we are putting those bytes into that buf: sprintf(buf, "%llx", (longlong_t)fuid); nothing more
10:09:12 <tsoome> :D
10:09:17 <tsoome> yes, its hex
10:09:32 <tsoome> so its 16+1
10:10:24 <tsoome> and yes, going to replace sprintf by snprintf there for safety
10:11:47 <andyf> That function takes a 'len' parameter in openzfs, as well as using snprintf (commit c9e319faae)
10:17:57 <jclulow> tsoome: we should use ilstr for that, tbh
10:19:25 <jclulow> https://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/zfs/zfs_vfsops.c?r=4763305e#1576-1587 -- this is not great, for example
10:21:26 <tsoome> yes, that one was blowing on my face with char buf[32] like this:  ../../common/fs/zfs/zfs_vfsops.c:849:15: error: 'id_to_fuidstr' accessing 32 bytes in a region of size 24 [-Werror=stringop-overflow=]
10:21:52 <jclulow> oof
10:22:28 <jclulow> You can still use a stack buffer with ilstr_init_prealloc() at least, it just won't be as egregiously unsafe haha
10:22:30 <tsoome> and then I started to check 1) why 32, and 2) what happens with the content there
10:24:35 <tsoome> I guess ilstr may be good answer there, as zfs_vfsops.c is os specific anyhow [in OpenZFS] and therefore we will not suffer the portability.
10:28:19 <tsoome> ofc that 32 must be leftover from some older version;)
10:44:14 <tsoome> ah, ok, quota bits are moved to zfs_quota.c ok....
20:04:46 <gitomat> [illumos-gate] 16997 zfs.h correct comments in zfs_ioc -- Toomas Soome <tsoome⊙mc>
20:28:31 <richlowe> I might have misread above, but I don't see reasons to avoid ilstr for porting purposes
20:28:42 <richlowe> we have an interface that makes our strings safer, that's good, and we should use it
22:18:54 <jclulow> richlowe: Yes, agreed.
22:19:24 <jclulow> If folks want to take patches we've written against ZFS and apply them to other projects, they're welcome to them under the same licence etc
22:19:36 <jclulow> (and thus also welcome to make a copy of ilstr etc)