From sacadmin Thu Dec 18 13:48:08 2008 Received: from sunraf.sfbay.sun.com (sunraf.SFBay.Sun.COM [129.146.177.11]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBILm8PB013694; Thu, 18 Dec 2008 13:48:08 -0800 (PST) Received: from sunraf.sfbay.sun.com (localhost [127.0.0.1]) by sunraf.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mBILlwPm133120; Thu, 18 Dec 2008 13:47:58 -0800 (PST) Received: (from raf@localhost) by sunraf.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id mBILlwed133116; Thu, 18 Dec 2008 13:47:58 -0800 (PST) Date: Thu, 18 Dec 2008 13:47:58 -0800 (PST) From: "Roger A. Faulkner" Message-Id: <200812182147.mBILlwed133116@sunraf.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: asprintf, vasprintf [PSARC/2008/778 Self Review] Status: RO Content-Length: 552 Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: asprintf, vasprintf 1.2. Name of Document Author/Supplier: Author: Roger Faulkner 1.3 Date of This Document: 18 December, 2008 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From Roger.Faulkner@sun.com Thu Dec 18 15:05:39 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBIN5dGW016115 for ; Thu, 18 Dec 2008 15:05:39 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.63]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id mBIN5dP8370787; Thu, 18 Dec 2008 15:05:39 -0800 (PST) Message-Id: <200812182305.mBIN5dP8370787@jurassic-x4600.sfbay.sun.com> Date: Thu, 18 Dec 2008 15:05:39 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: PSARC/2008/778 - asprintf, vasprintf To: psarc-ext@sac.sfbay.sun.com Cc: tim.marsland@sun.com, john.levon@sun.com, peter.memishian@sun.com, daniel.price@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: i5Yxgu7x7L0oha6oIdsxHQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_98 SunOS 5.11 i86pc i386 Status: RO Content-Length: 7606 I am sponsoring this automatic case for myself. 1. Introduction This case adds two new functions to the C library, asprintf() and vasprintf() as follows: int asprintf(char **ret, const char *format, ...); int vasprintf(char **ret, const char *format, va_list ap); The committment level of these interfaces is Committed. The release binding is "patch" (so it can be back-ported to Solaris 10 if required). 2. Discussion Linux and the various BSD operating systems provide the *asprintf() family of functions. These behave as sprintf(), except that they allocate a string large enough to hold the result, and return a pointer to that string. The caller is later expected to free() this buffer. Both functions return the same values as the corresponding sprintf() variant with one addition: The asprintf() and vasprintf() functions may fail if: ENOMEM Insufficient storage space is available. The contents of 'ret' on failure varies between current implementations. This case proposes to set 'ret' to NULL on failure (as the BSD implementation does, unlike the Linux implementation which leaves it as undefined). Note that there is some extant usage of asnprintf() and vasnprintf() functions, mostly via a library called gnulib, which is typically used to provide missing functionality in cross-platform software. As no OS actually implements these variants, and they have a somewhat strange interface, this case does not propose an implementation of them for Solaris. 3. Interface table Both functions are Committed. Both are derived from OpenBSD source. 4. References 4508459 Solaris should have asprintf() and vasprintf() functions 5. Manual page differences (See the materials directory for the full old and new man pages.) --- printf.3c.old Wed Dec 17 12:02:14 2008 +++ printf.3c Wed Dec 17 12:46:03 2008 @@ -6,7 +6,7 @@ NAME - printf, fprintf, sprintf, snprintf - print formatted output + printf, fprintf, sprintf, snprintf, asprintf - print formatted output SYNOPSIS #include @@ -27,6 +27,10 @@ const char *restrict format, /* args*/ ...); + int asprintf(char **ret, const char *restrict format, + /* args*/ ...); + + DESCRIPTION The printf() function places output on the standard output stream stdout. @@ -51,6 +55,15 @@ written into the array. + The asprintf() function is the same as the sprintf() function + except that it returns, in the ret argument, a pointer to a + buffer sufficiently large to hold the output string. This + pointer should be passed to free(3C) to release the allocated + storage when it is no longer needed. If sufficient space + cannot be allocated, the asprintf() function returns -1 and + sets ret to be a NULL pointer. + + Each of these functions converts, formats, and prints its arguments under control of the format. The format is a char- acter string, beginning and ending in its initial shift @@ -611,9 +624,10 @@ call to exit(3C) or abort(3C). RETURN VALUES - The printf(), fprintf(), and sprintf() functions return the + The printf(), fprintf(), sprintf(), and asprintf() functions + return the number of bytes transmitted (excluding the terminating null - byte in the case of sprintf()). + byte in the case of sprintf() and asprintf()). The snprintf() function returns the number of bytes that @@ -622,7 +636,7 @@ n is 0 on a call to snprintf(), s can be a null pointer and the number of bytes that would have been written if n had been sufficiently large (excluding the terminating null - byte) are returned. + byte) is returned. Each function returns a negative value if an output error @@ -653,7 +667,7 @@ - The printf() and fprintf() functions may fail if: + The printf(), fprintf(), and asprintf() functions may fail if: ENOMEM Insufficient storage space is available. @@ -798,14 +812,19 @@ - The sprintf() and snprintf() functions are Async-Signal- - Safe. The printf() and fprintf() functions can be used - safely in multithreaded applications, as long as - setlocale(3C) is not being called to change the locale. + The printf(), fprintf(), sprintf(), and snprintf() functions + are Standard. The asprintf() function is modeled on the one + that appears in the FreeBSD, NetBSD, and GNU C libraries. + All of these functions can be used safely in multithreaded + applications, as long as setlocale(3C) is not being called + to change the locale. + + The sprintf() and snprintf() functions are Async-Signal-Safe. + SEE ALSO exit(2), lseek(2), write(2), abort(3C), ecvt(3C), exit(3C), - fclose(3C), fflush(3C), fputwc(3C), putc(3C), scanf(3C), + fclose(3C), fflush(3C), fputwc(3C), free(3C), putc(3C), scanf(3C), setlocale(3C), stdio(3C), vprintf(3C), wcstombs(3C), wctomb(3C), attributes(5), environ(5), standards(5) --- vprintf.3c.old Wed Dec 17 12:02:25 2008 +++ vprintf.3c Wed Dec 17 20:04:02 2008 @@ -6,8 +6,8 @@ NAME - vprintf, vfprintf, vsprintf, vsnprintf - print formatted - output of a variable argument list + vprintf, vfprintf, vsprintf, vsnprintf, vasprintf - print + formatted output of a variable argument list SYNOPSIS #include @@ -25,10 +25,14 @@ int vsnprintf(char *s, size_t n, const char *format, va_list ap); + int vasprintf(char **ret, const char *format, va_list ap); + + DESCRIPTION - The vprintf(), vfprintf(), vsprintf() and vsnprintf() func- - tions are the same as printf(), fprintf(), sprintf(), and - snprintf(), respectively, except that instead of being + The vprintf(), vfprintf(), vsprintf(), vsnprintf(), and + vasprintf() functions are the same as printf(), fprintf(), + sprintf(), snprintf(), and asprintf(), respectively, except + that instead of being called with a variable number of arguments, they are called with an argument list as defined in the header. See printf(3C). @@ -104,7 +108,7 @@ ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| - | Interface Stability | Standard | + | Interface Stability | Committed | |_____________________________|_____________________________| | MT-Level | See below. | |_____________________________|_____________________________| @@ -111,9 +115,16 @@ - The vprintf() and vfprintf() functions are MT-Safe. The - vsprintf() and vsnprintf() functions are Async-Signal-Safe. + The vprintf(), vfprintf(), vsprintf(), and vsnprintf() functions + are Standard. The vasprintf() function is modeled on the one + that appears in the FreeBSD, NetBSD, and GNU C libraries. + All of these functions can be used safely in multithreaded + applications, as long as setlocale(3C) is not being called + to change the locale. + + The vsprintf() and vsnprintf() functions are Async-Signal-Safe. + SEE ALSO printf(3C), attributes(5), stdarg(3EXT), attributes(5), standards(5) From dp@eng.sun.com Thu Dec 18 15:24:11 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBINOBTm016414 for ; Thu, 18 Dec 2008 15:24:11 -0800 (PST) Received: from xanadu (xanadu.SFBay.Sun.COM [129.146.228.194]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mBINOAYY376833; Thu, 18 Dec 2008 15:24:10 -0800 (PST) Date: Thu, 18 Dec 2008 15:24:30 -0800 From: Dan Price To: "Roger A. Faulkner" Cc: psarc-ext@sac.sfbay.sun.com, tim.marsland@sun.com, john.levon@sun.com, peter.memishian@sun.com, daniel.price@sun.com Subject: Re: PSARC/2008/778 - asprintf, vasprintf Message-ID: <20081218232430.GD24462@eng.sun.com> References: <200812182305.mBIN5dP8370787@jurassic-x4600.sfbay.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200812182305.mBIN5dP8370787@jurassic-x4600.sfbay.sun.com> User-Agent: Mutt/1.5.14 (2007-02-12) Status: RO Content-Length: 462 On Thu 18 Dec 2008 at 03:05PM, Roger A. Faulkner wrote: > > ENOMEM Insufficient storage space is available. Roger-- does this errno of ENOMEM collapse the two malloc errnos (ENOMEM and EAGAIN) together? Or is EAGAIN still a possible errno return? Overall, looks great to me. This will be much appreciated by many many many people. Thanks for doing it. -dp -- Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp From peter.memishian@sun.com Thu Dec 18 15:34:19 2008 Received: from dm-east-02.east.sun.com (dm-east-02.East.Sun.COM [129.148.13.5]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBINYJkA016555 for ; Thu, 18 Dec 2008 15:34:19 -0800 (PST) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBINYEC5031374; Thu, 18 Dec 2008 18:34:14 -0500 (EST) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mBINYEV2746904; Thu, 18 Dec 2008 18:34:14 -0500 (EST) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mBINYEh8746845; Thu, 18 Dec 2008 18:34:14 -0500 (EST) X-Authentication-Warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18762.56822.312347.578583@gargle.gargle.HOWL> Date: Thu, 18 Dec 2008 18:34:14 -0500 From: Peter Memishian To: Dan Price Cc: "Roger A. Faulkner" , psarc-ext@sac.sfbay.sun.com, Tim.Marsland@sun.com, john.levon@sun.com, Peter.Memishian@sun.com, Daniel.Price@sun.com Subject: Re: PSARC/2008/778 - asprintf, vasprintf In-Reply-To: <20081218232430.GD24462@eng.sun.com> References: <200812182305.mBIN5dP8370787@jurassic-x4600.sfbay.sun.com> <20081218232430.GD24462@eng.sun.com> X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Reply-To: peter.memishian@sun.com Status: RO Content-Length: 321 > > ENOMEM Insufficient storage space is available. > > Roger-- does this errno of ENOMEM collapse the two malloc errnos > (ENOMEM and EAGAIN) together? Or is EAGAIN still a possible > errno return? Given the ability to DR in memory, what is the practical distinction between ENOMEM and EAGAIN? -- meem From Scott.Rotondo@Sun.COM Thu Dec 18 15:50:34 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBINoYGg016663 for ; Thu, 18 Dec 2008 15:50:34 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBINoYx5032263 for ; Thu, 18 Dec 2008 15:50:34 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mBINoXgd025571 for ; Thu, 18 Dec 2008 23:50:33 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KC300301J9O2W00@mail-amer.sun.com> (original mail from Scott.Rotondo@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Thu, 18 Dec 2008 16:50:33 -0700 (MST) Received: from [129.146.108.62] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KC30093CJK9IYD0@mail-amer.sun.com>; Thu, 18 Dec 2008 16:50:33 -0700 (MST) Date: Thu, 18 Dec 2008 15:50:32 -0800 From: Scott Rotondo Subject: Re: PSARC/2008/778 - asprintf, vasprintf In-reply-to: <18762.56822.312347.578583@gargle.gargle.HOWL> Sender: Scott.Rotondo@Sun.COM To: Peter.Memishian@Sun.COM Cc: Dan Price , "Roger A. Faulkner" , psarc-ext@sac.sfbay.sun.com, Tim.Marsland@Sun.COM, john.levon@Sun.COM, Daniel.Price@Sun.COM Message-id: <494AE1C8.7060406@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200812182305.mBIN5dP8370787@jurassic-x4600.sfbay.sun.com> <20081218232430.GD24462@eng.sun.com> <18762.56822.312347.578583@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.12 (X11/20080422) Status: RO Content-Length: 701 Peter Memishian wrote: > > > ENOMEM Insufficient storage space is available. > > > > Roger-- does this errno of ENOMEM collapse the two malloc errnos > > (ENOMEM and EAGAIN) together? Or is EAGAIN still a possible > > errno return? > > Given the ability to DR in memory, what is the practical distinction > between ENOMEM and EAGAIN? > At least in libumem, the distinction between ENOMEM and EAGAIN is based on constants in the library. If it returns ENOMEM, it's never going to succeed - no matter how much memory you add. Scott -- Scott Rotondo Principal Engineer, Solaris Security Technologies President, Trusted Computing Group Phone/FAX: +1 408 850 3655 (Internal x68278) From Roger.Faulkner@sun.com Thu Dec 18 17:41:44 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBJ1fiLx004465 for ; Thu, 18 Dec 2008 17:41:44 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.59]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id mBJ1fhhB398093; Thu, 18 Dec 2008 17:41:43 -0800 (PST) Message-Id: <200812190141.mBJ1fhhB398093@jurassic-x4600.sfbay.sun.com> Date: Thu, 18 Dec 2008 17:41:43 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: PSARC/2008/778 - asprintf, vasprintf To: dp@eng.sun.com Cc: psarc-ext@sac.sfbay.sun.com, tim.marsland@sun.com, john.levon@sun.com, peter.memishian@sun.com, daniel.price@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 2jiTu7/jPJqOIvkjT4Fv3A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_98 SunOS 5.11 i86pc i386 Status: RO Content-Length: 988 > Date: Thu, 18 Dec 2008 15:24:30 -0800 > From: Dan Price > Subject: Re: PSARC/2008/778 - asprintf, vasprintf > To: "Roger A. Faulkner" > Cc: psarc-ext@sac.sfbay.sun.com, tim.marsland@sun.com, john.levon@sun.com, peter.memishian@sun.com, daniel.price@sun.com > > On Thu 18 Dec 2008 at 03:05PM, Roger A. Faulkner wrote: > > > > ENOMEM Insufficient storage space is available. > > Roger-- does this errno of ENOMEM collapse the two malloc errnos > (ENOMEM and EAGAIN) together? Or is EAGAIN still a possible > errno return? I can arrange for [v]asprintf() to just return (-1) in the event that malloc() fails (letting the malloc() underpinnings set errno). And I could add EAGAIN to the possible errno values for failure. How does that sound? > Overall, looks great to me. This will be much appreciated by > many many many people. Thanks for doing it. > > -dp tpm made me do it. Give credit/blame to him. ;-) Roger From carlsonj@phorcys.east.sun.com Fri Dec 19 06:10:21 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBJEAKaE005865 for ; Fri, 19 Dec 2008 06:10:20 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mBJEAKHZ010273; Fri, 19 Dec 2008 09:10:20 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mBJEAKZM010270; Fri, 19 Dec 2008 09:10:20 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18763.43852.300195.299991@gargle.gargle.HOWL> Date: Fri, 19 Dec 2008 09:10:20 -0500 From: James Carlson To: "Roger A. Faulkner" Cc: psarc-ext@sac.sfbay.sun.com, Daniel.Price@sun.com, Tim.Marsland@sun.com, Peter.Memishian@sun.com Subject: Re: PSARC/2008/778 - asprintf, vasprintf In-Reply-To: <200812182305.mBIN5dP8370787@jurassic-x4600.sfbay.sun.com> References: <200812182305.mBIN5dP8370787@jurassic-x4600.sfbay.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 618 Roger A. Faulkner writes: > This case adds two new functions to the C library, asprintf() > and vasprintf() as follows: > > int asprintf(char **ret, const char *format, ...); > int vasprintf(char **ret, const char *format, va_list ap); > > The committment level of these interfaces is Committed. +1 with the addition of the somewhat dubious EAGAIN from malloc(3C). -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From roland.mainz@nrubsig.org Fri Dec 19 12:14:43 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBJKEhiR015126 for ; Fri, 19 Dec 2008 12:14:43 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBJKEhiQ033799 for ; Fri, 19 Dec 2008 12:14:43 -0800 (PST) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mBJK4com010107 for ; Fri, 19 Dec 2008 20:14:43 GMT Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay14i.sun.com with ESMTP id BT-MMP-976782 for psarc-ext@sac.sfbay.sun.com; Fri, 19 Dec 2008 20:14:42 Z Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-29058688 for psarc-ext@sac.sfbay.sun.com; Fri, 19 Dec 2008 20:14:42 Z Received: from mail-in-03.arcor-online.net ([151.189.21.43] [151.189.21.43]) by relay1ib.sun.com with ESMTP id BT-MMP-10065309 for psarc-ext@sac.sfbay.sun.com; Fri, 19 Dec 2008 20:14:42 Z Received: from mail-in-05-z2.arcor-online.net (mail-in-05-z2.arcor-online.net [151.189.8.17]) by mail-in-03.arcor-online.net (Postfix) with ESMTP id 76FFE2CAE8E; Fri, 19 Dec 2008 21:14:41 +0100 (CET) Received: from mail-in-02.arcor-online.net (mail-in-02.arcor-online.net [151.189.21.42]) by mail-in-05-z2.arcor-online.net (Postfix) with ESMTP id 450FD2DAF8F; Fri, 19 Dec 2008 21:14:41 +0100 (CET) Received: from jupiterb48.nrubsig.org (dslb-088-068-032-006.pools.arcor-ip.net [88.68.32.6]) by mail-in-02.arcor-online.net (Postfix) with ESMTP id D1317376550; Fri, 19 Dec 2008 21:14:40 +0100 (CET) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id mBJKEcIW008996; Fri, 19 Dec 2008 21:14:38 +0100 (CET) Sender: gisburn@jupiterb48.nrubsig.org Message-ID: <494C00AD.8AD9978E@nrubsig.org> Date: Fri, 19 Dec 2008 21:14:37 +0100 From: Roland Mainz X-Brightmail-Tracker: AAAAAA== X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) X-Accept-Language: en To: "Roger A. Faulkner" CC: psarc-ext@sac.sfbay.sun.com, daniel.price@sun.com, peter.memishian@sun.com Subject: Re: PSARC/2008/778 - asprintf, vasprintf References: <200812182305.mBIN5dP8370787@jurassic-x4600.sfbay.sun.com> X-Virus-Scanned: ClamAV 0.94.1/8786/Fri Dec 19 11:30:31 2008 on mail-in-02.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.054sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1195 "Roger A. Faulkner" wrote: > > I am sponsoring this automatic case for myself. > > 1. Introduction > > This case adds two new functions to the C library, asprintf() > and vasprintf() as follows: > > int asprintf(char **ret, const char *format, ...); > int vasprintf(char **ret, const char *format, va_list ap); > > The committment level of these interfaces is Committed. > > The release binding is "patch" > (so it can be back-ported to Solaris 10 if required). > > 2. Discussion > > Linux and the various BSD operating systems provide the *asprintf() > family of functions. These behave as sprintf(), except that they > allocate a string large enough to hold the result, and return a > pointer to that string. The caller is later expected to free() > this buffer. Will this even work if another library is used for |malloc()|&&|free()| calls (IMO it should work but I am not sure about the case when an application is linked via -B direct) ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From Nicolas.Williams@sun.com Fri Dec 19 13:01:48 2008 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBJL1mcC016393 for ; Fri, 19 Dec 2008 13:01:48 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mBJKrLwX014291; Fri, 19 Dec 2008 14:53:21 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mBJKrLfm014290; Fri, 19 Dec 2008 14:53:21 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 19 Dec 2008 14:53:21 -0600 From: Nicolas Williams To: Roland Mainz Cc: "Roger A. Faulkner" , psarc-ext@sac.sfbay.sun.com, Daniel.Price@sun.com, Peter.Memishian@sun.com Subject: Re: PSARC/2008/778 - asprintf, vasprintf Message-ID: <20081219205321.GV12468@Sun.COM> References: <200812182305.mBIN5dP8370787@jurassic-x4600.sfbay.sun.com> <494C00AD.8AD9978E@nrubsig.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <494C00AD.8AD9978E@nrubsig.org> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 430 On Fri, Dec 19, 2008 at 09:14:37PM +0100, Roland Mainz wrote: > Will this even work if another library is used for |malloc()|&&|free()| > calls (IMO it should work but I am not sure about the case when an > application is linked via -B direct) ? Yes, it will: malloc() and friends are marked as NODIRECT in libc, which means they can be interposed on freely by the application, even when they are called from within libc itself. From roland.mainz@nrubsig.org Fri Dec 19 13:23:56 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBJLNu7W016801 for ; Fri, 19 Dec 2008 13:23:56 -0800 (PST) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBJLNufG012621 for ; Fri, 19 Dec 2008 13:23:56 -0800 (PST) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mBJLKU4f006002 for ; Fri, 19 Dec 2008 21:23:55 GMT Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay44i.sun.com with ESMTP id BT-MMP-944884 for psarc-ext@sac.sfbay.sun.com; Fri, 19 Dec 2008 21:23:55 Z Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-21247432 for psarc-ext@sac.sfbay.sun.com; Fri, 19 Dec 2008 21:23:55 Z Received: from mail-in-07.arcor-online.net ([151.189.21.47] [151.189.21.47]) by relay4i.sun.com with ESMTP id BT-MMP-10905273 for psarc-ext@sac.sfbay.sun.com; Fri, 19 Dec 2008 21:23:55 Z Received: from mail-in-10-z2.arcor-online.net (mail-in-10-z2.arcor-online.net [151.189.8.27]) by mail-in-07.arcor-online.net (Postfix) with ESMTP id BBBF924AE1B; Fri, 19 Dec 2008 22:23:54 +0100 (CET) Received: from mail-in-12.arcor-online.net (mail-in-12.arcor-online.net [151.189.21.52]) by mail-in-10-z2.arcor-online.net (Postfix) with ESMTP id A176823D2EB; Fri, 19 Dec 2008 22:23:54 +0100 (CET) Received: from jupiterb48.nrubsig.org (dslb-088-068-032-006.pools.arcor-ip.net [88.68.32.6]) by mail-in-12.arcor-online.net (Postfix) with ESMTP id 54CEC8C463; Fri, 19 Dec 2008 22:23:54 +0100 (CET) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id mBJLNqRo009024; Fri, 19 Dec 2008 22:23:52 +0100 (CET) Sender: gisburn@jupiterb48.nrubsig.org Message-ID: <494C10E8.D67D538A@nrubsig.org> Date: Fri, 19 Dec 2008 22:23:52 +0100 From: Roland Mainz X-Brightmail-Tracker: AAAAAA== X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) X-Accept-Language: en To: Nicolas Williams CC: "Roger A. Faulkner" , psarc-ext@sac.sfbay.sun.com, Daniel.Price@sun.com, Peter.Memishian@sun.com Subject: Re: PSARC/2008/778 - asprintf, vasprintf References: <200812182305.mBIN5dP8370787@jurassic-x4600.sfbay.sun.com> <494C00AD.8AD9978E@nrubsig.org> <20081219205321.GV12468@Sun.COM> X-Virus-Scanned: ClamAV 0.94.1/8786/Fri Dec 19 11:30:31 2008 on mail-in-12.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.055sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Content-Length: 819 Nicolas Williams wrote: > On Fri, Dec 19, 2008 at 09:14:37PM +0100, Roland Mainz wrote: > > Will this even work if another library is used for |malloc()|&&|free()| > > calls (IMO it should work but I am not sure about the case when an > > application is linked via -B direct) ? > > Yes, it will: malloc() and friends are marked as NODIRECT in libc, which > means they can be interposed on freely by the application, even when > they are called from within libc itself. Devils advocate question: What happens if someone intercepts |asprintf()| or |vasprintf()| with his/her own function which doesn't use the default |malloc()| () ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From Roger.Faulkner@sun.com Fri Dec 19 13:26:59 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBJLQxbb016815 for ; Fri, 19 Dec 2008 13:26:59 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.63]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id mBJLQw5n295855; Fri, 19 Dec 2008 13:26:59 -0800 (PST) Message-Id: <200812192126.mBJLQw5n295855@jurassic-x4600.sfbay.sun.com> Date: Fri, 19 Dec 2008 13:26:59 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: PSARC/2008/778 - asprintf, vasprintf To: roland.mainz@nrubsig.org Cc: psarc-ext@sac.sfbay.sun.com, daniel.price@sun.com, peter.memishian@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: v/YUN85hU384x8Hz2Prczw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_98 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1932 > Date: Fri, 19 Dec 2008 21:14:37 +0100 > From: Roland Mainz > Subject: Re: PSARC/2008/778 - asprintf, vasprintf > To: "Roger A. Faulkner" > Cc: psarc-ext@sac.sfbay.sun.com, daniel.price@sun.com, peter.memishian@sun.com > X-Brightmail-Tracker: AAAAAA== > X-Virus-Scanned: ClamAV 0.94.1/8786/Fri Dec 19 11:30:31 2008 on mail-in-02.arcor-online.net > X-Virus-Status: Clean > X-Antispam: No, score=0.0/5.0, scanned in 0.058sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ > > "Roger A. Faulkner" wrote: > > > > I am sponsoring this automatic case for myself. > > > > 1. Introduction > > > > This case adds two new functions to the C library, asprintf() > > and vasprintf() as follows: > > > > int asprintf(char **ret, const char *format, ...); > > int vasprintf(char **ret, const char *format, va_list ap); > > > > The committment level of these interfaces is Committed. > > > > The release binding is "patch" > > (so it can be back-ported to Solaris 10 if required). > > > > 2. Discussion > > > > Linux and the various BSD operating systems provide the *asprintf() > > family of functions. These behave as sprintf(), except that they > > allocate a string large enough to hold the result, and return a > > pointer to that string. The caller is later expected to free() > > this buffer. > > Will this even work if another library is used for |malloc()|&&|free()| > calls (IMO it should work but I am not sure about the case when an > application is linked via -B direct) ? Sure. The code for [v]asprintf() calls malloc() (and free() on error). libc in general makes sure that any preloaded malloc library is used instead of the version in libc itself. It's no different from any other call to malloc() internally to libc. (The libc mapfiles mark malloc and free as NODIRECT.) Roger From bart.smaalders@Sun.COM Fri Dec 19 13:42:09 2008 Received: from zion.sfbay.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBJLg9gG016943 for ; Fri, 19 Dec 2008 13:42:09 -0800 (PST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id mBJLYeCA009802; Fri, 19 Dec 2008 21:34:40 GMT Message-ID: <494C136F.8090600@Sun.COM> Date: Fri, 19 Dec 2008 13:34:39 -0800 From: Bart Smaalders Organization: Sun Microsystems User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: Roland Mainz CC: Nicolas Williams , "Roger A. Faulkner" , psarc-ext@sac.sfbay.sun.com, Daniel.Price@Sun.COM, Peter.Memishian@Sun.COM Subject: Re: PSARC/2008/778 - asprintf, vasprintf References: <200812182305.mBIN5dP8370787@jurassic-x4600.sfbay.sun.com> <494C00AD.8AD9978E@nrubsig.org> <20081219205321.GV12468@Sun.COM> <494C10E8.D67D538A@nrubsig.org> In-Reply-To: <494C10E8.D67D538A@nrubsig.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1088 Roland Mainz wrote: > Nicolas Williams wrote: >> On Fri, Dec 19, 2008 at 09:14:37PM +0100, Roland Mainz wrote: >>> Will this even work if another library is used for |malloc()|&&|free()| >>> calls (IMO it should work but I am not sure about the case when an >>> application is linked via -B direct) ? >> Yes, it will: malloc() and friends are marked as NODIRECT in libc, which >> means they can be interposed on freely by the application, even when >> they are called from within libc itself. > > Devils advocate question: > What happens if someone intercepts |asprintf()| or |vasprintf()| with > his/her own function which doesn't use the default |malloc()| () ? > Any ON lib caller of asprintf() will call the libc version, which will inherit the application's malloc(), because ON is linke w/ direct binding. Any application calls will find their own version of asprintf(), which will do whatever it does. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From Roger.Faulkner@Sun.COM Fri Dec 19 13:42:33 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBJLgXUg016957 for ; Fri, 19 Dec 2008 13:42:33 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.59]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id mBJLgXp1297649; Fri, 19 Dec 2008 13:42:33 -0800 (PST) Message-Id: <200812192142.mBJLgXp1297649@jurassic-x4600.sfbay.sun.com> Date: Fri, 19 Dec 2008 13:42:33 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: PSARC/2008/778 - asprintf, vasprintf To: Nicolas.Williams@Sun.COM, roland.mainz@nrubsig.org Cc: psarc-ext@sac.sfbay.sun.com, Daniel.Price@Sun.COM, Peter.Memishian@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 6b6GdAnijDzYpFFBWygaZQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_98 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1554 > Date: Fri, 19 Dec 2008 22:23:52 +0100 > From: Roland Mainz > Subject: Re: PSARC/2008/778 - asprintf, vasprintf > To: Nicolas Williams > Cc: "Roger A. Faulkner" , psarc-ext@sac.sfbay.sun.com, Daniel.Price@Sun.COM, Peter.Memishian@Sun.COM > X-Brightmail-Tracker: AAAAAA== > X-Virus-Scanned: ClamAV 0.94.1/8786/Fri Dec 19 11:30:31 2008 on mail-in-12.arcor-online.net > X-Virus-Status: Clean > X-Antispam: No, score=0.0/5.0, scanned in 0.056sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ > > Nicolas Williams wrote: > > On Fri, Dec 19, 2008 at 09:14:37PM +0100, Roland Mainz wrote: > > > Will this even work if another library is used for |malloc()|&&|free()| > > > calls (IMO it should work but I am not sure about the case when an > > > application is linked via -B direct) ? > > > > Yes, it will: malloc() and friends are marked as NODIRECT in libc, which > > means they can be interposed on freely by the application, even when > > they are called from within libc itself. > > Devils advocate question: > What happens if someone intercepts |asprintf()| or |vasprintf()| with > his/her own function which doesn't use the default |malloc()| () ? > > ---- > > Bye, > Roland They must conform to the specification (from Linux and *BSD and now Solaris) that the pointer obtained from [v]asprintf() is to be the subject of free() when no longer needed. Otherwise, they have just shot themselves in the foot. What else did you expect? Roger From Nicolas.Williams@sun.com Fri Dec 19 13:46:48 2008 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBJLklUu017082 for ; Fri, 19 Dec 2008 13:46:48 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mBJLcMBA014321; Fri, 19 Dec 2008 15:38:22 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mBJLcMUB014320; Fri, 19 Dec 2008 15:38:22 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 19 Dec 2008 15:38:22 -0600 From: Nicolas Williams To: Roland Mainz Cc: "Roger A. Faulkner" , psarc-ext@sac.sfbay.sun.com, Daniel.Price@sun.com, Peter.Memishian@sun.com Subject: Re: PSARC/2008/778 - asprintf, vasprintf Message-ID: <20081219213821.GZ12468@Sun.COM> References: <200812182305.mBIN5dP8370787@jurassic-x4600.sfbay.sun.com> <494C00AD.8AD9978E@nrubsig.org> <20081219205321.GV12468@Sun.COM> <494C10E8.D67D538A@nrubsig.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <494C10E8.D67D538A@nrubsig.org> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 815 On Fri, Dec 19, 2008 at 10:23:52PM +0100, Roland Mainz wrote: > Nicolas Williams wrote: > > On Fri, Dec 19, 2008 at 09:14:37PM +0100, Roland Mainz wrote: > > > Will this even work if another library is used for |malloc()|&&|free()| > > > calls (IMO it should work but I am not sure about the case when an > > > application is linked via -B direct) ? > > > > Yes, it will: malloc() and friends are marked as NODIRECT in libc, which > > means they can be interposed on freely by the application, even when > > they are called from within libc itself. > > Devils advocate question: > What happens if someone intercepts |asprintf()| or |vasprintf()| with > his/her own function which doesn't use the default |malloc()| () ? They're allocator had better be interposing on libc's, else that's not supported. Nico -- From Roger.Faulkner@Sun.COM Fri Dec 19 13:52:17 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBJLqHRZ017193 for ; Fri, 19 Dec 2008 13:52:17 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.59]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id mBJLqHjf299145 for ; Fri, 19 Dec 2008 13:52:17 -0800 (PST) Message-Id: <200812192152.mBJLqHjf299145@jurassic-x4600.sfbay.sun.com> Date: Fri, 19 Dec 2008 13:52:17 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: PSARC/2008/778 - asprintf, vasprintf To: psarc-ext@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: JMlaSZVoqEuXqLKkkqygzg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_98 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1944 Date: Fri, 19 Dec 2008 13:47:09 -0800 (PST) From: "Roger A. Faulkner" Subject: Re: PSARC/2008/778 - asprintf, vasprintf To: psarc-ext@sac.sfbay.sun Cc: james.d.carlson@sun.com, Daniel.Price@sun.com, Tim.Marsland@sun.com, Peter.Memishian@sun.com > Date: Fri, 19 Dec 2008 09:10:20 -0500 > From: James Carlson > Subject: Re: PSARC/2008/778 - asprintf, vasprintf > To: "Roger A. Faulkner" > Cc: psarc-ext@sac.sfbay.sun.com, Daniel.Price@sun.com, Tim.Marsland@sun.com, Peter.Memishian@sun.com > > Roger A. Faulkner writes: > > This case adds two new functions to the C library, asprintf() > > and vasprintf() as follows: > > > > int asprintf(char **ret, const char *format, ...); > > int vasprintf(char **ret, const char *format, va_list ap); > > > > The committment level of these interfaces is Committed. > > +1 with the addition of the somewhat dubious EAGAIN from malloc(3C). > > -- > James Carlson, Solaris Networking Here is the addemdum to the case, specifying the EAGAIN errno for the failure case (diff of old vs new asprintf.3c): @@ -653,10 +667,12 @@ - The printf() and fprintf() functions may fail if: + The printf(), fprintf(), and asprintf() functions may fail + due to an underlying malloc(3C) failure: ENOMEM Insufficient storage space is available. + EAGAIN Storage space is temporarily unavailable. USAGE If the application calling the printf() functions has any @@ -798,14 +814,20 @@ SEE ALSO exit(2), lseek(2), write(2), abort(3C), ecvt(3C), exit(3C), - fclose(3C), fflush(3C), fputwc(3C), putc(3C), scanf(3C), + fclose(3C), fflush(3C), fputwc(3C), free(3C), malloc(3C), + putc(3C), scanf(3C), setlocale(3C), stdio(3C), vprintf(3C), wcstombs(3C), wctomb(3C), attributes(5), environ(5), standards(5) From gdamore@sun.com Fri Dec 19 14:38:26 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBJMcQlC018196 for ; Fri, 19 Dec 2008 14:38:26 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBJMcQRF001330 for ; Fri, 19 Dec 2008 14:38:26 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mBJMcLaY026075 for ; Fri, 19 Dec 2008 14:38:21 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KC500A01ALXN100@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for psarc-ext@sac.sfbay.sun.com; Fri, 19 Dec 2008 14:38:21 -0800 (PST) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KC500748AVWXPA0@fe-sfbay-10.sun.com>; Fri, 19 Dec 2008 14:38:21 -0800 (PST) Date: Fri, 19 Dec 2008 14:30:22 -0800 From: "Garrett D'Amore" Subject: Re: PSARC/2008/778 - asprintf, vasprintf In-reply-to: <494C10E8.D67D538A@nrubsig.org> Sender: Garrett.Damore@sun.com To: Roland Mainz Cc: Nicolas Williams , "Roger A. Faulkner" , psarc-ext@sac.sfbay.sun.com, Daniel.Price@sun.com, Peter.Memishian@sun.com Message-id: <494C207E.8020900@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200812182305.mBIN5dP8370787@jurassic-x4600.sfbay.sun.com> <494C00AD.8AD9978E@nrubsig.org> <20081219205321.GV12468@Sun.COM> <494C10E8.D67D538A@nrubsig.org> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1061 Roland Mainz wrote: > Nicolas Williams wrote: > >> On Fri, Dec 19, 2008 at 09:14:37PM +0100, Roland Mainz wrote: >> >>> Will this even work if another library is used for |malloc()|&&|free()| >>> calls (IMO it should work but I am not sure about the case when an >>> application is linked via -B direct) ? >>> >> Yes, it will: malloc() and friends are marked as NODIRECT in libc, which >> means they can be interposed on freely by the application, even when >> they are called from within libc itself. >> > > Devils advocate question: > What happens if someone intercepts |asprintf()| or |vasprintf()| with > his/her own function which doesn't use the default |malloc()| () ? > Then they better impose a reasonable malloc/free, or a free that works with both their allocators as well as malloc() memory. Why would anyone want to do this, btw? (Replacing the system malloc I understand. Replacing these functions with a version that doesn't use malloc() seems questionable, though.) --Garrett > ---- > > Bye, > Roland > >