15:45:43 <andyf> tsoome - a trailing comma on an enum is a C99 thing, isn't it?
15:45:57 <jbk> i believe so
15:46:19 <andyf> We probably shouldn't have that in blkdev.h then (although still definitely good to make dtrace handle it)
15:46:55 <jbk> is blkdev.h something we expect userland to use?
15:48:42 <jbk> (IIUC, kernel is C99.. it's just stuff userland might #include that still needs to be c89 compat)
15:48:45 <andyf> good point, no, it doesn't look like it
16:07:19 <tsoome> there are few places with trailing comma.
16:10:04 <gitomat> [illumos-gate] 15289 cmd: remove pragma ident -- Toomas Soome <tsoome⊙mc>
16:55:01 <tsoome> lib cleanup RTI builds started, soon this is history and we can hunt down unknown pragmas;)
17:22:24 <jperkin> removing the _CHAR_IS_SIGNED sections from sys/int_types.h and making int*8_t fixes a bunch of C++ software for me with no regressions that I can see, is there anything else I might be missing?
17:23:56 <jperkin> .."making int*8_t signed char explicitly"
17:24:07 <jperkin> alanc: be interested to know if solaris 11.4 has changed ^^ too
17:25:42 <alanc> we still have _CHAR_IS_SIGNED
17:26:31 <jperkin> ok thanks
17:27:46 <alanc> but we still support Studio cc, which has the -xchar={signed,unsigned} option
17:58:11 <andyf> and char is not signed on aarch64, IIRC.
17:59:13 <jperkin> yeh it wouldn't affect that
18:00:23 <sommerfeld> "typedef signed char int8_t" works regardless of the default signed-ness of char
18:03:08 <sommerfeld> the " Note that int8_t
18:03:08 <sommerfeld>  * is not defined in -Xs mode on ISAs for which the ABI specifies "char"
18:03:08 <sommerfeld>  * as an unsigned entity because there is no way to define an eight bit
18:03:08 <sommerfeld>  * signed integral.
18:03:08 <sommerfeld> " comment appears to be out of sync with the code beneath
18:09:09 <sommerfeld> (were there a bunch of #ifdef __STDC__ or the like in there that got stripped when it was safe to use the "signed" keyword unconditionally?)
18:59:23 <alanc> in the Solaris version, there's still an #if defined(__STDC__) around the typedef signed char		int8_t; in the #else clause of #if defined(_CHAR_IS_SIGNED)
19:00:32 <richlowe> you can't remove the _CHAR_IS_SIGNED bits, we need them.
19:01:24 <richlowe> making them signed explicitly sounds good
19:01:35 <richlowe> but in general _CHAR_IS_SIGNED/UNSIGNED is important
19:01:56 <alanc> looks like gdamore dropped that __STDC__ check in https://github.com/illumos/illumos-gate/commit/ba3594ba9b5dd4c846c472a8d657edcb7c8109ac but failed to update your comments to match
19:01:58 <jperkin> sure, I'm not proposing removing them generally, just the sections in sys/int_types.h
19:02:15 <jperkin> anyway I'll keep this in my tree for now and see if anything falls out with a bit more thorough testing
19:02:17 <rmustacc> jperkin: What was the build failure?
19:03:04 <richlowe> jperkin: being explicit definitely sounds good, I just don't want anything to change/stop respecting those in fact, if not syntactically. 
19:04:26 <jperkin> rmustacc: I don't have a link to the main failure which is textproc/nlohmann-json that is now a dependency for mkvtoolnix, but in my bulk build to test fixing that I found these two failures were also fixed:
19:04:30 <jperkin> https://us-central.manta.mnx.io/pkgsrc/public/reports/upstream-bulktest/20230121.1926/tesseract-4.1.1nb12/build.log
19:04:34 <jperkin> https://us-central.manta.mnx.io/pkgsrc/public/reports/upstream-bulktest/20230121.1926/gjs-1.68.4nb4/build.log
19:04:53 <jperkin> possibly others too (there was one false-positive that has skewed the results a little, I'm waiting for a rebuild to clean that up)
19:05:36 <rmustacc> OK. Makes me wonder what else is going wrong as the results should be mostly identical. Though I agree with Rich that it's good to just be explicit and that'd be good regardless.
19:06:13 <richlowe> ../../src/ccutil/serialis.h:98:8: error: 'bool tesseract::TFile::DeSerialize(int8_t*, std::size_t)' cannot be overloaded with 'bool tesseract::TFile::DeSerialize(char*, std::size_t)' sounds like a real bug
19:06:21 <richlowe> you _can't_ rely on char and int8 having the same signedness
19:06:38 <richlowe> why your change fixes that I'm less sure of
19:07:01 <richlowe> I guess because the change alan pointed out made C++ thing they were the other way around?
19:07:03 <richlowe> that would be bad.
19:07:34 <jperkin> the nlohmann-json failure is in bowels of C++ too, I've never seen it be an issue in C code
19:08:48 <richlowe> anyway, what your diff does seems reasonable to me, and I'm trying it out somewhere problematic
19:09:00 <richlowe> what happened to make you notice sounds more important, honestly, and like someone just screwed it all up
19:09:03 <richlowe> but rm is the expert.
19:09:17 <richlowe> (because I learned from alan that if you declare someone "the expert" enough, they get stuck with it)
19:09:43 <jperkin> hah, and like anyone is going to object to robert being labelled an expert on something
19:10:01 <rmustacc> I'll remember this one.
19:10:23 <rmustacc> Anyways, the question is probably does the C++ library define some of these on their own and not as typedefs.
19:10:52 <jperkin> tonight I'll be kicking off a test build which will include rebuilding gcc12 with these changes
19:11:11 <rmustacc> I guess I need to understand C++ specs which I have not ever really done to date.
19:11:13 <richlowe> my questions would be does the C++ stew change stuff, did garrett's change just absolutely break C++?
19:11:28 <richlowe> CTF might be able to answer the latter
19:11:47 <richlowe> (or dwarfdump, or whatever floats your boat)
19:29:30 <alanc> so gdamore forgot that defined(__STDC__) can also mean !defined(__cplusplus) ?
19:30:25 <alanc> though I could also see garrett arguing that breaking C++ is a good thing...
19:33:23 <richlowe> the first one was my thought.
19:33:29 <richlowe> the second did also cross my mind
20:17:03 <tsoome> are there plans to bump libdwarf btw?:)
20:22:04 <richlowe> to what end?
20:22:15 <richlowe> I haven't any, but I haven't had reason to, or heard reason to
20:22:38 <richlowe> if you want to -- and it works -- I certainly wouldn't stop you?
20:22:42 <richlowe> but I'm sorta busy myself.
20:23:03 <tsoome> i mean, if I did read it right, ours is from 2020, current is from 2022 and some bugs fixed, as one can imagine:)
20:24:44 <tsoome> and dwarf5 support added  meanwhile...
20:24:47 <richlowe> sure, but not bugs we have -- that we know of -- experienced.
20:25:06 <tsoome> I see.
20:25:08 <richlowe> and since we use our libdwarf for CTF, dwarf4 and dwarf5 are less important since the ctf tools don't understand (fully) anyway, and also we specify v2 
20:25:12 <richlowe> so nobody got to it yet
20:25:15 <richlowe> but someone _could_
20:26:02 <tsoome> as usual:)
20:51:41 <rmustacc> tsoome: I don't have a time frame for it. But it's pretty non-trivial, but could at some point.
20:53:19 <tsoome> since clang defaults to dwarf5, I was a bit curious and did check what we have/miss. Therefore the question:)
20:53:40 <richlowe> you need to do what we do with gcc, make it output dwarf2 
20:53:57 <tsoome> yes, I did that too:)
20:53:58 <richlowe> I'm not actually sure what the differences are for the small amount of dwarf we consume, but they do apparently matter.
20:54:49 <rmustacc> I meant to at some point try and do dwarf4 as a default and see what breaks with illumos.
20:56:21 <rmustacc> richlowe: I think the CTF tools are pretty good for dwarf4, fwiw.
20:56:36 <rmustacc> There was a large effort that last time I did that.
20:59:40 <richlowe> oh, well that's great at least
21:03:37 <rmustacc> The CTF tests at the time I last did this all worked well with gcc/clang with both -gdwarf2/4
21:05:19 <gitomat> [illumos-gate] 15340 cxgbe could make use of firmware loader API -- Andy Fiddaman <illumos⊙fn>
21:12:46 <richlowe> should we be looking into defaulting to 4 then?
21:18:39 <rmustacc> Probably.
21:18:49 <rmustacc> That'd be the next test is diffing everything.
21:19:20 <richlowe> ctfdiff certainly makes that a more pleasant experience
21:19:47 <rmustacc> Indeed.
21:19:58 <rmustacc> Especially with the ctfdump -c making it actually usable.
21:28:34 <gitomat> [illumos-gate] 15352 acl_get(3sec) return type is wrong -- Bill Sommerfeld <sommerfeld⊙ame>