Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!agate!bionet!apple!rutgers!njin!princeton!udel!mmdf
From: ZQ0018%DMSWWU1A.BITNET@cunyvm.cuny.edu (Kai Henningsen)
Newsgroups: comp.os.minix
Subject: Re: minix/ST cc peculiarity
Message-ID: <5255@louie.udel.EDU>
Date: 9 Nov 88 01:23:32 GMT
Sender: mmdf@udel.EDU
Lines: 43


|I noticed the following problem in the minix st C compiler.
|Given the following program:
|#define SOMETHING -32768
|#include <stdio.h>
|
|main()
|{
|    printf("%d\n", SOMETHING);
|}
|
|The result is, that -1 is printed.
|Thing work well for -32767.
|Also defining SOMETHING as (int)(-32768L) works fine.
|
|This is obviously some conversion problem within the compiler.
|
|I have not checked things for MINLONG etc.
|
|by the way: don't use floats or doubles; they don't work.
|--
|Frans Meulenbroeks        (meulenbr@cst.prl.philips.nl)
|    Centre for Software Technology
|    ( or try: ...!mcvax!philmds!prle!cst!meulenbr)


What is happening is this:
When the compiler sees "-32768", it parses this as two tokens,
"-" and "32768". The latter has obviously to be some sort of
an int; it's too large for a short, so it must be a long.
This is negated, yielding -32768L, or 0xffff8000.
As printf %d expects a (short) int, it uses the first word
of this number, which on a 68K machine is 0xffff. This
is -1. The rest will be ignored in this case.

The problem is your assumption that because the number
-32768 CAN be represented as a short int, the compiler
will do so; instead look at the number alone: 32768
definitely is NOT short.

Kai Henningsen
zq0018 @ dmswwu1a . bitnet

or what path do you use?