Re: [Libjpeg-turbo-devel] Removing support for pre-'89 compilers

[DRC <dco...@us...>]

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?
>>