mirror/freebsd
1
0
Fork 0
mirror of https://git.FreeBSD.org/src.git synced 2024-12-29 12:03:03 +00:00
Code Issues Releases Activity
149004e99d
freebsd/lib/libc/stdio/asprintf.c

68 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: asprintf.c,v 1.4 1998/06/21 22:13:46 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
*/
Fix the style of the SCM ID's. I believe have made all of libc .c's as consistent as possible.
2002-03-22 21:53:29 +00:00
#include <sys/cdefs.h>
__FBSDID("$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
#include <stdio.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 <stdlib.h>
#include <errno.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
#include <stdarg.h>
libc MT-safety, part 2. Add a lock to FILE. flockfile and friends are now implemented (for the most part) in libc. flockfile_debug is implemented in libc_r; I suppose it's about time to kill it but will do it in a future commit. Fix a potential deadlock in _fwalk in a threaded environment. A file flag (__SIGN) was added to stdio.h that, when set, tells _fwalk to ignore it in its walk. This seemed to be needed in refill.c because each file needs to be locked when flushing. Add a stub for pthread_self in libc. This is needed by flockfile which is allowed by POSIX to be recursive. Make fgetpos() error return value (-1) match man page. Remove recursive calls to locked functions (stdio); I think I've got them all, but I may have missed a couple. A few K&R -> ANSI conversions along with removal of a few instances of "register". $Id$ -> $FreeBSD$ in libc/stdio/rget.c Not objected to: -arch, a few months ago
2001-02-11 22:06:43 +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
asprintf(char **str, char const *fmt, ...)
{
int ret;
va_list 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
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
va_start(ap, 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
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;
return (-1);
}
f._bf._size = f._w = 127; /* Leave room for the NULL */
libc MT-safety, part 2. Add a lock to FILE. flockfile and friends are now implemented (for the most part) in libc. flockfile_debug is implemented in libc_r; I suppose it's about time to kill it but will do it in a future commit. Fix a potential deadlock in _fwalk in a threaded environment. A file flag (__SIGN) was added to stdio.h that, when set, tells _fwalk to ignore it in its walk. This seemed to be needed in refill.c because each file needs to be locked when flushing. Add a stub for pthread_self in libc. This is needed by flockfile which is allowed by POSIX to be recursive. Make fgetpos() error return value (-1) match man page. Remove recursive calls to locked functions (stdio); I think I've got them all, but I may have missed a couple. A few K&R -> ANSI conversions along with removal of a few instances of "register". $Id$ -> $FreeBSD$ in libc/stdio/rget.c Not objected to: -arch, a few months ago
2001-02-11 22:06:43 +00:00
ret = __vfprintf(&f, fmt, ap); /* Use unlocked __vfprintf */
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';
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
va_end(ap);
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;
}
*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