Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
In-Reply-To: <01c701c54b41$f8d8c380$0055fd04@RUFF01>
References: <aea328ab050425230978094dc8@mail.gmail.com>
 <20050426101414.GD16976@redhat.com>
 <Pine.GSO.4.58.0504261210340.1090@cobra.cs.Virginia.EDU>
 <aea328ab0504260950614a3480@mail.gmail.com>
 <Pine.GSO.4.58.0504261408270.1090@cobra.cs.Virginia.EDU>
 <aea328ab05042611277a034f54@mail.gmail.com>
 <6.2.1.2.2.20050426140218.09844110@pop3.rowe-clan.net>
 <24e9a9288f100312c64a5fc3e80a8265@apache.org>
 <01c701c54b41$f8d8c380$0055fd04@RUFF01>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <2c3db737f340fc13271f6fc295637ecc@apache.org>
Content-Transfer-Encoding: 7bit
Cc: dev@apr.apache.org
From: Curt Arnold <carnold@apache.org>
Subject: Re: [PATCH] Don't define POSIX types {p,g,u}id_t
Date: Thu, 28 Apr 2005 22:39:30 -0500
To: Jeff White <jlwpc1@earthlink.net>


On Apr 27, 2005, at 10:49 AM, Jeff White wrote:

>
> From: "Curt Arnold"
>> I had to do some hacks around this to get APR to build
>
>>
>> BTW: Do I have any hope of getting the patches to support Borland and 
>>  Ming compilation reviewed and incorporated into the SVN?
>>
>
> Do those above compilers include
> the Safer CRT libraries usage yet?
>
> They are designed by Microsoft but these libraries may become a part 
> of the other OS systems C/C++ compilers too!
>
> Safe! Repel Attacks on Your
> Code with the Visual Studio
> 2005 Safe C and C++ Libraries
> http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/default.aspx
>
> Jeff
>

The patches address non-standard usage within Windows-specific sections 
of code that appear to have only been tested with the Microsoft 
compilers.         I was not making any functional changes to APR.

I was attempting to build APR using Borland 5.6.4 which shipped with 
CBuilderX (Copyright 2002) and gcc 3.4.2 for MinGW.  The Borland 
compiler is very likely at the end of its life as they were floating 
around a beta of a new generation compiler two years ago but they may 
have abandoned that effort.  Anyway it is highly unlikely that there 
will be a new version of bcc32 in the future.  I have no clue if gcc 
has any interest in providing those libraries.

Since APR wants to be able to be compiled and run on a large variety of 
compilers, some quite archaic and dormant, it should not require 
__STDC_SECURE_LIB__.  However, it would be lovely if APR's API methods 
were "secure" (in general contained a length parameter for any buffer) 
and the implementations called "secure" C RTL methods if they were 
available.  It would be an interesting experiment to see how pervasive 
use of "deprecated" C RTL methods are in APR and what would need to be 
changed to eliminate those warnings.