d/freebsd-nq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
f0d5097e06
freebsd-nq/lib/libc/stdio/vasprintf.c

67 lines
2.2 KiB
C
Raw Normal View History

Replace my original asprintf() and vasprintf() hacks with something more cleanly integrated with stdio. This should be faster and cleaner since it doesn't memcpy() the data into a seperate buffer. This lets stdio allocate and manage the buffer and then hand it over to the user. Obtained from: Todd Miller <Todd.Miller@courtesan.com> via OpenBSD
1998-07-08 00:44:56 +00:00
/* $OpenBSD: vasprintf.c,v 1.4 1998/06/21 22:13:47 millert Exp $ */
/*
* Copyright (c) 1997 Todd C. Miller <Todd.Miller@courtesan.com>
* All rights reserved.
Add an implementation of the gnu-ish asprintf() and vasprintf(). They are not based on gpl'ed code, just prototype and usage. I'm not 100% certain they behave the same while the system is in trouble (eg: malloc() failing) but in those circumstances all bets would be off anyway. These routines work like sprintf() and vsprintf(), except that instead of using a fixed buffer, they allocate memory and return it to the user and it's the user's responsibility to free() it. They have allocate as much memory as they need (and can get), so the size of strings it can deal with is limited only by the amount of memory it can malloc() on your behalf. There are a few gpl'ed programs starting to use this interface, and it's becoming more common with the scares about security risks with sprintf(). I dont like the look of the code that the various programs (including cvs, gdb, libg++, etc) provide if configure can't find it on the system. It should be possible to modify the stdio core code to provide this interface more efficiently, I was more worried about having something that worked and was secure. :-) (I noticed that there was once intended to be a smprintf() routine when our stdio was written for 4.4BSD, but it looks pretty stillborn, and it's intended interface is not clear). Since Linux and gnu libc have this interface, it seemed silly to bring yet another one onto the scene.
1996-05-27 10:49:43 +00:00
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
Replace my original asprintf() and vasprintf() hacks with something more cleanly integrated with stdio. This should be faster and cleaner since it doesn't memcpy() the data into a seperate buffer. This lets stdio allocate and manage the buffer and then hand it over to the user. Obtained from: Todd Miller <Todd.Miller@courtesan.com> via OpenBSD
1998-07-08 00:44:56 +00:00
* 3. The name of the author may not be used to endorse or promote products
* derived from this software without specific prior written permission.
Add an implementation of the gnu-ish asprintf() and vasprintf(). They are not based on gpl'ed code, just prototype and usage. I'm not 100% certain they behave the same while the system is in trouble (eg: malloc() failing) but in those circumstances all bets would be off anyway. These routines work like sprintf() and vsprintf(), except that instead of using a fixed buffer, they allocate memory and return it to the user and it's the user's responsibility to free() it. They have allocate as much memory as they need (and can get), so the size of strings it can deal with is limited only by the amount of memory it can malloc() on your behalf. There are a few gpl'ed programs starting to use this interface, and it's becoming more common with the scares about security risks with sprintf(). I dont like the look of the code that the various programs (including cvs, gdb, libg++, etc) provide if configure can't find it on the system. It should be possible to modify the stdio core code to provide this interface more efficiently, I was more worried about having something that worked and was secure. :-) (I noticed that there was once intended to be a smprintf() routine when our stdio was written for 4.4BSD, but it looks pretty stillborn, and it's intended interface is not clear). Since Linux and gnu libc have this interface, it seemed silly to bring yet another one onto the scene.
1996-05-27 10:49:43 +00:00
*
Replace my original asprintf() and vasprintf() hacks with something more cleanly integrated with stdio. This should be faster and cleaner since it doesn't memcpy() the data into a seperate buffer. This lets stdio allocate and manage the buffer and then hand it over to the user. Obtained from: Todd Miller <Todd.Miller@courtesan.com> via OpenBSD
1998-07-08 00:44:56 +00:00
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
* AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
* THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
* PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
* OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
* WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
* OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
* ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Add an implementation of the gnu-ish asprintf() and vasprintf(). They are not based on gpl'ed code, just prototype and usage. I'm not 100% certain they behave the same while the system is in trouble (eg: malloc() failing) but in those circumstances all bets would be off anyway. These routines work like sprintf() and vsprintf(), except that instead of using a fixed buffer, they allocate memory and return it to the user and it's the user's responsibility to free() it. They have allocate as much memory as they need (and can get), so the size of strings it can deal with is limited only by the amount of memory it can malloc() on your behalf. There are a few gpl'ed programs starting to use this interface, and it's becoming more common with the scares about security risks with sprintf(). I dont like the look of the code that the various programs (including cvs, gdb, libg++, etc) provide if configure can't find it on the system. It should be possible to modify the stdio core code to provide this interface more efficiently, I was more worried about having something that worked and was secure. :-) (I noticed that there was once intended to be a smprintf() routine when our stdio was written for 4.4BSD, but it looks pretty stillborn, and it's intended interface is not clear). Since Linux and gnu libc have this interface, it seemed silly to bring yet another one onto the scene.
1996-05-27 10:49:43 +00:00
*/
#if defined(LIBC_RCS) && !defined(lint)
$Id$ -> $FreeBSD$
1999-08-28 00:22:10 +00:00
static char rcsid[] = "$FreeBSD$";
Add an implementation of the gnu-ish asprintf() and vasprintf(). They are not based on gpl'ed code, just prototype and usage. I'm not 100% certain they behave the same while the system is in trouble (eg: malloc() failing) but in those circumstances all bets would be off anyway. These routines work like sprintf() and vsprintf(), except that instead of using a fixed buffer, they allocate memory and return it to the user and it's the user's responsibility to free() it. They have allocate as much memory as they need (and can get), so the size of strings it can deal with is limited only by the amount of memory it can malloc() on your behalf. There are a few gpl'ed programs starting to use this interface, and it's becoming more common with the scares about security risks with sprintf(). I dont like the look of the code that the various programs (including cvs, gdb, libg++, etc) provide if configure can't find it on the system. It should be possible to modify the stdio core code to provide this interface more efficiently, I was more worried about having something that worked and was secure. :-) (I noticed that there was once intended to be a smprintf() routine when our stdio was written for 4.4BSD, but it looks pretty stillborn, and it's intended interface is not clear). Since Linux and gnu libc have this interface, it seemed silly to bring yet another one onto the scene.
1996-05-27 10:49:43 +00:00
#endif /* LIBC_RCS and not lint */
#include <stdio.h>
#include <stdlib.h>
Replace my original asprintf() and vasprintf() hacks with something more cleanly integrated with stdio. This should be faster and cleaner since it doesn't memcpy() the data into a seperate buffer. This lets stdio allocate and manage the buffer and then hand it over to the user. Obtained from: Todd Miller <Todd.Miller@courtesan.com> via OpenBSD
1998-07-08 00:44:56 +00:00
#include <errno.h>
Remove _THREAD_SAFE and make libc thread-safe by default by adding (weak definitions to) stubs for some of the pthread functions. If the threads library is linked in, the real pthread functions will pulled in. Use the following convention for system calls wrapped by the threads library: __sys_foo - actual system call _foo - weak definition to __sys_foo foo - weak definition to __sys_foo Change all libc uses of system calls wrapped by the threads library from foo to _foo. In order to define the prototypes for _foo(), we introduce namespace.h and un-namespace.h (suggested by bde). All files that need to reference these system calls, should include namespace.h before any standard includes, then include un-namespace.h after the standard includes and before any local includes. <db.h> is an exception and shouldn't be included in between namespace.h and un-namespace.h namespace.h will define foo to _foo, and un-namespace.h will undefine foo. Try to eliminate some of the recursive calls to MT-safe functions in libc/stdio in preparation for adding a mutex to FILE. We have recursive mutexes, but would like to avoid using them if possible. Remove uneeded includes of <errno.h> from a few files. Add $FreeBSD$ to a few files in order to pass commitprep. Approved by: -arch
2001-01-24 13:01:12 +00:00
#include "local.h"
Add an implementation of the gnu-ish asprintf() and vasprintf(). They are not based on gpl'ed code, just prototype and usage. I'm not 100% certain they behave the same while the system is in trouble (eg: malloc() failing) but in those circumstances all bets would be off anyway. These routines work like sprintf() and vsprintf(), except that instead of using a fixed buffer, they allocate memory and return it to the user and it's the user's responsibility to free() it. They have allocate as much memory as they need (and can get), so the size of strings it can deal with is limited only by the amount of memory it can malloc() on your behalf. There are a few gpl'ed programs starting to use this interface, and it's becoming more common with the scares about security risks with sprintf(). I dont like the look of the code that the various programs (including cvs, gdb, libg++, etc) provide if configure can't find it on the system. It should be possible to modify the stdio core code to provide this interface more efficiently, I was more worried about having something that worked and was secure. :-) (I noticed that there was once intended to be a smprintf() routine when our stdio was written for 4.4BSD, but it looks pretty stillborn, and it's intended interface is not clear). Since Linux and gnu libc have this interface, it seemed silly to bring yet another one onto the scene.
1996-05-27 10:49:43 +00:00
int
vasprintf(str, fmt, ap)
char **str;
const char *fmt;
Replace my original asprintf() and vasprintf() hacks with something more cleanly integrated with stdio. This should be faster and cleaner since it doesn't memcpy() the data into a seperate buffer. This lets stdio allocate and manage the buffer and then hand it over to the user. Obtained from: Todd Miller <Todd.Miller@courtesan.com> via OpenBSD
1998-07-08 00:44:56 +00:00
_BSD_VA_LIST_ ap;
Add an implementation of the gnu-ish asprintf() and vasprintf(). They are not based on gpl'ed code, just prototype and usage. I'm not 100% certain they behave the same while the system is in trouble (eg: malloc() failing) but in those circumstances all bets would be off anyway. These routines work like sprintf() and vsprintf(), except that instead of using a fixed buffer, they allocate memory and return it to the user and it's the user's responsibility to free() it. They have allocate as much memory as they need (and can get), so the size of strings it can deal with is limited only by the amount of memory it can malloc() on your behalf. There are a few gpl'ed programs starting to use this interface, and it's becoming more common with the scares about security risks with sprintf(). I dont like the look of the code that the various programs (including cvs, gdb, libg++, etc) provide if configure can't find it on the system. It should be possible to modify the stdio core code to provide this interface more efficiently, I was more worried about having something that worked and was secure. :-) (I noticed that there was once intended to be a smprintf() routine when our stdio was written for 4.4BSD, but it looks pretty stillborn, and it's intended interface is not clear). Since Linux and gnu libc have this interface, it seemed silly to bring yet another one onto the scene.
1996-05-27 10:49:43 +00:00
{
int ret;
Replace my original asprintf() and vasprintf() hacks with something more cleanly integrated with stdio. This should be faster and cleaner since it doesn't memcpy() the data into a seperate buffer. This lets stdio allocate and manage the buffer and then hand it over to the user. Obtained from: Todd Miller <Todd.Miller@courtesan.com> via OpenBSD
1998-07-08 00:44:56 +00:00
FILE f;
Add an implementation of the gnu-ish asprintf() and vasprintf(). They are not based on gpl'ed code, just prototype and usage. I'm not 100% certain they behave the same while the system is in trouble (eg: malloc() failing) but in those circumstances all bets would be off anyway. These routines work like sprintf() and vsprintf(), except that instead of using a fixed buffer, they allocate memory and return it to the user and it's the user's responsibility to free() it. They have allocate as much memory as they need (and can get), so the size of strings it can deal with is limited only by the amount of memory it can malloc() on your behalf. There are a few gpl'ed programs starting to use this interface, and it's becoming more common with the scares about security risks with sprintf(). I dont like the look of the code that the various programs (including cvs, gdb, libg++, etc) provide if configure can't find it on the system. It should be possible to modify the stdio core code to provide this interface more efficiently, I was more worried about having something that worked and was secure. :-) (I noticed that there was once intended to be a smprintf() routine when our stdio was written for 4.4BSD, but it looks pretty stillborn, and it's intended interface is not clear). Since Linux and gnu libc have this interface, it seemed silly to bring yet another one onto the scene.
1996-05-27 10:49:43 +00:00
Replace my original asprintf() and vasprintf() hacks with something more cleanly integrated with stdio. This should be faster and cleaner since it doesn't memcpy() the data into a seperate buffer. This lets stdio allocate and manage the buffer and then hand it over to the user. Obtained from: Todd Miller <Todd.Miller@courtesan.com> via OpenBSD
1998-07-08 00:44:56 +00:00
f._file = -1;
f._flags = __SWR | __SSTR | __SALC;
f._bf._base = f._p = (unsigned char *)malloc(128);
if (f._bf._base == NULL) {
*str = NULL;
errno = ENOMEM;
Add an implementation of the gnu-ish asprintf() and vasprintf(). They are not based on gpl'ed code, just prototype and usage. I'm not 100% certain they behave the same while the system is in trouble (eg: malloc() failing) but in those circumstances all bets would be off anyway. These routines work like sprintf() and vsprintf(), except that instead of using a fixed buffer, they allocate memory and return it to the user and it's the user's responsibility to free() it. They have allocate as much memory as they need (and can get), so the size of strings it can deal with is limited only by the amount of memory it can malloc() on your behalf. There are a few gpl'ed programs starting to use this interface, and it's becoming more common with the scares about security risks with sprintf(). I dont like the look of the code that the various programs (including cvs, gdb, libg++, etc) provide if configure can't find it on the system. It should be possible to modify the stdio core code to provide this interface more efficiently, I was more worried about having something that worked and was secure. :-) (I noticed that there was once intended to be a smprintf() routine when our stdio was written for 4.4BSD, but it looks pretty stillborn, and it's intended interface is not clear). Since Linux and gnu libc have this interface, it seemed silly to bring yet another one onto the scene.
1996-05-27 10:49:43 +00:00
return (-1);
}
Replace my original asprintf() and vasprintf() hacks with something more cleanly integrated with stdio. This should be faster and cleaner since it doesn't memcpy() the data into a seperate buffer. This lets stdio allocate and manage the buffer and then hand it over to the user. Obtained from: Todd Miller <Todd.Miller@courtesan.com> via OpenBSD
1998-07-08 00:44:56 +00:00
f._bf._size = f._w = 127; /* Leave room for the NULL */
Remove _THREAD_SAFE and make libc thread-safe by default by adding (weak definitions to) stubs for some of the pthread functions. If the threads library is linked in, the real pthread functions will pulled in. Use the following convention for system calls wrapped by the threads library: __sys_foo - actual system call _foo - weak definition to __sys_foo foo - weak definition to __sys_foo Change all libc uses of system calls wrapped by the threads library from foo to _foo. In order to define the prototypes for _foo(), we introduce namespace.h and un-namespace.h (suggested by bde). All files that need to reference these system calls, should include namespace.h before any standard includes, then include un-namespace.h after the standard includes and before any local includes. <db.h> is an exception and shouldn't be included in between namespace.h and un-namespace.h namespace.h will define foo to _foo, and un-namespace.h will undefine foo. Try to eliminate some of the recursive calls to MT-safe functions in libc/stdio in preparation for adding a mutex to FILE. We have recursive mutexes, but would like to avoid using them if possible. Remove uneeded includes of <errno.h> from a few files. Add $FreeBSD$ to a few files in order to pass commitprep. Approved by: -arch
2001-01-24 13:01:12 +00:00
ret = __vfprintf(&f, fmt, ap);
Replace my original asprintf() and vasprintf() hacks with something more cleanly integrated with stdio. This should be faster and cleaner since it doesn't memcpy() the data into a seperate buffer. This lets stdio allocate and manage the buffer and then hand it over to the user. Obtained from: Todd Miller <Todd.Miller@courtesan.com> via OpenBSD
1998-07-08 00:44:56 +00:00
*f._p = '\0';
Replace memory leaking instances of realloc with non-leaking reallocf. In some cases replace if (a == null) a = malloc(x); else a = realloc(a, x); with simple reallocf(a, x). Per ANSI-C, this is guaranteed to be the same thing. I've been running these on my system here w/o ill effects for some time. However, the CTM-express is at part 6 of 34 for the CAM changes, so I've not been able to do a build world with the CAM in the tree with these changes. Shouldn't impact anything, but...
1998-09-16 04:17:47 +00:00
f._bf._base = reallocf(f._bf._base, f._bf._size + 1);
Replace my original asprintf() and vasprintf() hacks with something more cleanly integrated with stdio. This should be faster and cleaner since it doesn't memcpy() the data into a seperate buffer. This lets stdio allocate and manage the buffer and then hand it over to the user. Obtained from: Todd Miller <Todd.Miller@courtesan.com> via OpenBSD
1998-07-08 00:44:56 +00:00
if (f._bf._base == NULL) {
errno = ENOMEM;
ret = -1;
Fix off-by-one error PR: 3451 Submitted by: Tim Vanderhoek <ac199@hwcn.org>
1997-07-06 07:54:56 +00:00
}
Replace my original asprintf() and vasprintf() hacks with something more cleanly integrated with stdio. This should be faster and cleaner since it doesn't memcpy() the data into a seperate buffer. This lets stdio allocate and manage the buffer and then hand it over to the user. Obtained from: Todd Miller <Todd.Miller@courtesan.com> via OpenBSD
1998-07-08 00:44:56 +00:00
*str = (char *)f._bf._base;
Add an implementation of the gnu-ish asprintf() and vasprintf(). They are not based on gpl'ed code, just prototype and usage. I'm not 100% certain they behave the same while the system is in trouble (eg: malloc() failing) but in those circumstances all bets would be off anyway. These routines work like sprintf() and vsprintf(), except that instead of using a fixed buffer, they allocate memory and return it to the user and it's the user's responsibility to free() it. They have allocate as much memory as they need (and can get), so the size of strings it can deal with is limited only by the amount of memory it can malloc() on your behalf. There are a few gpl'ed programs starting to use this interface, and it's becoming more common with the scares about security risks with sprintf(). I dont like the look of the code that the various programs (including cvs, gdb, libg++, etc) provide if configure can't find it on the system. It should be possible to modify the stdio core code to provide this interface more efficiently, I was more worried about having something that worked and was secure. :-) (I noticed that there was once intended to be a smprintf() routine when our stdio was written for 4.4BSD, but it looks pretty stillborn, and it's intended interface is not clear). Since Linux and gnu libc have this interface, it seemed silly to bring yet another one onto the scene.
1996-05-27 10:49:43 +00:00
return (ret);
}
Reference in New Issue Copy Permalink