Re: Fwd: RE: C99 (was: Re: Fix patch for SF bug 2833)

2018-03-22 Thread Bart Van Assche 

On 03/22/18 15:56, Keith Mendoza wrote:

Looking into using clang on Windows might be worth the effort to get
net-snmp code caught up to C99. Google Chrome now uses clang to
compile in Windows:
http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html


We do not only need a compiler on Windows but also the Windows API 
header files, e.g. for building the winExtDLL module. Microsoft owns the 
copyright on the Windows API header files. Does clang for Windows 
include Windows header files? I think MinGW comes with a clean-room 
rewrite of the Windows header files to avoid copyright issues. See also

http://mingw.org/history.

Bart.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Fwd: RE: C99 (was: Re: Fix patch for SF bug 2833)

2018-03-22 Thread Keith Mendoza 
Looking into using clang on Windows might be worth the effort to get
net-snmp code caught up to C99. Google Chrome now uses clang to
compile in Windows:
http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html

Thanks,
Keith

-Original Message-
Subject: RE: C99 (was: Re: Fix patch for SF bug 2833)
Date: Thu, 22 Mar 2018 18:27:47 + (UTC)
From: Steve Friedl <st...@unixwiz.net>
To: e...@thyrsus.com, 'Bill Fenner' <fen...@gmail.com>
CC: 'Net-SNMP Coders' <net-snmp-coders@lists.sourceforge.net>


net-snmp is expected to build on Windows, which gpsd does not; it's not
clear how much this impacts compiler choice.

-Original Message-
From: Eric S. Raymond [mailto:e...@thyrsus.com]
Sent: Thursday, March 22, 2018 10:32 AM
To: Bill Fenner <fen...@gmail.com>
Cc: Net-SNMP Coders <net-snmp-coders@lists.sourceforge.net>
Subject: C99 (was: Re: Fix patch for SF bug 2833)

Bill Fenner <fen...@gmail.com>:
> On Thu, Mar 22, 2018 at 9:16 AM, Eric S. Raymond <e...@thyrsus.com> wrote:
>
> > On the other hand, I question whether the extra overhead is a real
> > issue in 2018.
>
>
> I have the same question, but know that I have no useful opinion here
> - my "embedded system" ships with 4 gigs minimum, but the project has
> more use cases than mine.

Bart's objection about changing the public ABI is a showstopper and I
wihdraw the suggestion.

On the other hand...

>For example, the project did decide to back off from introducing c99
constructs.

*This* is an issue about which I know something important that does not seem
to have percolated into general knowledge yet.

I lead the GPSD project, a daemon for handling GPSes and other geolocation
sources.  It's deployed *everywhere* - smartphones, driverless cars, marine
navigation systems, main battle tanks, drones and UAVs, first-responder comm
gear, you name it.

If GPSD makes an assumption that breaks any Unix build chain or portability
anywhere, I get a complaint right quick.  I've fielded dozens of these.
Maybe the weirdest one was due to actual signed chars on a 360 mainframe.

There came a point at which I got tired of seeing legacy ifdefs from ancient
big iron in my codebase. Thought about my options, decided to move to
assuming C99 and SuSv2. I shipped a point release on this premise expecting
at least some minor pushback from some odd legacy environment.

I heard not a peep, and never have since.  And this was in 2009.

If that's not enough, since 2015 I have led the NTPsec project.  Based on
GPSD experience we made the same decision to assume a C99/SuSv2 base.
With no problems whatsoever except that on old versions of MacOS one of the
time primitives is broken.

That's how I learned that the standards people won.  Our traditional
twitchiness about tossing out any portability shim back to the year zero is
obsolete.

And bear in mind that GPSD/NTPsec probably exercises a wider swathe of the
host API than snmpd does, so the test has been more stringent. GPSD has to
get deep into odd corners of the tty driver and kernel PPS; NTPsec gets even
further into system clock handling.

I can say with confidence that assuming C99 is *very* safe in 2018.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute:
https://icei.org Please visit their site and donate: the civilization you
save might be your own.




--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

RE: C99 (was: Re: Fix patch for SF bug 2833)

2018-03-22 Thread Steve Friedl 
net-snmp is expected to build on Windows, which gpsd does not; it's not
clear how much this impacts compiler choice.

-Original Message-
From: Eric S. Raymond [mailto:e...@thyrsus.com] 
Sent: Thursday, March 22, 2018 10:32 AM
To: Bill Fenner <fen...@gmail.com>
Cc: Net-SNMP Coders <net-snmp-coders@lists.sourceforge.net>
Subject: C99 (was: Re: Fix patch for SF bug 2833)

Bill Fenner <fen...@gmail.com>:
> On Thu, Mar 22, 2018 at 9:16 AM, Eric S. Raymond <e...@thyrsus.com> wrote:
> 
> > On the other hand, I question whether the extra overhead is a real 
> > issue in 2018.
> 
> 
> I have the same question, but know that I have no useful opinion here 
> - my "embedded system" ships with 4 gigs minimum, but the project has 
> more use cases than mine.

Bart's objection about changing the public ABI is a showstopper and I
wihdraw the suggestion.

On the other hand...

>For example, the project did decide to back off from introducing c99
constructs.

*This* is an issue about which I know something important that does not seem
to have percolated into general knowledge yet.

I lead the GPSD project, a daemon for handling GPSes and other geolocation
sources.  It's deployed *everywhere* - smartphones, driverless cars, marine
navigation systems, main battle tanks, drones and UAVs, first-responder comm
gear, you name it.

If GPSD makes an assumption that breaks any Unix build chain or portability
anywhere, I get a complaint right quick.  I've fielded dozens of these.
Maybe the weirdest one was due to actual signed chars on a 360 mainframe.

There came a point at which I got tired of seeing legacy ifdefs from ancient
big iron in my codebase. Thought about my options, decided to move to
assuming C99 and SuSv2. I shipped a point release on this premise expecting
at least some minor pushback from some odd legacy environment.

I heard not a peep, and never have since.  And this was in 2009.

If that's not enough, since 2015 I have led the NTPsec project.  Based on
GPSD experience we made the same decision to assume a C99/SuSv2 base.
With no problems whatsoever except that on old versions of MacOS one of the
time primitives is broken.

That's how I learned that the standards people won.  Our traditional
twitchiness about tossing out any portability shim back to the year zero is
obsolete.

And bear in mind that GPSD/NTPsec probably exercises a wider swathe of the
host API than snmpd does, so the test has been more stringent. GPSD has to
get deep into odd corners of the tty driver and kernel PPS; NTPsec gets even
further into system clock handling.

I can say with confidence that assuming C99 is *very* safe in 2018.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute:
https://icei.org Please visit their site and donate: the civilization you
save might be your own.




--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

C99 (was: Re: Fix patch for SF bug 2833)

2018-03-22 Thread Eric S. Raymond 
Bill Fenner :
> On Thu, Mar 22, 2018 at 9:16 AM, Eric S. Raymond  wrote:
> 
> > On the other hand, I question whether the extra overhead is a real
> > issue in 2018.
> 
> 
> I have the same question, but know that I have no useful opinion here - my
> "embedded system" ships with 4 gigs minimum, but the project has more use
> cases than mine.

Bart's objection about changing the public ABI is a showstopper and I
wihdraw the suggestion.

On the other hand...

>For example, the project did decide to back off from introducing c99 
>constructs.

*This* is an issue about which I know something important that does not seem to
have percolated into general knowledge yet.

I lead the GPSD project, a daemon for handling GPSes and other geolocation
sources.  It's deployed *everywhere* - smartphones, driverless cars, marine
navigation systems, main battle tanks, drones and UAVs, first-responder comm
gear, you name it.

If GPSD makes an assumption that breaks any Unix build chain or
portability anywhere, I get a complaint right quick.  I've fielded
dozens of these. Maybe the weirdest one was due to actual signed chars
on a 360 mainframe.

There came a point at which I got tired of seeing legacy ifdefs from
ancient big iron in my codebase. Thought about my options, decided to
move to assuming C99 and SuSv2. I shipped a point release on this
premise expecting at least some minor pushback from some odd legacy
environment.

I heard not a peep, and never have since.  And this was in 2009.

If that's not enough, since 2015 I have led the NTPsec project.  Based on
GPSD experience we made the same decision to assume a C99/SuSv2 base.
With no problems whatsoever except that on old versions of MacOS one
of the time primitives is broken.

That's how I learned that the standards people won.  Our traditional
twitchiness about tossing out any portability shim back to the year zero
is obsolete.

And bear in mind that GPSD/NTPsec probably exercises a wider swathe of
the host API than snmpd does, so the test has been more stringent. GPSD has
to get deep into odd corners of the tty driver and kernel PPS; NTPsec
gets even further into system clock handling.

I can say with confidence that assuming C99 is *very* safe in 2018.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders