Bug 32760

Comment 1 Robert Watson 2001-12-12 19:27:21 UTC

While I'm not opposed to such a change in general, I think doing this
before 4.5-RELEASE would be very bad idea, as it would dramatically
increase the "make ports work" work-load before the release.  Doing this
after 4.5-RELEASE sounds like a reasonable idea. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org      NAI Labs, Safeport Network Services

On Wed, 12 Dec 2001, Alan E wrote:

> 
> >Number:         32760
> >Category:       misc
> >Synopsis:       Please MFC /usr/include/malloc.h to -STABLE.
> >Confidential:   no
> >Severity:       serious
> >Priority:       medium
> >Responsible:    freebsd-bugs
> >State:          open
> >Quarter:        
> >Keywords:       
> >Date-Required:
> >Class:          change-request
> >Submitter-Id:   current-users
> >Arrival-Date:   Wed Dec 12 11:20:01 PST 2001
> >Closed-Date:
> >Last-Modified:
> >Originator:     Alan E
> >Release:        FreeBSD 4.4-STABLE i386
> >Organization:
> Geeksrus.NET
> >Environment:
> System: FreeBSD wwweasel.geeksrus.net 4.4-STABLE FreeBSD 4.4-STABLE #0: Sun Dec 2 19:14:12 EST 2001 root@wwweasel.geeksrus.net:/usr/obj/usr/src/sys/WWWEASEL i386
> >Description:
> 
> /usr/include/malloc.h on CURRENT generates an error using #error.
> /usr/include/malloc.h on STABLE only generates a #warning.
> 
> This means that things (like KDE) will build in STABLE and then people try
> to build the released ports on CURRENT and get bit by this.
> 
> If malloc.h were MFC'd, then we'd catch all of this stuff up front, rather
> than after releasing new ports to the world.
> 
> >How-To-Repeat:
> 
> Compile something that does "#include <malloc.h>".
> 
> >Fix:
> 
> MFC malloc.h.
> 
> >Release-Note:
> >Audit-Trail:
> >Unformatted:
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-bugs" in the body of the message
>

On Wed, 12 Dec 2001 14:10:48 EST, Alan E wrote:

> /usr/include/malloc.h on CURRENT generates an error using #error.
> /usr/include/malloc.h on STABLE only generates a #warning.
> 
> This means that things (like KDE) will build in STABLE and then people try
> to build the released ports on CURRENT and get bit by this.
> 
> If malloc.h were MFC'd, then we'd catch all of this stuff up front, rather
> than after releasing new ports to the world.

The problem with merging the change onto the stable branch is that it's
a serious change of interface in the middle of the lifetime of a major
release (4.x).

Sure, POSIX-conformant software should look for the prototype in the
right place, but we try quite hard to keep point release upgrades as
painless as possible.

Ciao,
Sheldon.

Comment 3 Jens Schweikhardt 2002-08-21 16:11:47 UTC

State Changed
From-To: open->suspended

As Sheldon points out, this won't be MFCd on the 4-STABLE branch 
due to the reasons stated. Once 4-STABLE is no longer maintained, 
this PR can be closed.

Comment 4 Kris Kennaway 2003-07-14 11:19:42 UTC

State Changed
From-To: suspended->closed

malloc.h should not be deprecated in the RELENG_4 branch.  We 
already have the ports under control, so this isn't an issue.