www.digitalmars.com         C & C++   DMDScript  

D - printf safety

reply "Matthew Wilson" <dmd synesis.com.au> writes:
In light of today's discussion of the regarding the type-safe printf, I got
to wondering about whether using printf is as dangerous as it's cracked up
to be.

I am pretty confident that the only printf mistakes I've made this year are
in writing code that deals with 64-bit ints, which (for C/C++) use either
%I64d or %lld formats. Since I primarily use Intel 7/7.1 plugged into Visual
Studio 98, the Intel compiler picks up anything else for me.

I don't think I'm uniquely gifted in using printf, so I wonder whether we'd
be best served by just boosting the D compiler's analysis of printf
arguments to at least the competency of the Intel compiler.

Thoughts?
Nov 06 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:bodh54$agt$1 digitaldaemon.com...
 In light of today's discussion of the regarding the type-safe printf, I

 to wondering about whether using printf is as dangerous as it's cracked up
 to be.

 I am pretty confident that the only printf mistakes I've made this year

 in writing code that deals with 64-bit ints, which (for C/C++) use either
 %I64d or %lld formats. Since I primarily use Intel 7/7.1 plugged into

 Studio 98, the Intel compiler picks up anything else for me.

 I don't think I'm uniquely gifted in using printf, so I wonder whether

 be best served by just boosting the D compiler's analysis of printf
 arguments to at least the competency of the Intel compiler.

 Thoughts?

While everyone is correct in that printf is certainly not typesafe, I have rarely had any problems with it.
Nov 06 2003
parent Sarat Venugopal <sarat removeme.huelix.com> writes:
Walter wrote:
 While everyone is correct in that printf is certainly not typesafe, I have
 rarely had any problems with it.

Well, you are hardly the typical user. :-) Cheers, Sarat
Nov 07 2003
prev sibling next sibling parent "Charles Sanders" <sanders-consulting comcast.net> writes:
I don't think I've ever had a problem with printf, not that I can remember.

C


"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:bodh54$agt$1 digitaldaemon.com...
 In light of today's discussion of the regarding the type-safe printf, I

 to wondering about whether using printf is as dangerous as it's cracked up
 to be.

 I am pretty confident that the only printf mistakes I've made this year

 in writing code that deals with 64-bit ints, which (for C/C++) use either
 %I64d or %lld formats. Since I primarily use Intel 7/7.1 plugged into

 Studio 98, the Intel compiler picks up anything else for me.

 I don't think I'm uniquely gifted in using printf, so I wonder whether

 be best served by just boosting the D compiler's analysis of printf
 arguments to at least the competency of the Intel compiler.

 Thoughts?

Nov 06 2003
prev sibling next sibling parent reply "Luna Kid" <lunakid neuropolis.org> writes:
"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:bodh54$agt$1 digitaldaemon.com...
 In light of today's discussion of the regarding the type-safe printf, I got
 to wondering about whether using printf is as dangerous as it's cracked up
 to be.

 I am pretty confident that the only printf mistakes I've made this year are
 in writing code that deals with 64-bit ints, which (for C/C++) use either
 %I64d or %lld formats. Since I primarily use Intel 7/7.1 plugged into Visual
 Studio 98, the Intel compiler picks up anything else for me.

 I don't think I'm uniquely gifted in using printf, so I wonder whether we'd
 be best served by just boosting the D compiler's analysis of printf
 arguments to at least the competency of the Intel compiler.

 Thoughts?

"Charles Sanders" <sanders-consulting comcast.net> wrote in message news:boebh7$1icq$1 digitaldaemon.com...
 I don't think I've ever had a problem with printf, not that I can remember.

 C

I also agree that compiler errors on printf-misuse might be enough to save the day, especially if that would be a required language feature, not just the niceness of a compiler. (However, I'd still miss typesafe varargs, I think. OTOH, I suspect that with typesafe vararg, we'd end up having similar overhead as with the C++ << >> stuff. (I don't say this because I have feelings either pro or contra about the C++ approach; I just think that's probably the best compromise C++ could afford.) Later, Sz.
Nov 06 2003
next sibling parent "Luna Kid" <lunakid neuropolis.org> writes:
 about the C++ approach; I just think that's probably the
 best compromise C++ could afford.)

(Just to make it clear: good compromise in terms of type-safety / performance + syntax. Regarding formatting, it's a poor one.) Mr. X.
Nov 07 2003
prev sibling parent Sarat Venugopal <sarat removeme.huelix.com> writes:
[...]

 (However, I'd still miss typesafe varargs, I think. OTOH,
 I suspect that with typesafe vararg, we'd end up having
 similar overhead as with the C++ << >> stuff. (I don't
 say this because I have feelings either pro or contra
 about the C++ approach; I just think that's probably the
 best compromise C++ could afford.)

Streams are a powerful abstraction. I hope some serious work goes into current streams.d. The overhead is probably justified in this context. Same with type-safety. It is certainly possible to write robust code without strong type checking. only harder - especially for the majority of the users. It'll be faster not to check array bounds, not use smart pointers, not use GCs.....ad infinitum. Ultimately robust code ends up checking every one of these manually, often with more overhead. printf(...) is no real substitute for full featured streams and is unaware of objects. IMHO, Sarat Venugopal
Nov 07 2003
prev sibling next sibling parent Ilya Minkov <midiclub tiscali.de> writes:
I can *never* remember the flags. I have to look them up every time. 
It's really not very convenient for users which have little experience 
with C. I myself have switched to C++ right within a couple of months 
after having learned C. And we will hopefully have users switching to D 
from Delphi, Java and C#.

Matthew Wilson wrote:
 In light of today's discussion of the regarding the type-safe printf, I got
 to wondering about whether using printf is as dangerous as it's cracked up
 to be.

In C, it's usable. In D, it's dangerous and even more stupid. We have had Burton's typesafe printf, which doesn't necessarily requiere or could check type specification. It simply accepted an own kind of a discriminated union, which would contain the original type or its string conversion. A more elegant solution could be based on inheritance. While everyone is talking of typesafe varargs, they are actually quite easy to make by yourself. Maybe compiler could support automatic box-type generation?
 I don't think I'm uniquely gifted in using printf, so I wonder whether we'd
 be best served by just boosting the D compiler's analysis of printf
 arguments to at least the competency of the Intel compiler.

You are just protecting your old habits. ;) After 10 years of extensive printeffing :> everyone would probably become a printf wizard, knowing binary layouts of each struct in their program by heart, and thus being able to elegantly output it using printf. :>>>>>>> Thus making his code also quite immune against reverse engineering. :) Probably printf is not the most important skill in the world, so i would say we should free new users of it. I cannot say that i approve the C++ iostrams completely, but they made a step into the right direction, allowing to use them easily for usual stuff. For unusual stuff, like formatting, these modifiers get really awkward, it could be solved in a more lightweight manner. But that's actually the only complaint against a ton which i have towards C output and especially the input!!! -eye
Nov 07 2003
prev sibling parent reply davepermen <davepermen_member pathlink.com> writes:
first: there should be no special printf compiler feature required to make
printf typesave. this is hackish, premature fixing of something that could get
fixed in a general, reusable way (like streams in c++ are).

the other problem is forgotten often: because of the lack of typesavety, there
is as well lack of type determination and due that, type support AT ALL. there
is no way to get printf to take my custom vec3 struct, or my Window class, or
what EVER and print it out correctly. THAT is possible with streams in c++,
too..

we should not forget this. streams in c++ can ALL get extended to support
arbitary types. printf only knows some string variants, some int variants, and
some float variants.

i for myself are completely with the opCall idea, as i've done this in c++
myself, thinking its a very clean way. it is, as well, a very reusable way..
think of this:

class MyObj {
void serialize(ISerializer serializer) {
serializer(this.foo)(this.bar)(this.foobar)(this.whatever);
}
}

MyObj obj = new MyObj;
obj.serialize(new TextFileLoader("obj.txt"));
obj.serialize(new BinaryFileWriter("obj.data"));


this is something the << and >> in c++ doesn't directly support..


(yes, this could be directly done with opCall and not serialize.. but i've just
thought of the general messy way to actually DO serialization to highlight that
here with the proper naming)


then again, to make it really extendable, operators should not be member
functions.. that way, we could just write..

ISerializer opCall(ISerializer me,vec3 v) {
return me(v.x)(v.y)(v.z);
}

and done.. or so..



oh, and about the very stupid discussion about ("\n") or (endl) or .nl() or what
ever bullshit.. how about... (\n) ? this works! \n is a special char you can
use. short, clean, simple.. we just need opCall(char chr)
Nov 07 2003
parent Sarat Venugopal <sarat removeme.huelix.com> writes:
davepermen wrote:
[...]

 oh, and about the very stupid discussion about ("\n") or (endl) or .nl() or
what
 ever bullshit.. how about... (\n) ? this works! \n is a special char you can
 use. short, clean, simple.. we just need opCall(char chr)

Maybe. The good thing about .nl() is that it is an abstraction of newline (may be your (\n) can be too...). On Windows "\r\n", "\n" on POSIX, and so on (Is it "\r" on Mac?). Cheers, Sarat Venugopal
Nov 07 2003