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
-----------------------------------------------------------------------
Nov 14 '05
63  3291 
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
In <20*******************@beagle.kn.op.dlr.de> Harti Brandt <br****@dlr.de> 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
In <cb**********@news-reader2.wanadoo.fr> "jacob navia" <ja***@jacob.remcomp.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
In <cb**********@news-reader2.wanadoo.fr> "jacob navia" <ja***@jacob.remcomp.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
In <Pi***********************************@unix45.andr ew.cmu.edu> "Arthur J. O'Dwyer" <aj*@nospam.andrew.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
Harti Brandt <br****@dlr.de> 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_Keith) 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.
On Wed, 30 Jun 2004, Dan Pop wrote:
DP>In <20*******************@beagle.kn.op.dlr.de> Harti Brandt <br****@dlr.de> 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
On Wed, 30 Jun 2004, Dan Pop wrote:
DP>In <cb**********@news-reader2.wanadoo.fr> "jacob navia" <ja***@jacob.remcomp.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>implementation 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
On Wed, 30 Jun 2004, Keith Thompson wrote:
KT>Harti Brandt <br****@dlr.de> 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
In <20*******************@beagle.kn.op.dlr.de> Harti Brandt <br****@dlr.de> writes: On Wed, 30 Jun 2004, Dan Pop wrote:
DP>In <20*******************@beagle.kn.op.dlr.de> Harti Brandt <br****@dlr.de> 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
On Tue, 29 Jun 2004 07:56:37 GMT, in comp.lang.c , andynaik
<an*************@mail.codecomments.com> wrote: Hi,
Whenever we type in this code
int main()
{
printf("%f",10);
}
we get an error.
Yes, because the code is broken.
We can remove that by using #pragma directive to
direct that to the 8087.
Don't do that, you're breaking it even worse.
Even after that the output is 0.00000 and not
10.0000. Can anybody tell me why it is like that and why typecasting is
not done in this case??
This has nothing to do with typecasting. You're calling printf() without
any prototype or declaration in scope, so it has no idea what the arguments
mean. You absolutely must declare functions before you use them, typically
by #including the correct header.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Mark McIntyre <ma**********@spamcop.net> writes: On Tue, 29 Jun 2004 07:56:37 GMT, in comp.lang.c , andynaik
<an*************@mail.codecomments.com> wrote:Whenever we type in this code
int main()
{
printf("%f",10);
}
we get an error.
Yes, because the code is broken.
[...] This has nothing to do with typecasting. You're calling printf() without
any prototype or declaration in scope, so it has no idea what the arguments
mean. You absolutely must declare functions before you use them, typically
by #including the correct header.
Including the <stdio.h> header to declare printf() won't solve this
problem (though of course you should do it anyway). For a function
that takes a variable number of arguments, the compiler still doesn't
know the types of the variable arguments. You have to make sure the
types of the arguments match the expected types for the format.
Some compilers may issue warnings based on the format string (if it's
a literal), but they won't do the conversions for you.
(BTW, Mark, your newsfeed.com sig is appearing twice on each post.)
--
Keith Thompson (The_Other_Keith) 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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Kapil Khosla |
last post by:
Hi,
I have been trying to understand this concept for quite sometime now
somehow I am missing some vital point. I am new to Object Oriented
Programming so maybe thats the reason.
I want to...
|
by: Nicolay Korslund |
last post by:
Hi! I'm having a little trouble with the typecast operator, can anybody
help me with the rules for when the this operator is invoked?
In the class 'Test' in the code below, the typecast operator...
|
by: Arun Prasath |
last post by:
Hi all,
I have the following question regd pointer typecasting. Is the
following type of pointer typecasting valid?
#define ALLOC(type,num) ((type *)malloc(sizeof(type)*num))
/*begin...
|
by: Vinod Patel |
last post by:
I have a piece of code : -
void *data;
......
/* data initialized */
......
struct known_struct *var = (struct known_struct*) data; /*typecasting*/
How is this different from simple...
|
by: jdm |
last post by:
In the sample code for the SortedList class, I see the use of a string
typecasting macro consisting of a single letter "S". i.e.:
Sortedlist->Add(S"Keyval one", S"Item one");
Now I have...
|
by: Raghu |
last post by:
Hello All,
I need some help regarding overloading operation.
Is there any way to overload typecasting?
I mean if i have a piece of code as below.
int a = 2:
float b;
b = (float)a;
|
by: Abhishek |
last post by:
why do I see that in most C programs, pointers in functions are
accepted as:
int func(int i,(void *)p) where p is a pointer or an address which is
passed from the place where it is called. what...
|
by: vivekian |
last post by:
Hi,
This is the part of the code am trying to compile to :
void Server::respondToClient ( std::string response )
{
....
....
if ((numbytes = sendto ( sockFd_ , response , sizeof(response)...
|
by: bwaichu |
last post by:
What is the best way to handle this warning:
warning: cast from pointer to integer of different size
I am casting in and out of a function that requires a pointer type. I
am casting an...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
| |
