Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Kevin Vigor <kevin@vi...> - 2001-01-26 23:24:28
In my last bit of monkeying about for today, I have just comitted a
change which should make parameters to varargs functions work in a more
intuitive way: small integer types (char/short) are upcast to int, and all
pointers are upcast to generic. This should make, for instance,
work without ugly typecasts (will wonders never cease?!).
An explicit typecast should disable this behavior.
Please note that this change can break existing code, for which I am
sorry; for instance, this code:
should now become:
printf("%d", c); // drop 'b' because c will be upcast to int
printf("%bd", (char)c); // explicit typecast should prevent cast to int.
I hope this doesn't break too much existing code, but I really think this
is an improvement.
> I hope this doesn't break too much existing code, but I really think this
> is an improvement.
So do I, now it's just a piece of cake to port existings software.
Just one flaw left (at line 159 in ds2480ut.c)
sendpacket[sendlen++] = CMD_CONFIG | PARMSEL_BAUDRATE | newbaud;
does (at line 877 in ds2480ut.asm):
mov dptr,#_DS2480ChangeBaud_PARM_2 ; this is newbaud
mov a,#0x71 ; this is CMD_CONFIG|PARMSEL_BAUDRATE
movx a,@dptr ; don't know why
orl a,a ; the assembler doesn't like this
Also the compiler still segmentation-fault's when DEMAND_... is defined.
From: Johan Knol <johan.knol@id...> - 2001-01-30 15:27:49
> Please note that this change can break existing code, for which I am
> sorry; for instance, this code:
> char c;
> printf("%bd", c);
> should now become:
> char c;
> printf("%d", c); // drop 'b' because c will be upcast to int
> char c;
> printf("%bd", (char)c); // explicit typecast should prevent cast to int.
That wouldn't be true if vprintf just ignores the 'b' specifier as in "%bd"
as I did in my local fix. Since printf, by it's nature, is inherently
complex and slow I would say we can live with the penalty for being ansi
compiant. It would require however that even a "(char)c" should be pushed as