Re: CVS commit: pkgsrc/www/c-icap
Greg Troxel <[email protected]> Sun, 14 Jun 2026 14:37:52 -0400
| Newsgroups | gmane.os.netbsd.devel.packages |
|---|---|
| Message-ID | <[email protected]> |
"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.