tsoome - a trailing comma on an enum is a C99 thing, isn't it?

i believe so

We probably shouldn't have that in blkdev.h then (although still definitely good to make dtrace handle it)

is blkdev.h something we expect userland to use?

(IIUC, kernel is C99.. it's just stuff userland might #include that still needs to be c89 compat)

good point, no, it doesn't look like it

there are few places with trailing comma.

[illumos-gate] 15289 cmd: remove pragma ident -- Toomas Soome <tsoome⊙mc>

lib cleanup RTI builds started, soon this is history and we can hunt down unknown pragmas;)

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?

.."making int*8_t signed char explicitly"

alanc: be interested to know if solaris 11.4 has changed ^^ too

we still have _CHAR_IS_SIGNED

ok thanks

but we still support Studio cc, which has the -xchar={signed,unsigned} option

and char is not signed on aarch64, IIRC.

yeh it wouldn't affect that

"typedef signed char int8_t" works regardless of the default signed-ness of char

the " Note that int8_t

* is not defined in -Xs mode on ISAs for which the ABI specifies "char"

* as an unsigned entity because there is no way to define an eight bit

* signed integral.

" comment appears to be out of sync with the code beneath

(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?)

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)

you can't remove the _CHAR_IS_SIGNED bits, we need them.

making them signed explicitly sounds good

but in general _CHAR_IS_SIGNED/UNSIGNED is important

looks like gdamore dropped that __STDC__ check in illumos/illumos-gate ba3594b but failed to update your comments to match

sure, I'm not proposing removing them generally, just the sections in sys/int_types.h

anyway I'll keep this in my tree for now and see if anything falls out with a bit more thorough testing

jperkin: What was the build failure?

jperkin: being explicit definitely sounds good, I just don't want anything to change/stop respecting those in fact, if not syntactically.

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:

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)

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.

../../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

you _can't_ rely on char and int8 having the same signedness

why your change fixes that I'm less sure of

I guess because the change alan pointed out made C++ thing they were the other way around?

that would be bad.

the nlohmann-json failure is in bowels of C++ too, I've never seen it be an issue in C code

anyway, what your diff does seems reasonable to me, and I'm trying it out somewhere problematic

what happened to make you notice sounds more important, honestly, and like someone just screwed it all up

but rm is the expert.

(because I learned from alan that if you declare someone "the expert" enough, they get stuck with it)

hah, and like anyone is going to object to robert being labelled an expert on something

I'll remember this one.

Anyways, the question is probably does the C++ library define some of these on their own and not as typedefs.

tonight I'll be kicking off a test build which will include rebuilding gcc12 with these changes

I guess I need to understand C++ specs which I have not ever really done to date.

my questions would be does the C++ stew change stuff, did garrett's change just absolutely break C++?

CTF might be able to answer the latter

(or dwarfdump, or whatever floats your boat)

so gdamore forgot that defined(__STDC__) can also mean !defined(__cplusplus) ?

though I could also see garrett arguing that breaking C++ is a good thing...

the first one was my thought.

the second did also cross my mind

are there plans to bump libdwarf btw?:)

to what end?

I haven't any, but I haven't had reason to, or heard reason to

if you want to -- and it works -- I certainly wouldn't stop you?

but I'm sorta busy myself.

i mean, if I did read it right, ours is from 2020, current is from 2022 and some bugs fixed, as one can imagine:)

and dwarf5 support added meanwhile...

sure, but not bugs we have -- that we know of -- experienced.

I see.

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

so nobody got to it yet

but someone _could_

as usual:)

tsoome: I don't have a time frame for it. But it's pretty non-trivial, but could at some point.

since clang defaults to dwarf5, I was a bit curious and did check what we have/miss. Therefore the question:)

you need to do what we do with gcc, make it output dwarf2

yes, I did that too:)

I'm not actually sure what the differences are for the small amount of dwarf we consume, but they do apparently matter.

I meant to at some point try and do dwarf4 as a default and see what breaks with illumos.

richlowe: I think the CTF tools are pretty good for dwarf4, fwiw.

There was a large effort that last time I did that.

oh, well that's great at least

The CTF tests at the time I last did this all worked well with gcc/clang with both -gdwarf2/4

[illumos-gate] 15340 cxgbe could make use of firmware loader API -- Andy Fiddaman <illumos⊙fn>

should we be looking into defaulting to 4 then?

Probably.

That'd be the next test is diffing everything.

ctfdiff certainly makes that a more pleasant experience

Indeed.

Especially with the ctfdump -c making it actually usable.

[illumos-gate] 15352 acl_get(3sec) return type is wrong -- Bill Sommerfeld <sommerfeld⊙ame>