d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
8a77722ad7
freebsd-skq/sys/amd64/include/varargs.h

71 lines
2.7 KiB
C
Raw Normal View History

BSD 4.4 Lite Kernel Sources
1994-05-25 01:34:38 +00:00
/*-
* Copyright (c) 1990, 1993
* The Regents of the University of California. All rights reserved.
* (c) UNIX System Laboratories, Inc.
* All or some portions of this file are derived from material licensed
* to the University of California by American Telephone and Telegraph
* Co. or Unix System Laboratories, Inc. and are reproduced herein with
* the permission of UNIX System Laboratories, Inc.
*
* 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.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``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 REGENTS OR CONTRIBUTORS 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.
*
* @(#)varargs.h 8.2 (Berkeley) 3/22/94
Fixed the gcc ellipsis change to work with gcc-1.x.
1997-02-28 07:12:34 +00:00
* $Id: varargs.h,v 1.5 1997/02/22 09:35:22 peter Exp $
BSD 4.4 Lite Kernel Sources
1994-05-25 01:34:38 +00:00
*/
#ifndef _VARARGS_H_
#define _VARARGS_H_
typedef char *va_list;
I have no idea what this is all about, but it works and Bruce hasn't complained so it cannot be entirely bad :-) I include the email that probably explains it for people who already know: > >Compiling with -O3 inlines functions. However the function that is being > >inlined in makeinfo.c (add_word_args()) is a vararg function and must not be > >inlined. > > > >The code in question is K&R style, and AFIK, there is no way for the compiler > >to determine that the function uses vararg. Either change the code to use > >prototypes, or use stdarg, or add a directive to prevent inlining. > > Not declaring a varargs function as varargs before it is used gives > undefined behaviour. > > However, in practice the bug is probably in FreeBSD's <varargs.h>, which > doesn't use gcc's __builtin_next_arg(). gcc should notice that it is > used and not inline functions that have it. <stdarg.h.> uses it, but I > think there's another gcc builtin that it should be using. Patch attached. The ellipsis causes gcc to flag this as a varargs function, and the name "__builtin_va_alist" is special cased in gcc to hide the last argument in the arglist. Reviewed by: bde & phk Submitted by: jlemon@americantv.com (Jonathan Lemon)
1997-02-07 20:22:15 +00:00
#ifdef __GNUC__
Fixed the gcc ellipsis change to work with gcc-1.x.
1997-02-28 07:12:34 +00:00
#define va_alist __builtin_va_alist
#endif
#if __GNUC__ > 1
I have no idea what this is all about, but it works and Bruce hasn't complained so it cannot be entirely bad :-) I include the email that probably explains it for people who already know: > >Compiling with -O3 inlines functions. However the function that is being > >inlined in makeinfo.c (add_word_args()) is a vararg function and must not be > >inlined. > > > >The code in question is K&R style, and AFIK, there is no way for the compiler > >to determine that the function uses vararg. Either change the code to use > >prototypes, or use stdarg, or add a directive to prevent inlining. > > Not declaring a varargs function as varargs before it is used gives > undefined behaviour. > > However, in practice the bug is probably in FreeBSD's <varargs.h>, which > doesn't use gcc's __builtin_next_arg(). gcc should notice that it is > used and not inline functions that have it. <stdarg.h.> uses it, but I > think there's another gcc builtin that it should be using. Patch attached. The ellipsis causes gcc to flag this as a varargs function, and the name "__builtin_va_alist" is special cased in gcc to hide the last argument in the arglist. Reviewed by: bde & phk Submitted by: jlemon@americantv.com (Jonathan Lemon)
1997-02-07 20:22:15 +00:00
#define va_dcl int va_alist; ...
Fixed the gcc ellipsis change to work with gcc-1.x.
1997-02-28 07:12:34 +00:00
#else
I have no idea what this is all about, but it works and Bruce hasn't complained so it cannot be entirely bad :-) I include the email that probably explains it for people who already know: > >Compiling with -O3 inlines functions. However the function that is being > >inlined in makeinfo.c (add_word_args()) is a vararg function and must not be > >inlined. > > > >The code in question is K&R style, and AFIK, there is no way for the compiler > >to determine that the function uses vararg. Either change the code to use > >prototypes, or use stdarg, or add a directive to prevent inlining. > > Not declaring a varargs function as varargs before it is used gives > undefined behaviour. > > However, in practice the bug is probably in FreeBSD's <varargs.h>, which > doesn't use gcc's __builtin_next_arg(). gcc should notice that it is > used and not inline functions that have it. <stdarg.h.> uses it, but I > think there's another gcc builtin that it should be using. Patch attached. The ellipsis causes gcc to flag this as a varargs function, and the name "__builtin_va_alist" is special cased in gcc to hide the last argument in the arglist. Reviewed by: bde & phk Submitted by: jlemon@americantv.com (Jonathan Lemon)
1997-02-07 20:22:15 +00:00
#define va_dcl int va_alist;
#endif
BSD 4.4 Lite Kernel Sources
1994-05-25 01:34:38 +00:00
#define va_start(ap) \
ap = (char *)&va_alist
#ifdef KERNEL
#define va_arg(ap, type) \
((type *)(ap += sizeof(type)))[-1]
#else
#define va_arg(ap, type) \
((type *)(ap += sizeof(type) < sizeof(int) ? \
(abort(), 0) : sizeof(type)))[-1]
#endif
#define va_end(ap)
#endif /* !_VARARGS_H_ */
Reference in New Issue Copy Permalink