Re: CVS commit: pkgsrc/www/c-icap
nia <[email protected]> Mon, 15 Jun 2026 16:00:25 +0000
| Newsgroups | gmane.os.netbsd.devel.packages |
|---|---|
| Message-ID | <[email protected]> |
On Sun, Jun 14, 2026 at 02:37:52PM -0400, Greg Troxel wrote: > "Nia Alarie" <[email protected]> writes: > > > Log Message: > > c-icap: Fails with C23 default language. > > > -USE_LANGUAGES= c > > +FORCE_C_STD= gnu89 > > (I didn't comment on the first one, but this now seems like a > larger-scale change.) > > It seems the root cause is compilers defaulting to a newer std. That > seems obviously buggy but not something we can address. > > Given how compilers are, a package failing to probe for and set --std is > an upstream bug. > > I think any FORCE_C_STD needs a comment. It's only set because of a > bug. "fails when compiler defaults to C23" seems like it's it, but that > should travel with the variable definition. It will not be obvious to > someone in a few years, and maybe not even next week. > > It's not obvious why you chose gnu89, or why that's right. Upstream > should document what it needs, but it probably doesn't. I would think > that C99 would be a better choice, if it works, as I view that as the > standard C approach these days, vs too-old-you-really-shouldn't of C89, > and the newfangled-is-this-really-necessary C11 and especially C17 and > later. I realize gnu extensions might be needed, but I think it's > better if they are turned on if they are needed. >a I honestly really do not care what you think.