From owner-freebsd-alpha Wed Jul 17 0:40:24 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D26D37B401 for ; Wed, 17 Jul 2002 00:40:15 -0700 (PDT) Received: from gnah.bolet.org (gnah.bolet.org [80.65.226.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4768D43E3B for ; Wed, 17 Jul 2002 00:40:13 -0700 (PDT) (envelope-from pornin@bolet.org) Received: (from pornin@localhost) by gnah.bolet.org (8.11.6/8.11.6) id g6H7e5s11947; Wed, 17 Jul 2002 09:40:06 +0200 (CEST) (envelope-from pornin) Date: Wed, 17 Jul 2002 09:40:04 +0200 From: Thomas Pornin To: "Chris J. Mutter" Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: gftp core dumps for floating point exception Message-ID: <20020717094003.A11645@gnah.bolet.org> References: <20020716212939.4694066d.Jan.Lentfer@web.de> <200207162021.g6GKL5vt026115@satanii.enemy.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200207162021.g6GKL5vt026115@satanii.enemy.org>; from cjm@satanii.enemy.org on Tue, Jul 16, 2002 at 10:21:05PM +0200 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jul 16, 2002 at 10:21:05PM +0200, Chris J. Mutter wrote: > it even doesnt compile with the compaq-cc. it gives an compile error when > it reaches gftp-text.h line 41: > > void gftp_text_log ( gftp_logging_level level, void *ptr, > const char *string, ... ) __attribute__((format(printf, 3, 4))); > > the compaq-cc expects a ``;'' after the ...) > > could someone with c-skills please explain me that line? The `...' means "function with a variable number of arguments" (just like printf()). Obviously, this function is some logging utility that takes printf()-like arguments formatted with a format string passed as the argument `string'. Up to and including the `... )', this is completely standard C. What follows (the `__attribute__' thing) is specific the gcc (which explains why ccc cannot compile it) and is a hint to the compiler that the types of the variadic arguments (beginning with the fourth argument) should be checked against the printf()-like format string held in the third argument (called `string'). As far as C syntax is concerned, just any bunch of arguments could be passed to a function with a variable number of arguments, but gcc knows some functions such as printf() and scans the format string (if it is a constant literal string) to check that the arguments actually passed are appropriate. gcc can be instructed to perform a similar check for other functions as well, through the __attribute__ construct displayed above. In good C code, this line should have looked like: void gftp_text_log(gftp_logging_level level, void *ptr, const char *string, ...) ATTRIBUTE((format(printf, 3, 4))); With the macro ATTRIBUTE defined somewhere as such: #ifdef __GNUC__ #define ATTRIBUTE(x) __attribute__(x) #else #define ATTRIBUTE(x) #endif > there are also some pointer-mismatches the compiler i.e. says: In this > statement, the referenced type of the pointer value "&data_addr_len" > is "unsigned long", which is not compatible with "unsigned int". > (ptrmismatch) That one is more serious. It means that some pointer to an unsigned long as been passed as argument to a function which expected a pointer to an unsigned int. This does not really matter on i386 platforms, since both `unsigned long' and `unsigned int' are 32-bit quantities on the PC. However, on the Alpha, `unsigned int' is 32-bit whereas `unsigned long' is 64-bit. This means that the function access a data value with the wrong size. In that specific instance, `data_addr_len' is probably a variable that should be filled with some array or structure length. Since the Alpha is little-endian (under FreeBSD at least), what happens there is probably that only the 32 lower bits of `data_addr_len' will be filled by the called function, and the 32 upper bits will remain untouched, which can trigger ugly bugs. By the way, I am not quite sure about the Alpha, but at least on the PC you will get a "floating point exception" (SIGFPE) only on integer arithmetic, when the result of an integer division does not fit into the destination register or when a division by 0 has been attempted. Floating point operations only yield "NaN" (Not a Number) on impossible operations. --Thomas Pornin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message