Date: Wed, 17 Jul 2002 09:40:04 +0200 From: Thomas Pornin <pornin@bolet.org> To: "Chris J. Mutter" <cjm@satanii.enemy.org> Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: gftp core dumps for floating point exception Message-ID: <20020717094003.A11645@gnah.bolet.org> In-Reply-To: <200207162021.g6GKL5vt026115@satanii.enemy.org>; from cjm@satanii.enemy.org on Tue, Jul 16, 2002 at 10:21:05PM %2B0200 References: <20020716212939.4694066d.Jan.Lentfer@web.de> <200207162021.g6GKL5vt026115@satanii.enemy.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020717094003.A11645>