Re: [Libjpeg-turbo-devel] Removing support for pre-'89 compilers
SIMD-accelerated libjpeg-compatible JPEG codec library
Brought to you by:
dcommander
From: DRC <dco...@us...> - 2014-08-03 13:55:50
|
A more thorough list of legacy stuff that has been removed: r1307: removed support for linkers with a 15-character global symbol name limit, i.e. the NEED_SHORT_EXTERNAL_NAMES configure option. There was scant information as to which linkers ever required this-- probably VMS and/or a.out BSD. We have never supported such systems, nor do other open source libraries of this nature. r1308: removed support for HAVE_PROTOTYPES configure option, as well as the related JPP() and JMETHOD() macros. libjpeg-turbo has never supported non-ANSI compilers. Doing so requires ansi2knr, which even IJG doesn't support anymore. r1312: removed MS-DOS-specific code and information. We've never supported MS-DOS, nor would it be possible to do with with our SIMD extensions. r1313: removed SIZEOF() macro. This was also a throwback to non-ANSI compilers, and it was inconsistently implemented in our code anyhow (basically, all of the legacy libjpeg code used SIZEOF(), but my new code generally used sizeof(), so it has never been possible to compile the software using compilers that had a broken sizeof() implementation.) r1317: removed reference to install.txt, which we don't have (install.txt also had information on compiling with non-ANSI compilers.) r1322: removed VMS-specific code On 8/3/14 8:36 AM, DRC wrote: > Yes, this has already been done in subversion trunk (which will become > either libjpeg-turbo 1.4 or 2.0, pending completion of AVX support and a > couple of other things.) I've also removed support for MS-DOS and VMS > and other legacy platforms that libjpeg-turbo would have never worked on > anyway. > > > On 8/3/14 6:12 AM, Kornel wrote: >> I've noticed libjpeg code uses JPP and JMETHOD macros for C compilers >> that don't support function prototypes. >> >> I doubt anybody uses compilers that old, and a compiler that is so old >> and primitive that it doesn't support even basic ANSI C, probably is a >> terrible choice for a for performance-critical code anyway. >> >> Do you think it would be OK to remove usage of JPP and JMETHOD macros >> and change that code to regular ANSI C function prototypes? >> |