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
----------------------------------------------------------------------- 63  3288 
andynaik wrote: Hi,
Whenever we type in this code
int main()
{
printf("%f",10);
}
we get an error. We can remove that by using #pragma directive to
direct that to the 8087. 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??
%f is for double, but 10 is an int.
Rewrite as:
#include <stdio.h>
int main(){printf("%d",10);return 0;}
or as:
#include <stdio.h>
int main(){printf("%f",10.0);return 0;}
- Dario
"andynaik" <an*************@mail.codecomments.com> wrote in message
news:2e******************************@news.thenews groups.com... Whenever we type in this code
int main()
{
printf("%f",10);
}
we get an error. We can remove that by using #pragma directive to
direct that to the 8087.
Means nothing to me (compiler specifics are off-topic here).
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??
Read section 15 in the FAQ. Post back if you still have questions. http://www.eskimo.com/~scs/C-faq/s15.html
Alex
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.
Compiling MAIN.C:
Warning MAIN.C 4: Call to function 'printf' with no prototype
Warning MAIN.C 5: Function should return a value
Linking EXE\PROJ.EXE:
This code invokes an undefined behaviour (UB). It is mandatory to supply a
prototype when using a variadic function. Add
#include <stdio.h>
That said, 10 is a int. "%f" is expecting a double. If you want to printf a
double, use 10.0, or the (double) typecast.
Finally, some old Borland C compilers anre buggy and forget to link the
floating point library un such a case. This little hack can help:
#include <stdio.h>
#ifdef __BORLANDC__
/* The pesky "floating point formats not linked" killer hack : */
extern unsigned _floatconvert;
#pragma extref _floatconvert
#endif
int main (void)
{
printf ("%f\n", 10.0);
return 0;
}
--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
"Alex Fraser" <me@privacy.net> a écrit dans le message de
news:2k***********@uni-berlin.de... "andynaik" <an*************@mail.codecomments.com> wrote in message
news:2e******************************@news.thenews groups.com... Whenever we type in this code
int main()
{
printf("%f",10);
}
we get an error. We can remove that by using #pragma directive to
direct that to the 8087.
Means nothing to me (compiler specifics are off-topic here).
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??
Read section 15 in the FAQ. Post back if you still have questions.
http://www.eskimo.com/~scs/C-faq/s15.html
Alex
The FAQ should mention that some compilers DO test the arguments
for sprintf/printf/fprintf etc for validity.
This CAN be done. lcc-win32 does it, and other compilers too.
For instance the above code produces
Warning tx.c: 4 printf argument mismatch for format f. Expected double got
int
0 errors, 1 warnings
Some compilers DO test the arguments of printf for
validity.
Under lcc-win32 the above code produces:
Warning tx.c: 4 printf argument mismatch for format f. Expected double got
int
0 errors, 1 warnings
In <cb**********@news-reader3.wanadoo.fr> "jacob navia" <ja***@jacob.remcomp.fr> writes: The FAQ should mention that some compilers DO test the arguments
for sprintf/printf/fprintf etc for validity.
This CAN be done.
ONLY if the compiler can "see" the contents of the format string.
Which is usually the case, but exceptions are not that rare either.
At some point, gcc had the annoying habit of warning if it couldn't
perform such a check (if enabled), because the format was not a
string literal.
lcc-win32 does it, and other compilers too.
Other compilers do a much better job than lcc-win32, when it comes to
format string consistency checks. See below.
For instance the above code produces
Warning tx.c: 4 printf argument mismatch for format f. Expected double got
int
0 errors, 1 warnings
OTOH, lcc-win32 silently accepts printf("%d\n", "foo"), which is very
bad, considering the relative positions of the D and S keys on most
keyboard layouts (i.e. it is a fairly frequent mistake to type d
when you mean s).
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
"Dan Pop" <Da*****@cern.ch> a écrit dans le message de
news:cb**********@sunnews.cern.ch... OTOH, lcc-win32 silently accepts printf("%d\n", "foo"), which is very
bad, considering the relative positions of the D and S keys on most
keyboard layouts (i.e. it is a fairly frequent mistake to type d
when you mean s).
I pondered a long time about that one, since it is perfectly legal to
do:
char *p;
....
printf("The address is %d\n",p);
specially in debugging code.
Granted, this is weird, but how to discriminate between
legal and wrong usage?
But maybe you are right. I added a warning when the "d" format
is used with a pointer.
The "x" format will NOT provoke any warnings.
But this is at the limit of what a compiler can do.
In <cb**********@news-reader1.wanadoo.fr> "jacob navia" <ja***@jacob.remcomp.fr> writes: "Dan Pop" <Da*****@cern.ch> a écrit dans le message de
news:cb**********@sunnews.cern.ch... OTOH, lcc-win32 silently accepts printf("%d\n", "foo"), which is very
bad, considering the relative positions of the D and S keys on most
keyboard layouts (i.e. it is a fairly frequent mistake to type d
when you mean s).
I pondered a long time about that one, since it is perfectly legal to
do: ^^^^^^^^^^^^^^^^^^
char *p;
...
printf("The address is %d\n",p);
What have you been smoking recently?
specially in debugging code.
Granted, this is weird, but how to discriminate between
legal and wrong usage?
^^^^^
Can I have a chapter and verse? When did they drop the following
paragraph from the C standard?
9 If a conversion specification is invalid, the behavior is
undefined. If any argument is not the correct type for the
corresponding conversion specification, the behavior is undefined.
What is the type expected by %d? What is the type of p?
So, the legal usage would be (int)p instead of a plain p, right?
But maybe you are right. I added a warning when the "d" format
is used with a pointer.
The "x" format will NOT provoke any warnings.
Which is just as bad, especially given that x is also a typo candidate
for s.
But this is at the limit of what a compiler can do.
In your humble opinion, what is the purpose of the %p conversion
specification? Why support *anything else* for displaying pointer values?
And if a user *really* wants to use the extra flexibility of the
signed or unsigned integer conversion descriptors, what is preventing
him from casting the pointer to the desired type?
As I said in other threads, you have nothing to lose by using gcc's
behaviour as a guide. If you can benefit from the thought many competent
people have put into the same issue, why reinvent the wheel?
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
andynaik wrote: Hi,
Whenever we type in this code
int main()
{
printf("%f",10);
}
we get an error. We can remove that by using #pragma directive to
direct that to the 8087. 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??
Because you forgot
#include <stdio.h>
You also forgot to terminate the last line of output with an end-of-line
character.
The first mistake, omission of the prototype for a variadic function, is
always an error. The second is an error in code designed to be
portable, and may result in behavior you were not expecting.
jacob navia wrote: "Dan Pop" <Da*****@cern.ch> a écrit dans le message de
news:cb**********@sunnews.cern.ch...
OTOH, lcc-win32 silently accepts printf("%d\n", "foo"), which is very
bad, considering the relative positions of the D and S keys on most
keyboard layouts (i.e. it is a fairly frequent mistake to type d
when you mean s).
I pondered a long time about that one, since it is perfectly legal to
do:
char *p;
...
printf("The address is %d\n",p);
The specifier for a pointer is "%p" and it expects a (void *) argument.
This supposedly "legal" line should be
printf("The address is %p\n", (void *)p);
Please stop misleading people who might think you know what you're
talking about.
specially in debugging code.
Granted, this is weird, but how to discriminate between
legal and wrong usage?
You "legal" usage is _wrong_. There is no need to discriminate between
your error and that which is wrong.
The expression
printf("the address is: 0x%x\n",p);
where p is some pointer appears in several million lines in
existing code.
The warnings can become a nuisance and people would stop
using this feature. Personally I think warnings should be
kept to the essential ones, warnings that would uncover a
possible error.
Strictly speaking you should use %p, but I have almost
never seen it in debugging code, where this conversion is
used.
To the contrary of your expectations, I work to make a usable
compiler, not one that will please the purists around c.l.c
In article <cb**********@news-reader1.wanadoo.fr>, ja***@jacob.remcomp.fr
says... I pondered a long time about that one, since it is perfectly legal to
do:
char *p;
...
printf("The address is %d\n",p);
specially in debugging code.
I just lost any faith I might have had in lcc-win32. Thanks for
the flashing warning label.
In <2k************@uni-berlin.de> Martin Ambuhl <ma*****@earthlink.net> writes: andynaik wrote:
Hi,
Whenever we type in this code
int main()
{
printf("%f",10);
}
we get an error. We can remove that by using #pragma directive to
direct that to the 8087. 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??
Because you forgot
#include <stdio.h>
You also forgot to terminate the last line of output with an end-of-line
character. ^^^^^^^^^^^
^^^^^^^^^
In C, it is called new-line character, even if no line follows. You must
be confusing with the end-of-line *indicator* (which needs not be a
character).
The first mistake, omission of the prototype for a variadic function, is
always an error. The second is an error in code designed to be
portable, and may result in behavior you were not expecting.
Neither of then having anything to do with the real cause of the OP's
problem: type mismatch in a printf call, which will continue to manifest
even after including <stdio.h> and adding the new-line character.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
On Tue, 29 Jun 2004, jacob navia wrote:
jn>The expression
jn>
jn>printf("the address is: 0x%x\n",p);
jn>
jn>where p is some pointer appears in several million lines in
jn>existing code.
jn>
jn>The warnings can become a nuisance and people would stop
jn>using this feature. Personally I think warnings should be
jn>kept to the essential ones, warnings that would uncover a
jn>possible error.
jn>
jn>Strictly speaking you should use %p, but I have almost
jn>never seen it in debugging code, where this conversion is
jn>used.
jn>
jn>To the contrary of your expectations, I work to make a usable
jn>compiler, not one that will please the purists around c.l.c
That has nothing to do with purism. Ever cared to work on a machine where
sizeof(void *) > sizeof(int)? The nearest to correct thing to do if you
happen to have a printf() without %p would be to use %lx and cast the
pointer to an unsigned long.
harti
In <2e******************************@news.thenewsgrou ps.com> andynaik <an*************@mail.codecomments.com> writes: Whenever we type in this code
int main()
{
printf("%f",10);
}
we get an error. We can remove that by using #pragma directive to
direct that to the 8087. 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??
Since type casting is a programming construct, it is you who have to
explain us why you have omitted it from your program.
If your question is why 10 wasn't *automatically converted*, which is
something *completely* different from type casting, the answer is that
it is located in the variable argument part of the printf call and,
therefore, it is subject to the default argument promotions, *only*.
In other words, although the compiler is allowed to have special
knowledge about printf, it is not required to have such knowledge or to
use it for fixing any mismatch between the format string and the rest
of the arguments.
Furthermore, because printf is a variadic function, you *must* provide
a correct declaration for it, before calling it. So, including <stdio.h>
is NOT optional in programs using printf and/or scanf. And a new-line
character in the format string wouldn't hurt, either: the shell prompt
*may* overwrite the last line of output, otherwise. Or be appended to it,
which, even if less destructive, is still far from desirable.
As a last remark, NOW it is the right time to get used to properly
indenting your code.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <Xn***************************@212.27.42.65> Emmanuel Delahaye <em**********@noos.fr> writes: 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.
Compiling MAIN.C:
Warning MAIN.C 4: Call to function 'printf' with no prototype
Warning MAIN.C 5: Function should return a value
Linking EXE\PROJ.EXE:
You're sorely mistaken if you believe that compiler diagnostics *by
themselves* prove anything at all.
This code invokes an undefined behaviour (UB).
Which means that no diagnostic is required. Furthermore, even if all the
diagnostics of your compiler are fixed, the program is still as broken
as it was in the first place.
It is mandatory to supply a
prototype when using a variadic function. Add
#include <stdio.h>
That said, 10 is a int. "%f" is expecting a double. If you want to printf a
double, use 10.0, or the (double) typecast.
Did you actually try to understand the OP's question? He *knows* that
"%f" is expecting a double and he is asking why the compiler doesn't
convert 10 to double. WHERE are you addressing this question in your
reply?
Finally, some old Borland C compilers anre buggy and forget to link the
floating point library un such a case. This little hack can help:
Since when are some old Borland C compilers topical to this newsgroup?
Aren't they properly handled by the FAQ?
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <cb**********@news-reader3.wanadoo.fr> "jacob navia" <ja***@jacob.remcomp.fr> writes: "Alex Fraser" <me@privacy.net> a écrit dans le message de
news:2k***********@uni-berlin.de... "andynaik" <an*************@mail.codecomments.com> wrote in message
news:2e******************************@news.thenews groups.com... > Whenever we type in this code
> int main()
> {
> printf("%f",10);
> }
> we get an error. We can remove that by using #pragma directive to
> direct that to the 8087.
Means nothing to me (compiler specifics are off-topic here).
> 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??
Read section 15 in the FAQ. Post back if you still have questions.
http://www.eskimo.com/~scs/C-faq/s15.html
The FAQ should mention that some compilers DO test the arguments
for sprintf/printf/fprintf etc for validity.
But they *still* don't perform any automatic conversions on the arguments,
to make them match the format string (other than the default argument
promotions).
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
"Harti Brandt" <br****@dlr.de> a écrit dans le message de
news:20*******************@beagle.kn.op.dlr.de... On Tue, 29 Jun 2004, jacob navia wrote:
That has nothing to do with purism. Ever cared to work on a machine where
sizeof(void *) > sizeof(int)?
In the next implementation of lcc-win32 that will be the case (64 bit
machine).
In THAT environment I will issue the warning for all pointer/int
conversions.
In an environment where sizeof(int)==sizeof(void*) many people
(including me) write printf("pointer value=%#x\n",p); to debug
a piece of code. The compiler spitting you hundreds of warnings
would only have the consequence of people IGNORING all warnings.
lcc-win32 has several levels of warnings. After this discussion I have added
a warning when the warning level is higher than normal for all
implicit pointer/int conversions in the printf formats.
It is a pity that people here like to have an atmosphere of
aggresivity that is very boring.
In any case this discussion was positive for me (and lcc-win32).
I have been able to improve lcc-win32 a bit.
Thanks for your time.
"Randy Howard" <ra*********@FOOverizonBAR.net> a écrit dans le message de
news:MP************************@news.verizon.net.. . In article <cb**********@news-reader1.wanadoo.fr>, ja***@jacob.remcomp.fr
says...
I just lost any faith I might have had in lcc-win32. Thanks for
the flashing warning label.
Mr Howard
It is a pity that people here like to have an atmosphere of
aggresivity that is so boring.
In any case this discussion was positive for me (and lcc-win32).
I have been able to improve lcc-win32 a bit.
Thanks for your time.
In <cb**********@news-reader3.wanadoo.fr> "jacob navia" <ja***@jacob.remcomp.fr> writes: The expression
printf("the address is: 0x%x\n",p);
where p is some pointer appears in several million lines in
existing code.
If you think that the amount of existing broken code can prove anything,
you're sorely mistaken. The days when all the world was a 32-bit
platform are gone...
The warnings can become a nuisance and people would stop
using this feature. Personally I think warnings should be
kept to the essential ones, warnings that would uncover a
possible error.
In your stupidity, you don't realise that this is a genuine error, it
just doesn't manifest on *your* platform. Try to engage your brain
and think about platforms with 32-bit int's and 64-bit pointers
(increasingly common since DEC released Alpha OSF/1 in 1992).
To show you that the issue is *real* and not invented ad-hoc:
lx64:~/tmp 11> uname -m
x86_64
lx64:~/tmp 12> cat test.c
#include <stdio.h>
int main(void)
{
int i;
printf("%#x %p\n", &i, (void *)&i);
return 0;
}
lx64:~/tmp 13> gcc test.c
lx64:~/tmp 14> ./a.out
0xbffff00c 0x7fbffff00c
lx64:~/tmp 15> gcc -Wall test.c
test.c: In function `main':
test.c:6: warning: unsigned int format, pointer arg (arg 2)
As you can see, the two values are different: %x has lost information.
So, the people developing their code on your compiler will have a bad
surprise when trying to use it elsewhere and you believe that you're
doing them a favour!
Strictly speaking you should use %p, but I have almost
never seen it in debugging code, where this conversion is
used.
To the contrary of your expectations, I work to make a usable
compiler, not one that will please the purists around c.l.c
If you think you're doing your users any service by not diagnosing
their genuine mistakes, simply because they *accidentally* work on
your platform, you're even more stupid than I thought. People like you
have no business messing with compilers and libraries.
The FAQ *should* contain the following question: "Why should I avoid
lcc-win32 like the plague?". But the answer would significantly increase
its current size...
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
On Tue, 29 Jun 2004, jacob navia wrote:
The expression
printf("the address is: 0x%x\n",p);
where p is some pointer appears in several million lines in
existing code.
Has anyone besides Jacob ever seen this construct (or anything
similar) in real-world code? I've never encountered it. The
usual idiom in my part of the universe is more like
printf("(%d) %p\n", p!=NULL, (void*)p);
which has the benefit of (a) telling you something useful, and
(b) being standard, warning-less C code.
Who's been using "%d" or "%x" to print *pointer* values?
-Arthur
Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> wrote: On Tue, 29 Jun 2004, jacob navia wrote:
The expression
printf("the address is: 0x%x\n",p);
where p is some pointer appears in several million lines in
existing code.
Has anyone besides Jacob ever seen this construct (or anything
similar) in real-world code? I've never encountered it. The
usual idiom in my part of the universe is more like
printf("(%d) %p\n", p!=NULL, (void*)p);
which has the benefit of (a) telling you something useful, and
(b) being standard, warning-less C code.
Who's been using "%d" or "%x" to print *pointer* values?
It is quite common in legacy code. Especially in the stuff that
got carried over from the pre-ANSI days.
--
Alex Monjushko (mo*******@hotmail.com)
On Tue, 29 Jun 2004, Arthur J. O'Dwyer wrote:
AJO>
AJO>On Tue, 29 Jun 2004, jacob navia wrote:
AJO>>
AJO>> The expression
AJO>> printf("the address is: 0x%x\n",p);
AJO>> where p is some pointer appears in several million lines in
AJO>> existing code.
AJO>
AJO> Has anyone besides Jacob ever seen this construct (or anything
AJO>similar) in real-world code? I've never encountered it. The
AJO>usual idiom in my part of the universe is more like
AJO>
AJO> printf("(%d) %p\n", p!=NULL, (void*)p);
AJO>
AJO>which has the benefit of (a) telling you something useful, and
AJO>(b) being standard, warning-less C code.
AJO>
AJO> Who's been using "%d" or "%x" to print *pointer* values?
%p is a quite new feature for printf(). Neither V7 nor BSD had this, so
the natural way of printing pointers was %x. Don't assume that everybody
out there does a daily update of it's compilers and libraries to the
current gcc.
harti
"jacob navia" <ja***@jacob.remcomp.fr> writes: The expression
printf("the address is: 0x%x\n",p);
where p is some pointer appears in several million lines in
existing code.
Then there are several million errors, and you'd be doing your users a
favor by letting them know.
For example, on an IA-64 system:
#include <stdio.h>
int main(void)
{
char *p = "hello";
printf("Using %%x: p = 0x%x\n", p); /* wrong */
printf("Using %%p: p = %p\n", (void*)p); /* right */
return 0;
}
produces the following output:
Using %x: p = 0x7c0
Using %p: p = 0x40000000000007c0
I suspect that platforms with 32-bit ints and 64-bit pointers are
going to become much more common over the next few years. The sooner
programmers realize that all the world's not a VAX^H^H^H x86, the
better. Even if the sizes happen to match, it's still undefined
behavior, and any number of things can go wrong.
If you really want to make sure the address value is displayed in
hexadecimal, and you're willing to assume that pointers and ints are
the same size (e.g., you're writing a quick-and-dirty debugging
statement that will be deleted before the code could ever be ported to
another platform), you can always cast the pointer value to unsigned
int to inhibit the warning. The result may or may not be meaningful,
but at least it avoids undefined behavior.
Or you can just use "%p", which exists for exactly this purpose.
--
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.
In article <Pi**********************************@unix48.andre w.cmu.edu>, aj*@nospam.andrew.cmu.edu says...
On Tue, 29 Jun 2004, jacob navia wrote:
The expression
printf("the address is: 0x%x\n",p);
where p is some pointer appears in several million lines in
existing code.
Has anyone besides Jacob ever seen this construct (or anything
similar) in real-world code? I've never encountered it.
Unfortunately yes, but not in quite some time. I ran into it
fairly often in the MS-DOS and early Windows days. (Maybe Mr.
Schildt used it a lot in his books???) It was probably in a fair
amount of older legacy UNIX code as well, but I can't recall an
example offhand.
Usually they at least cast the type of p to something appropriate
for the %d or %x on the platform. Every time I encounter something
like that, I fix it, but it doesn't happen much anymore, plus I very
rarely get stuck maintaining code that poor these days.
--
Randy Howard (2reply remove FOOBAR)
"The most amazing achievement of the computer software industry is its
continuing cancellation of the steady and staggering gains made by the
computer hardware industry..." - Henry Petroski
In article <cb**********@news-reader3.wanadoo.fr>, ja***@jacob.remcomp.fr
says... To the contrary of your expectations, I work to make a usable
compiler, not one that will please the purists around c.l.c
Jacob, if you ever (or already) support 64-bit AMD Opteron/AthlonFX or the
Intel clones of same, you're users are going to be in for a rude awakening
when they get to work porting. Yes, it may be so common on 32-bit platforms
for programmers to make assumptions that it *seems* like you're doing them
a favor to ignore it, in the long run, when people WILL be porting a lot
of legacy code to new platforms, it will be a hindrance, not a benefit.
--
Randy Howard (2reply remove FOOBAR)
"The most amazing achievement of the computer software industry is its
continuing cancellation of the steady and staggering gains made by the
computer hardware industry..." - Henry Petroski
In article <cb**********@news-reader1.wanadoo.fr>, ja***@jacob.remcomp.fr
says... "Harti Brandt" <br****@dlr.de> a écrit dans le message de
news:20*******************@beagle.kn.op.dlr.de... On Tue, 29 Jun 2004, jacob navia wrote:
That has nothing to do with purism. Ever cared to work on a machine where
sizeof(void *) > sizeof(int)?
In the next implementation of lcc-win32 that will be the case (64 bit
machine).
In THAT environment I will issue the warning for all pointer/int
conversions.
So people using your 32-bit compiler to develop code which will migrate
to 64 in the future will have to wait until later to be warned of possible
errors in their program. That's not a good idea.
In an environment where sizeof(int)==sizeof(void*) many people
(including me) write printf("pointer value=%#x\n",p); to debug
a piece of code.
You write this in new code? Why? I could understand you trying to
support legacy code through some sort of "shut up warnings about this"
mode, but not by default, and certainly don't understand writing new
code with a modern compiler as you describe.
The compiler spitting you hundreds of warnings
would only have the consequence of people IGNORING all warnings.
Strange, I try very hard to get my code to compile (on multiple platforms,
with varying compilers) with no warnings at all, using the highest warning
level on each compiler. It's not always possible, but I try very hard to
do so without bastardizing the source to get there. I have met programmers
that did ignore all warnings, but they were not around long enough in any
case to have a lasting impact.
It is a pity that people here like to have an atmosphere of
aggresivity that is very boring.
I didn't mean to be aggressive earlier, I think it was more *shock* than
animosity. I would have expected this discussion 10 years ago here, not
today, especially in light of the age of the standards that allow it to
be avoided, not to mention the 64-bit transitions currently very active
in a lot of places.
--
Randy Howard (2reply remove FOOBAR)
"The most amazing achievement of the computer software industry is its
continuing cancellation of the steady and staggering gains made by the
computer hardware industry..." - Henry Petroski
"Keith Thompson" <ks***@mib.org> a écrit dans le message de
news:ln************@nuthaus.mib.org... "jacob navia" <ja***@jacob.remcomp.fr> writes: The expression
printf("the address is: 0x%x\n",p);
where p is some pointer appears in several million lines in
existing code.
Then there are several million errors, and you'd be doing your users a
favor by letting them know.
If they set the debug level to high then yes. If not, the compiler
accepts it. I think this discussion has shown me that
maybe a warning is needed, if the programmer wishes.
lcc-win32 (as its name implies) is a 32 bit system. I am working
in the 64 bit version already, but that is another topic.
For example, on an IA-64 system:
#include <stdio.h>
int main(void)
{
char *p = "hello";
printf("Using %%x: p = 0x%x\n", p); /* wrong */
printf("Using %%p: p = %p\n", (void*)p); /* right */
return 0;
}
produces the following output:
Using %x: p = 0x7c0
Using %p: p = 0x40000000000007c0
Yes, this is one of the reasons I think a warning should be
issued if the programmer wishes. It helps porting code
from 32-->64 bits.
I suspect that platforms with 32-bit ints and 64-bit pointers are
going to become much more common over the next few years. The sooner
programmers realize that all the world's not a VAX^H^H^H x86, the
better. Even if the sizes happen to match, it's still undefined
behavior, and any number of things can go wrong.
Yes. I started porting the code and it is hard. Warnings like this
could improve the situation. In any case in the 64 bit system a warning
will be issued since sizeof(int) != sizeof(void *).
If you really want to make sure the address value is displayed in
hexadecimal, and you're willing to assume that pointers and ints are
the same size (e.g., you're writing a quick-and-dirty debugging
statement that will be deleted before the code could ever be ported to
another platform), you can always cast the pointer value to unsigned
int to inhibit the warning.
But this is just effort for throwaway code. Why bother?
Most of those printf statements are for situations where the
debugger is absent.
I started programming when this statements were the only
way of debugging since there wasn't any debugger.
And I wrote (to see if a pointer had a value) %x and was done
with it.
This has worked since a long time. Yes, I know about
%p, but I didn't bother. Why? It continued to work.
The result may or may not be meaningful,
but at least it avoids undefined behavior.
Or you can just use "%p", which exists for exactly this purpose.
Yes, I think I will be forced to write that in the 64 bit system.
I am wary of forcing casts to please the compiler... In a 32
bit system where sizeof void * is the same as sizeof int, this
warning has no sense really, and should be optional.
Do not clutter output. Filter it. Make more verbose
options available but choose a sensible default:
do not clutter...
"Randy Howard" <ra*********@FOOverizonBAR.net> a écrit dans le message de
news:MP************************@news.verizon.net.. . In article <cb**********@news-reader3.wanadoo.fr>, ja***@jacob.remcomp.fr
says... To the contrary of your expectations, I work to make a usable
compiler, not one that will please the purists around c.l.c
Jacob, if you ever (or already) support 64-bit AMD Opteron/AthlonFX or the
Intel clones of same, you're users are going to be in for a rude awakening
when they get to work porting. Yes, it may be so common on 32-bit
platforms for programmers to make assumptions that it *seems* like you're doing them
a favor to ignore it, in the long run, when people WILL be porting a lot
of legacy code to new platforms, it will be a hindrance, not a benefit.
Yes, I added an optional warning. If you want this (and other
warnings) you set higher warning level.
64 bit systems were never a succes, since at least a few
years. Many of them started but never become popular.
And I am sure that issues like %x or %p will be the least
of the problems I will face. Data size bloat, code size bloat...
64 bits is very expensive...
Need more than 4GB of memory recently?
If we bloat things that doesn't make them faster. Twice as
much data needs to be loaded, read-in, etc. This
doesn't make for very significant improvements. But this
is another topic.
"Arthur J. O'Dwyer" wrote:
[...] printf("the address is: 0x%x\n",p);
[...] printf("(%d) %p\n", p!=NULL, (void*)p);
[...] Who's been using "%d" or "%x" to print *pointer* values?
I have old legacy code, from before "%p" existed, with a similar construct.
However, it uses "%lx" and the cast "(long)ptr". This at least "works" on
systems where pointers are not bigger than longs. (Which is all platforms
for which it is currently ported to.)
--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody at spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
"jacob navia" <ja***@jacob.remcomp.fr> wrote: "Dan Pop" wrote: OTOH, lcc-win32 silently accepts printf("%d\n", "foo"), which is very
bad, considering the relative positions of the D and S keys on most
keyboard layouts (i.e. it is a fairly frequent mistake to type d
when you mean s).
I pondered a long time about that one, since it is perfectly legal to
do:
char *p;
...
printf("The address is %d\n",p);
No it isn't. Putting anything other than an int, or a type that promotes
to int, is undefined. (Having said that, you can of course make
your compiler define that behaviour. But this code is not portable
to other compilers).
specially in debugging code.
I always write standard code for debugging. Why take the risk
of having your debugging information come out wrong because you
did something undefined? When you're frustrated with some hard-to-find
bug, the last thing you need is the debugging to not work.
Granted, this is weird, but how to discriminate between
legal and wrong usage?
Legal usage adheres to the standard, wrong usage doesn't.
But maybe you are right. I added a warning when the "d" format
is used with a pointer.
The "x" format will NOT provoke any warnings.
Do you not know about %p ?
But this is at the limit of what a compiler can do.
This is all very much simpler than, say, writing a C++ compiler.
I'm sure you could even build a runtime check to match the
format string to the types of the arguments.
Harti Brandt wrote: %p is a quite new feature for printf().
You must have an interesting definition of "quite new" in that it
appeared in the 1989 standard and K&R 2.
Neither V7 nor BSD had this, so
the natural way of printing pointers was %x. Don't assume that everybody
out there does a daily update of it's compilers and libraries to the
current gcc.
One needn't have a daily update, just one from, oh, the last 10 years or
so.
Brian Rodenborn
"Default User" <fi********@boeing.com.invalid> a écrit dans le message de
news:40***************@boeing.com.invalid... Harti Brandt wrote:
%p is a quite new feature for printf().
You must have an interesting definition of "quite new" in that it
appeared in the 1989 standard and K&R 2.
Neither V7 nor BSD had this, so
the natural way of printing pointers was %x. Don't assume that everybody
out there does a daily update of it's compilers and libraries to the
current gcc.
One needn't have a daily update, just one from, oh, the last 10 years or
so.
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.
And the usage became an habit. It has been working since
more or less 20 years.
Is that a terrible sin?
Do not know. I am not a star programmer, neither the one
that never makes mistakes sorry.
Those printf statements never survived a lot anyway. Why
should I bother?
Is this extremely important?
Maybe. The fact that I check printf (as few compilers do
actually) is ignored, and an oversight is amplified.
In article <cb**********@news-reader2.wanadoo.fr>, ja***@jacob.remcomp.fr
says... Yes, I added an optional warning. If you want this (and other
warnings) you set higher warning level.
If your compiler supports the logical equivalent of gcc's -pedantic
it should be there by default. Perhaps also for whatever might
equate to -std=c89 or -std=c99.
64 bit systems were never a succes, since at least a few
years. Many of them started but never become popular.
I guess all of those new macintoshes I see people buying are a
failure. Apparently the very high volume of 64-bit AMD servers,
desktops and even notebooks now being sold are also a failure.
If you said "Itanium" I would be in agreement. In the first
year of general availability, x86_64 processors outsold Itanium
about 8:1, despite being to market 4 or 5 years later. 64-bit
is coming, and quickly, particularly on the server side, but also
the gamer kids are jumping on the bandwagon.
I have a 64-bit AMD notebook now, and it's wonderful, even when
running 32-bit windoze, but far more fun with SuSE 9.1 64-bit.
And I am sure that issues like %x or %p will be the least
of the problems I will face.
True. A lot of programmers, especially maintaining large WIN32
apps are having a hell of a time moving, because of all of the
MS data type proliferations that make really painful assumptions
about the sizes of things. If however you stick to the "portable
C sandbox", it's very, very painless. YMMV.
Data size bloat
Not necessarily, unsigned char's are still available. :-) So
are most of the other "smaller" data types. Fortunately, limits.h
has been around for a while, which helps considerably in this area.
code size bloat...
Minor in the grand scheme of things, but yes...
64 bits is very expensive...
Actually, 64-bit Opteron servers typically sell for about 1/2 of
a slower, less capable Xeon server. :-) (I know what you meant)
Need more than 4GB of memory recently?
Actually, yes. Not so much for myself, but because I needed to
write some code to stress memory above 4GB on IA-32 systems
that supported it via PAE. Not pretty. On 64-bit platforms,
it's unlikely I'll be around long enough to see a machine with
enough memory sticks to fill up the address space.
More typically, database programmers have been fighting this
problem for quite a while. If you really want to see an ugly
hack to get around this problem, go search for "AWE" and memory
on the MSDN website. Not pretty, but in a sense unavoidable
to get around 4GB on a 32-bit box.
More concretely, it's a daily issue for server development and
end users, where 4GB limitations on file sizes really suck when
you have a 2TB filesystem at your disposal, thanks to 32-bit
file offset issues. There are hacks to get around the problem of
course. The point is, it's not just about how much memory you have
installed.
If we bloat things that doesn't make them faster.
Taken at face value, that's true. It doesn't mean that a 64-bit
platform and software is automatically bloated without any
redeeming benefits. A fair amount of crypto code for example
can be shown to be much, much more efficient on 64-bit platforms,
but it's also true for quite a few other things. There are also
some major architectural benefits with the AMD 64-bit technology
such as Hypertransport, which flat out slay Intel FSB memory
designs on throughput, particularly in SMP implementation, which is
a big improvement as processor speed increases continue to outpace
memory performance in general.
Twice as much data needs to be loaded, read-in, etc.
And 64-bit designs are much better at loading in twice as much
data than 32-bit designs, pretty much across the board.
You might consider that people said almost the same thing (and
were proved wrong fairly quickly) when the 8 -> 16-bit transitions
and the 16 -> 32-bit transitions happened. No sense fighting
progress.
This doesn't make for very significant improvements.
Actually, it does, but it sounds as if you haven't had much experience
working on various 64-bit platforms yet, so it doesn't make much
sense to continue this until some later date when you have.
The main point still is that a compiler should support portability of code
compiled with it, not believe, wish, or otherwise pretend that it won't
happen.
--
Randy Howard (2reply remove FOOBAR)
"The most amazing achievement of the computer software industry is its
continuing cancellation of the steady and staggering gains made by the
computer hardware industry..." - Henry Petroski
"Randy Howard" <ra*********@FOOverizonBAR.net> a écrit dans le message de
news:MP************************@news.verizon.net.. . In article <cb**********@news-reader2.wanadoo.fr>, ja***@jacob.remcomp.fr
says...
but it sounds as if you haven't had much experience
working on various 64-bit platforms yet, so it doesn't make much
sense to continue this until some later date when you have.
I ported lcc-win32 to windows XP 64 bits.
Rewrote the assembler, the linker, adapted the debugger.
It is working, in an embryonic stage yet.
sizeof(void *) == 64, sizeof(int) == 32.
The best thing is not the 64 bit but *the EXTRA REGISTERS!!!*
8 new registers at last... The Intel architecture didn't saw that
for 20 years...
I think lcc-win32 will eventually migrate to
sizeof(void *) == 32, sizeof(int) 32
sizeof( __long void *) == 64, sizeof (long long) == 64.
For the few data items where you may need more than
4GB of addressing space a special pointer type would be more efficient
than putting all pointers in 64 bit carrying mostly
32 bits of zeroes around.
There is no free lunch. The complexity of having
two pointer types can become an obstacle.
I haven't decided yet which way to go.
In article <cb**********@news-reader5.wanadoo.fr>,
"jacob navia" <ja***@jacob.remcomp.fr> wrote: I think lcc-win32 will eventually migrate to
sizeof(void *) == 32, sizeof(int) 32
sizeof( __long void *) == 64, sizeof (long long) == 64.
Are you sure about that?
"Christian Bau" <ch***********@cbau.freeserve.co.uk> a écrit dans le message
de news:ch*********************************@slb-newsm1.svr.pol.co.uk... In article <cb**********@news-reader5.wanadoo.fr>,
"jacob navia" <ja***@jacob.remcomp.fr> wrote:
I think lcc-win32 will eventually migrate to
sizeof(void *) == 32, sizeof(int) 32
sizeof( __long void *) == 64, sizeof (long long) == 64.
Are you sure about that?
The rationale is that most programs do have a certain use of the
extra registers provided by the new architecture, but will never
need more than 4GB address range for most pointers.
Since 32 bit isntructions are smaller and the size of the
pointers in structures doesn't change, it becomes an
easy way to migrate the existing software base to 64 bits
without a lot of pain.
Nothing changes, you just have a new "long"
pointer type when you need it.
In the moment where the complexity of two pointers
types outweights the performance benefits this is
moot.
But I do not have implemented that yet. It is
a lot of work, much more than just following the
trend and using 64 bit pointers.
"jacob navia" <ja***@jacob.remcomp.fr> writes:
[...] lcc-win32 has several levels of warnings. After this discussion I have added
a warning when the warning level is higher than normal for all
implicit pointer/int conversions in the printf formats.
It's not really an implicit conversion. At best, it's a pointer
representation being interpreted as if it were an integer. The effect
is often identical, but it's best not to think of it as a "conversion".
Consider an analagous call:
printf("f = %d\n", f);
where f is of type float. There is no conversion from float to int,
just a float representation being interpreted as an int value. The
displayed value will most likely be garbage.
It happens that conversions between floats and integers typically have
to do an actual conversion to get the right value, while conversions
between pointers and integers typically just copy the bits. That's
why
printf("f = %d\n", some_float_value);
typically prints garbage, while
printf("p = 0x%x\n", some_pointer_value);
often gives you something that looks meaningful, but both are equally
undefined behavior, and both will fail badly on some real-world
systems.
I urge you to issue a warning for both cases at the default warning
level; if you want to provide some mechanism to inhibit certain
warnings, that's fine. (This is my opinion; the standard, of course,
doesn't require a warning in either case.) I also urge you to use "%p"
in your own 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.
jacob navia wrote:
"Default User" <fi********@boeing.com.invalid> a écrit dans le message de
news:40***************@boeing.com.invalid... Harti Brandt wrote:
%p is a quite new feature for printf().
You must have an interesting definition of "quite new" in that it
appeared in the 1989 standard and K&R 2.
One needn't have a daily update, just one from, oh, the last 10 years or
so.
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.
And the usage became an habit. It has been working since
more or less 20 years.
Is that a terrible sin?
As my reply was not to you, but to someone who maintained that %p was
some new invention, I don't know why you are whining to me. I don't give
a good goddamn why you choose not to use what the language provides.
Brian Rodenborn
Harti Brandt <br****@dlr.de> writes: On Tue, 29 Jun 2004, Arthur J. O'Dwyer wrote:
[...] AJO> Who's been using "%d" or "%x" to print *pointer* values?
%p is a quite new feature for printf(). Neither V7 nor BSD had this, so
the natural way of printing pointers was %x. Don't assume that everybody
out there does a daily update of it's compilers and libraries to the
current gcc.
It's not *that* new; it was introduced in the 1989 ANSI C standard, at
the same time prototypes were introduced. It did take several years
for ANSI C to catch on widely enough for "%p" to be considered
portable, but certainly any code written in the last decade or so
should use it.
--
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.
jacob navia <ja***@jacob.remcomp.fr> wrote: I think lcc-win32 will eventually migrate to
sizeof(void *) == 32, sizeof(int) 32
sizeof( __long void *) == 64, sizeof (long long) == 64.
For the few data items where you may need more than
4GB of addressing space a special pointer type would be more efficient
Do we have to expect the return of the dreaded far and near pointer
issues in a new disguise? Please tell me you don't even consider
something like that....
Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de
<Je***********@physik.fu-berlin.de> a écrit dans le message de
news:2k***********@uni-berlin.de... jacob navia <ja***@jacob.remcomp.fr> wrote: I think lcc-win32 will eventually migrate to
sizeof(void *) == 32, sizeof(int) 32
sizeof( __long void *) == 64, sizeof (long long) == 64.
For the few data items where you may need more than
4GB of addressing space a special pointer type would be more efficient
Do we have to expect the return of the dreaded far and near pointer
issues in a new disguise? Please tell me you don't even consider
something like that....
Well, if you do not want that, you should use all 64 bit
pointers. I will allow a switch for that since anyway I have
implemented a 64 bit only mode first.
A 32 bit mode with all pointers 32 bit by default is
more efficient in space and also in time for many applications.
This will not work very well if the added complexity doesn't justify
the performance gains. But for *many* existing and many
complex programs, a 64 bit pointer is an overkill and 32 bits
will suffice wonderfully. Not all software is handling big
database applications. Why carry all those zeroes around?
jacob navia wrote: The expression
printf("the address is: 0x%x\n",p);
where p is some pointer appears in several million lines in
existing code.
...
This simply means that authors of such code are in desperate need of
additional education in C programming (even though they might not
realize that). In this particular case the problem with the code is not
hypothetical, it is very real. Just consider what will happen on 64-bit
platform with 32-bit ints.
--
Best regards,
Andrey Tarasevich
"jacob navia" <ja***@jacob.remcomp.fr> writes: "Keith Thompson" <ks***@mib.org> a écrit dans le message de
news:ln************@nuthaus.mib.org...
[...] Then there are several million errors, and you'd be doing your users a
favor by letting them know.
If they set the debug level to high then yes. If not, the compiler
accepts it. I think this discussion has shown me that
maybe a warning is needed, if the programmer wishes.
In my opinion, the warning is needed whether the programmer asks for
it or not.
lcc-win32 (as its name implies) is a 32 bit system. I am working
in the 64 bit version already, but that is another topic.
The name also implies that it's a C compiler. In C, calling printf()
with a "%d" or "%x" format and a pointer argument invokes undefined
behavior.
[...]
Yes. I started porting the code and it is hard. Warnings like this
could improve the situation. In any case in the 64 bit system a warning
will be issued since sizeof(int) != sizeof(void *).
A call like
printf("p = 0x%x\n", some_pointer_value);
isn't correct on a 32-bit system and incorrect on a 64-bit system.
It's incorrect in C, regardless of the particular implementation; it
just happens to "work" on some 32-bit systems (or more generally, on
some, but not all, systems where ints and pointers happen to be the
same size).
[...] The result may or may not be meaningful,
but at least it avoids undefined behavior.
Or you can just use "%p", which exists for exactly this purpose.
Yes, I think I will be forced to write that in the 64 bit system.
Why wait?
I am wary of forcing casts to please the compiler... In a 32
bit system where sizeof void * is the same as sizeof int, this
warning has no sense really, and should be optional.
Your wariness about casts is appropriate. Arguments to printf() are
among the rare cases where they're necessary (the prototype doesn't
force an implicit conversion, so you need an explicit one). Even
passing a pointer argument for a "%p" format calls for a cast to void*
(though it's probably not strictly necessary for char*).
Do not clutter output. Filter it. Make more verbose
options available but choose a sensible default:
do not clutter...
A warning about incorrect code is not clutter.
--
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.
In article <cb**********@news-reader5.wanadoo.fr>,
"jacob navia" <ja***@jacob.remcomp.fr> wrote: "Christian Bau" <ch***********@cbau.freeserve.co.uk> a écrit dans le message
de news:ch*********************************@slb-newsm1.svr.pol.co.uk... In article <cb**********@news-reader5.wanadoo.fr>,
"jacob navia" <ja***@jacob.remcomp.fr> wrote:
I think lcc-win32 will eventually migrate to
sizeof(void *) == 32, sizeof(int) 32
sizeof( __long void *) == 64, sizeof (long long) == 64.
Are you sure about that?
The rationale is that most programs do have a certain use of the
extra registers provided by the new architecture, but will never
need more than 4GB address range for most pointers.
So why would you need sizeof (void *) == 32? Don't you think that 256
bit pointers are a bit excessive and 256 bit int is a bit much as well?
On Wed, 30 Jun 2004, jacob navia wrote:
<Je***********@physik.fu-berlin.de> a écrit... jacob navia <ja***@jacob.remcomp.fr> wrote: I think lcc-win32 will eventually migrate to
sizeof(void *) == 32, sizeof(int) 32
sizeof( __long void *) == 64, sizeof (long long) == 64.
Do we have to expect the return of the dreaded far and near pointer
issues in a new disguise? Please tell me you don't even consider
something like that....
Well, if you do not want that, you should use all 64 bit
pointers. I will allow a switch for that since anyway I have
implemented a 64 bit only mode first.
A 32 bit mode with all pointers 32 bit by default is
more efficient in space and also in time for many applications.
This will not work very well if the added complexity doesn't justify
the performance gains. But for *many* existing and many
complex programs, a 64 bit pointer is an overkill and 32 bits
will suffice wonderfully. Not all software is handling big
database applications. Why carry all those zeroes around?
I second Jens' comment. Have you had any experience with the
'far'/'near' morass? It's exactly isomorphic to your '__long'
proposal, except that 'far' and 'near' were dinosaurs of the
16-to-32-bit transition, and your proposal is a dinosaur of the
32-to-64-bit transition. It ought never to see the light of day.
(On the other hand, I don't think there's much real danger that
anyone will use lcc-win32 as their primary source-developing
platform, in the same way Borland[1] dominated many areas during the
last ice age. And I do have a perverse fascination with archaic
hacks like 'far'/'near'. So maybe I would prefer to see Jacob
struggle this one out... ;)
The "correct" solution, as far as I'm concerned, is to go ahead
and use 32-bit pointers whenever possible --- but *hide this fact
from the user*! That is, have only a single type 'void*', but let
it be 32 bits most of the time and 64 bits when necessary. If
it's too hard to figure out when 32 bits are truly sufficient, then
go the "memory model" route (which you already suggested as an
alternative). But steer clear of 'far' and 'near'!
-Arthur
[1] - It *was* "Turbo <PLOC>" that introduced 'far' and 'near',
wasn't it, and then Microsoft picked it up? Or was it invented
several times independently?
On Wed, 30 Jun 2004, Keith Thompson wrote:
"jacob navia" <ja***@jacob.remcomp.fr> writes:
[re: warning about 'printf("%d", cptr)'] If they set the debug level to high then yes. If not, the compiler
accepts it. I think this discussion has shown me that
maybe a warning is needed, if the programmer wishes.
In my opinion, the warning is needed whether the programmer asks for
it or not.
Especially for a reason Dan Pop pointed out twice, which seems to
have been ignored in all the 64-bit "clutter";) ...
char *p = "foo";
if (should_we_print_foo)
printf("%d\n", p);
Whoops! The programmer meant to type "%s", but his finger slipped
from the 's' to the adjacent 'd' key, and his program will have a
subtle bug. Not so subtle if "foo" is an important prompt, but
suppose "foo" is an error message that only appears during weekly
progress meetings? ;)
"Oh, that's no problem... I'll fix the typo and recompile," says
the programmer.
char *p = "foo";
if (should_we_print_foo)
printf("%x\n", p);
Whoops! Dang that 's' key --- this time I hit 'x' by mistake instead!
And again lcc-win32 conspires to hide my mistake.
This is a system of compiler diagnostics truly worthy of the DS9000,
if it will hide *only* those 'printf' errors which could conceivably
be typing mistakes! (I bet it warns about printf("%d") on a float,
or vice versa, though, so it's not yet perfect. ;)
-Arthur
"jacob navia" <ja***@jacob.remcomp.fr> writes:
[...] I think lcc-win32 will eventually migrate to
sizeof(void *) == 32, sizeof(int) 32
sizeof( __long void *) == 64, sizeof (long long) == 64.
Assuming that by sizeof(foo) you mean sizeof(foo)*CHAR_BIT ...
So you're not planning to allow code compiled by lcc-win32
(lcc-win64?) to interface easily to code compiled by other compilers?
Like, say, the operating system?
--
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.
"jacob navia" <ja***@jacob.remcomp.fr> wrote: In any case this discussion was positive for me (and lcc-win32).
I have been able to improve lcc-win32 a bit.
I hope you have the decency to credit comp.lang.c in your documentation
for any correct parts of that compiler.
Richard 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: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
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: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
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,...
| |
