Typecasting in C

[andynaik]

Hi,
Whenever we type in this code
int main()
{
printf("%f",10) ;
}
we get an error. We can remove that by using #pragma directive t
direct that to the 8087. Even after that the output is 0.00000 and no
10.0000. Can anybody tell me why it is like that and why typecasting i
not done in this case?
-
andynai
-----------------------------------------------------------------------
Posted via http://www.codecomments.co
-----------------------------------------------------------------------

[Harti Brandt]

On Tue, 29 Jun 2004, Default User wrote:

DU>Harti Brandt wrote:
DU>
DU>> %p is a quite new feature for printf().
DU>
DU>You must have an interesting definition of "quite new" in that it
DU>appeared in the 1989 standard and K&R 2.

In the standards world 15 years is quite new :-). From time to time I even
compile v7 code on modern platforms. Don't forget that there is an aweful
lot of old code still running. There are still pdp11 systems running
production code. In the bank I was working a couple of years ago they
discovered (while preparing for Y2K) that they have code from the 60s
running since then every day with most of the programmers already dead or
almost so.

So definitely there is a lot of code written when %p wasn't there yet in
many compilers.

DU>> Neither V7 nor BSD had this, so
DU>> the natural way of printing pointers was %x. Don't assume that everybody
DU>> out there does a daily update of it's compilers and libraries to the
DU>> current gcc.
DU>
DU>One needn't have a daily update, just one from, oh, the last 10 years or
DU>so.

I just tried to explain that if you have a program that works and compiles
with an old compiler you just don't want to port your program to
adhere to the standards.

Sure, when writing new software or re-writing you better do what the
standards say - there is already too many crappy (from the porting
standpoint of view) software out there. Many programmers unfortunately
didn't learn the 16 -> 32 bit lesson and happily stuff pointers into ints.

harti

[Dan Pop]

In <20************ *******@beagle. kn.op.dlr.de> Harti Brandt <br****@dlr.d e> writes:

%p is a quite new feature for printf().
Yeah, it's "only" 15 years old.
Neither V7 nor BSD had this,
How much code developed back then is still used *as such*?
so the natural way of printing pointers was %x.
Nope, this was a mistake even back then. Read K&R1. The *correct* way
of printing pointers was converting them to unsigned integers and using
whatever conversion was appropriate for unsigned integers.
Don't assume that everybody
out there does a daily update of it's compilers and libraries to the
current gcc.

OTOH, it is a fair assumption that all code originally developed before
1989 that is still being used *and* maintained, has been converted to
ANSI C long ago. Especially considering the existence of tools that
automate most of the process and the advantages of maintaining standard
C code.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <cb**********@n ews-reader2.wanadoo .fr> "jacob navia" <ja***@jacob.re mcomp.fr> writes:

As I mentioned in another thread, I started learning C using those printf
statements for debugging since there wasn't any debugger in those times.
Without casting the pointers, those printf calls have *always* been
incorrect and worked by pure accident.
And the usage became an habit.
There are good habits and bad habits. It is sheer stupidity to defend
the bad ones.
It has been working since more or less 20 years.
And it stopped working (portably) 12 years ago, when DEC released an
implementation with 32-bit integers and 64-bit pointers.

Not to mention the AS/400 oddity...
Is that a terrible sin?
YES!
Those printf statements never survived a lot anyway. Why
should I bother?
But you *do* bother, as proved in this very thread.
Is this extremely important?
The quality of your diagnostics is entirely up to you. But if you make
the wrong choices, expect your users to discover the benefits of gcc.
Maybe. The fact that I check printf (as few compilers do
actually) is ignored, and an oversight is amplified.

Your main competition, gcc, does a better job than you do and this is the
only thing that matters. Noone is going to leave your implementation in
favour of a worse one ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <cb**********@n ews-reader2.wanadoo .fr> "jacob navia" <ja***@jacob.re mcomp.fr> writes:

64 bit systems were never a succes, since at least a few
years. Many of them started but never become popular.

You're talking through your hat.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <Pi************ *************** ********@unix45 .andrew.cmu.edu > "Arthur J. O'Dwyer" <aj*@nospam.and rew.cmu.edu> writes:

[1] - It *was* "Turbo <PLOC>" that introduced 'far' and 'near',
wasn't it, and then Microsoft picked it up?

Nope, they were a Microsoft invention that became standard in the MSDOS
world. Believe it or not, they served an excellent purpose at the time.
People who didn't care about the performance of their codes on those
slow 8088 chips, could always use the huge memory model and pretend that
they're programming on an architecture with a linear address space.

Strictly speaking, the 8086 has a 20-bit linear address space.
It's just that it cannot access it as such, in software, because its
address registers have only 16 bits, hence the need for the segment-offset
pairs.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Keith Thompson]

Harti Brandt <br****@dlr.d e> writes:
[...]

In the standards world 15 years is quite new :-). From time to time I even
compile v7 code on modern platforms. Don't forget that there is an aweful
lot of old code still running. There are still pdp11 systems running
production code. In the bank I was working a couple of years ago they
discovered (while preparing for Y2K) that they have code from the 60s
running since then every day with most of the programmers already dead or
almost so.

So definitely there is a lot of code written when %p wasn't there yet in
many compilers.

If I compile such code with a modern compiler, I still want to see
warnings about printf format mismatches; some of them are going to
indicate real problems. If I don't want the warnings for some reason,
I can always set an option to disable them (or run "grep -v" on the
log file).

The default behavior shouldn't be optimized for compiling 20-year-old
code.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Harti Brandt]

On Wed, 30 Jun 2004, Dan Pop wrote:

DP>In <20************ *******@beagle. kn.op.dlr.de> Harti Brandt <br****@dlr.d e> writes:
DP>
DP>>%p is a quite new feature for printf().
DP>
DP>Yeah, it's "only" 15 years old.
DP>
DP>>Neither V7 nor BSD had this,
DP>
DP>How much code developed back then is still used *as such*?

Well, although this now starts to be off-topic: there is a lot of old code
out there. There is still a company marketing pdp11 and the associated OSs
(RSX, RT) because there is still a lot of software that does it's duty.
While working for a bank some 10 years ago they discovered (while
preparing for year 2k) that they had still at lot of assembler code from
the 60s running that does some of the nightly jobs (with programmers not
available anymore of course). Yes, that's not C-code, but there is also
old C-code. Only two or three years ago FreeBSD removed the _P() macro
from the kernel after several years of yearly discussion. The port to
sparc64 discovered a lot of problems of the sizeof(int) == sizeof(void *)
problem and I assume there are still such problems lingering around. Some
of the FreeBSD programs still have no prototypes...

DP> DP>>so the natural way of printing pointers was %x.
DP>
DP>Nope, this was a mistake even back then. Read K&R1. The *correct* way
DP>of printing pointers was converting them to unsigned integers and using
DP>whatever conversion was appropriate for unsigned integers.

So that would be %x, wouldn't it? I assumed, that you would write

printf("%x", (unsigned)ptr);

But, OTOH, if you look at the v7 code (utilities I mean, the kernel was a
bit cleaner in this regard), you'll notice that they didn't much
care about casts. It was natural to stuff integers into pointers and
pointers into integers, applying -> to pointers that point to a different
struct (the compiler had a single name space for field names), even to ->
integers (as far as I remember).

I once needed the dmr compiler to be compiled by gcc. That was a hard job
:-)

DP>
DP>>Don't assume that everybody
DP>>out there does a daily update of it's compilers and libraries to the
DP>>current gcc.
DP>
DP>OTOH, it is a fair assumption that all code originally developed before
DP>1989 that is still being used *and* maintained, has been converted to
DP>ANSI C long ago. Especially considering the existence of tools that
DP>automate most of the process and the advantages of maintaining standard
DP>C code.

I don't think so. My experience (at least in the industry, not the
academic world) is that one won't change a program just to conform to a
standard, but rather use the old compiler, if there really needs to be a
change in the program. Nobody (at least in a german company) would give
you a EU-cent for this :-(

But sure, there is no reason to do these mistakes nowadays.

harti

[Harti Brandt]

On Wed, 30 Jun 2004, Dan Pop wrote:

DP>In <cb**********@n ews-reader2.wanadoo .fr> "jacob navia" <ja***@jacob.re mcomp.fr> writes:
DP>
DP>
DP>>It has been working since more or less 20 years.
DP>
DP>And it stopped working (portably) 12 years ago, when DEC released an
DP>implementati on with 32-bit integers and 64-bit pointers.
DP>
DP>Not to mention the AS/400 oddity...

Or the segmented compiler (based on pcc) running on a Z8000 under
SystemIII. That one had 16bit ints and 32bit (really 24 bit with an unused
byte in the middle :-) pointers. I still have one of those.

harti

[Harti Brandt]

On Wed, 30 Jun 2004, Keith Thompson wrote:

KT>Harti Brandt <br****@dlr.d e> writes:
KT>[...]
KT>> In the standards world 15 years is quite new :-). From time to time I even
KT>> compile v7 code on modern platforms. Don't forget that there is an aweful
KT>> lot of old code still running. There are still pdp11 systems running
KT>> production code. In the bank I was working a couple of years ago they
KT>> discovered (while preparing for Y2K) that they have code from the 60s
KT>> running since then every day with most of the programmers already dead or
KT>> almost so.
KT>>
KT>> So definitely there is a lot of code written when %p wasn't there yet in
KT>> many compilers.
KT>
KT>If I compile such code with a modern compiler, I still want to see
KT>warnings about printf format mismatches; some of them are going to
KT>indicate real problems. If I don't want the warnings for some reason,
KT>I can always set an option to disable them (or run "grep -v" on the
KT>log file).
KT>
KT>The default behavior shouldn't be optimized for compiling 20-year-old
KT>code.

Sure.

harti

[Dan Pop]

In <20************ *******@beagle. kn.op.dlr.de> Harti Brandt <br****@dlr.d e> writes:

On Wed, 30 Jun 2004, Dan Pop wrote:

DP>In <20************ *******@beagle. kn.op.dlr.de> Harti Brandt <br****@dlr.d e> writes:
DP>
DP>>%p is a quite new feature for printf().
DP>
DP>Yeah, it's "only" 15 years old.
DP>
DP>>Neither V7 nor BSD had this,
DP>
DP>How much code developed back then is still used *as such*?

Well, although this now starts to be off-topic: there is a lot of old code
out there. There is still a company marketing pdp11 and the associated OSs
(RSX, RT) because there is still a lot of software that does it's duty.
You're talking about legacy applications, most of them existing only in
binary form, not about applications that are under active maintenance.
Therefore, in most cases, you don't even need a C compiler for the
machines you're talking about. Not to mention that C has never been the
programming language of choice under either RSX or RT (yes, I used
DECUS C for RSX-11 and I know what I'm talking about).
While working for a bank some 10 years ago they discovered (while
preparing for year 2k) that they had still at lot of assembler code from
the 60s running that does some of the nightly jobs (with programmers not
available anymore of course). Yes, that's not C-code, but there is also
old C-code.
Is this old C code used on new platforms and being maintained? Its
mere existence has no bearing on what compilers developed *today* should
do.
Only two or three years ago FreeBSD removed the _P() macro
from the kernel after several years of yearly discussion. The port to
sparc64 discovered a lot of problems of the sizeof(int) == sizeof(void *)
problem and I assume there are still such problems lingering around. Some
of the FreeBSD programs still have no prototypes...
They will get them, as soon as they need to be maintained (if ever).
Unless they are legacy applications, superseded by other programs (which
could explain why no one bothered to touch them).
DP> DP>>so the natural way of printing pointers was %x.
DP>
DP>Nope, this was a mistake even back then. Read K&R1. The *correct* way
DP>of printing pointers was converting them to unsigned integers and using
DP>whatever conversion was appropriate for unsigned integers.

So that would be %x, wouldn't it?
Or %o (the usual choice on the PDP-11) or even %u, depending on the
programmer's taste.
I assumed, that you would write

printf("%x", (unsigned)ptr);
ONLY if the implementation didn't support the unsigned long type. The
most sensible choice would be

printf("%lx", (unsigned long)ptr);

Think about "weird" platforms like the 8086, with its 16-bit int's and
32-bit pointers... It predated standard C by more than one decade.
But, OTOH, if you look at the v7 code (utilities I mean, the kernel was a
Why should I bother? Is such code in any way relevant to the behaviour
of compilers developed today? Are you sure you remember the topic
of this subthread?
I once needed the dmr compiler to be compiled by gcc. That was a hard job
:-)
Why would you expect otherwise? The dmr compiler was written in whatever
happened to be the definition of the C language at the time. gcc
implements a different language specification, even in -traditional mode.
DP>>Don't assume that everybody
DP>>out there does a daily update of it's compilers and libraries to the
DP>>current gcc.
DP>
DP>OTOH, it is a fair assumption that all code originally developed before
DP>1989 that is still being used *and* maintained, has been converted to ^^^^^^^^^^^^^^^ ^DP>ANSI C long ago. Especially considering the existence of tools that
DP>automate most of the process and the advantages of maintaining standard
DP>C code.

I don't think so. My experience (at least in the industry, not the
academic world) is that one won't change a program just to conform to a
standard, but rather use the old compiler, if there really needs to be a
change in the program. Nobody (at least in a german company) would give
you a EU-cent for this :-(

If you're talking about *legacy* applications, we're in perfect agreement.
No one wants to touch them more than *strictly* necessary. And certainly
not with a modern compiler.

But I was talking about code under active maintenance, i.e. code that has
been ported to modern platforms and whose specifications are still being
changed. Not to be confused with V7 code that is still used on a PDP-11
running V7.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de