On 30.06.2019 17:29, Joerg Sonnenberger wrote: > On Fri, Jun 28, 2019 at 08:58:44PM -0400, Greg Troxel wrote: >> Joerg Sonnenberger <joerg%bec.de@localhost> writes: >> >>> On Fri, Jun 28, 2019 at 12:11:17PM -0400, Greg Troxel wrote: >>>> Why is gnu99 added when a package declares c99, when we have gnu >>>> flavors of the C++ standards explicitly? >>> >>> Because unlike with C++, a lot of things break with strict ISO C. >> >> Do you think pkgsrc should continue to use "c99" to mean "gnu99", or >> should we have c99 mean what it says, and have packages that need gnu99 >> declare that? I guess that's two questions, in an ideal world, and then >> when considering the pain of getting form here to there. >> >> I realize this is complicated by c99/gnu99 not ensuring that the >> compiler is capable, and by many upstream configures adding --std=foo >> themselves. > > Given that on most platform -std=c99 disables a lot of the POSIX things, > there is generally no point in doing that. Waste of time trying to > "enforce" strict C99. > > Joerg > A potential purpose of enforcing ANSI C would be to check some code for being conforming to strict standards. It does not make any positive value in pkgsrc and it can make harm (even if something will build, we can pick broken version of alloca(3) instead of __builtin_alloca()). For C++ software strict C++ is usually fine except for Windows applications that pick alloca as Visual Studio does not support VLA.
Attachment:
signature.asc
Description: OpenPGP digital signature