- 2021.01.04 14:55 "Re: [Tiff] Motions related to C99 use in libtiff", by Edward Lam
- 2021.01.04 18:43 "Re: [Tiff] Motions related to C99 use in libtiff", by Greg Troxel
- 2021.01.05 17:01 "Re: [Tiff] Motions related to C99 use in libtiff", by Jeff Breidenbach
- 2021.01.05 20:29 "Re: [Tiff] Motions related to C99 use in libtiff", by Kurt Schwehr
- 2021.01.05 20:46 "Re: [Tiff] Motions related to C99 use in libtiff", by Kemp Watson
-
2021.01.06 04:45 "Re: [Tiff] Motions related to C99 use in libtiff", by William Bader
- 2021.01.06 10:40 "Re: [Tiff] Motions related to C99 use in libtiff", by Even Rouault
- 2021.01.06 14:15 "Re: [Tiff] Motions related to C99 use in libtiff", by Bob Friesenhahn
-
2021.01.10 12:12 "Re: [Tiff] Motions related to C99 use in libtiff", by Even Rouault
- 2021.01.10 14:54 "Re: [Tiff] Motions related to C99 use in libtiff", by Bob Friesenhahn
- 2021.01.10 16:27 "Re: [Tiff] Motions related to C99 use in libtiff", by Roger Leigh
- 2021.01.15 15:58 "Re: [Tiff] Motions related to C99 use in libtiff", by Even Rouault
2021.01.04 15:35 "Re: [Tiff] Motions related to C99 use in libtiff", by Even Rouault
I'm probably missing something.
Motion 2 (requires Motion 1 to pass):
Did you mean this the other way around instead?
No, I really meant what I wrote. Motion 1 simplifies our autoconf/cmake scripts by requiring C99 headers, while still allowing libtiff headers to be used by software not requiring C99. That is you'd build libtiff with a "modern" compiler, and use it with an ancient one.
Motion 2 means we require C99 for libtiff internal use and external use, and avoid conflicts with the [u]intXXX types defined potentially in other headers.
Time to move on... Roger made the effort to do the work. We can't get stuck for eternity with pre-C99 constraints. People that can't cope with C99 can use past releases.
Even
Spatialys - Geospatial professional services
http://www.spatialys.com