Through Reddit I've seen another document that shows common little bugs in
C/C++ code found by a static analysis tool. The bugs shown seem to be real,
from real software:
http://www.slideshare.net/Andrey_Karpov/add2011-en
>From the slides I have selected seven of the bugs, here translated to D2:
bearophile wrote:
Through Reddit I've seen another document that shows common little bugs in
C/C++ code found by a static analysis tool. The bugs shown seem to be real,
from real software:
http://www.slideshare.net/Andrey_Karpov/add2011-en
From the slides I have selected seven of the bugs, her
Don:
> I would say that disallowing it would _always_ lead to clearer code.
OK. It's in Bugzilla since some time:
http://d.puremagic.com/issues/show_bug.cgi?id=5409
(But if we want to disallow something then we have to list exactly what syntax
are not allowed.)
> Making #7 an error would break
> Through Reddit I've seen another document that shows common little bugs in
> C/C++
code found by a static analysis tool. The bugs shown seem to be real, from real
software:
> http://www.slideshare.net/Andrey_Karpov/add2011-en
>
> From the slides I have selected seven of the bugs, here translated
Timon Gehr wrote:
>> - Bug #4 is probably easy to find, but in D is less common, because you >
>> usually
> use foreach, or for with local index variable (that D doesn't allow you to
> redefine). Once in > a while that kind of code is correct, maybe.
>
> This is already disallowed (deprecated).
O
Timon Gehr:
> The problem is that generated/CTFE'd code might produce that kind of
> redundancy.
Right.
> Proving that two sub-expressions are equivalent is a hard task.
A simple equivalence is enough here: the code with normalized whitespace. Those
tools are probably doing something not muc
> Timon Gehr:
>
>> The problem is that generated/CTFE'd code might produce that kind of
>> redundancy.
>
> Right.
>
>
>> Proving that two sub-expressions are equivalent is a hard task.
>
> A simple equivalence is enough here: the code with normalized whitespace.
> Those
tools are probably doing s
Timon Gehr:
> I think it might be a
> good idea though. However, having this feature means requiring one AST
> compare for
> every boolean operator.
You are worried about compilation time. I think the feature we're talking about
just tests the equivalence of the then/else clauses.
Clang has a
> Timon Gehr:
>
>> I think it might be a
>> good idea though. However, having this feature means requiring one AST
>> compare for
>> every boolean operator.
>
> You are worried about compilation time. I think the feature we're talking
> about
just tests the equivalence of the then/else clauses.
>
An interesting blog post found through Reddit:
http://randomascii.wordpress.com/2013/06/24/two-years-and-thousands-of-bugs-of-/
The post is about the heavy usage of static analysis on lot of
C++ code. They have a Python script that shows new warnings only
the first time they appear in the code
On Wed, Jun 26, 2013 at 08:08:08PM +0200, bearophile wrote:
> An interesting blog post found through Reddit:
>
> http://randomascii.wordpress.com/2013/06/24/two-years-and-thousands-of-bugs-of-/
[...]
> The most common problem they find are errors in the format string of
> printf-like functions (de
On Wednesday, 26 June 2013 at 18:08:10 UTC, bearophile wrote:
In D this is one case similar to variable shadowing, that the
compiler doesn't help you with:
this.z = z;
I'd argue that assigning something to itself is never useful.
On Wed, Jun 26, 2013 at 08:57:46PM +0200, Adam D. Ruppe wrote:
> On Wednesday, 26 June 2013 at 18:08:10 UTC, bearophile wrote:
> >In D this is one case similar to variable shadowing, that the
> >compiler doesn't help you with:
> >this.z = z;
>
> I'd argue that assigning something to itself
On Wednesday, 26 June 2013 at 18:54:17 UTC, H. S. Teoh wrote:
import std.stdio;
void main() {
size_t x = 10;
writefln("%d", x, x);
}
In a modern statically typed language I'd like such code to
give a compile-time error.
This looks like a bug to me. Please file one. :)
Not necessaril
On 6/26/13 11:08 AM, bearophile wrote:
On the other hand this D program prints just
"10" with no errors, ignoring the second x:
import std.stdio;
void main() {
size_t x = 10;
writefln("%d", x, x);
}
In a modern statically typed language I'd like such code to give a
compile-time error.
Actuall
Am 26.06.2013 21:07, schrieb Adam D. Ruppe:
On Wednesday, 26 June 2013 at 18:54:17 UTC, H. S. Teoh wrote:
import std.stdio;
void main() {
size_t x = 10;
writefln("%d", x, x);
}
In a modern statically typed language I'd like such code to
give a compile-time error.
This looks like a bug
Am 26.06.2013 21:33, schrieb Andrei Alexandrescu:
On 6/26/13 11:08 AM, bearophile wrote:
On the other hand this D program prints just
"10" with no errors, ignoring the second x:
import std.stdio;
void main() {
size_t x = 10;
writefln("%d", x, x);
}
In a modern statically typed language I'd lik
Am 26.06.2013 21:53, schrieb dennis luehring:
Am 26.06.2013 21:33, schrieb Andrei Alexandrescu:
On 6/26/13 11:08 AM, bearophile wrote:
On the other hand this D program prints just
"10" with no errors, ignoring the second x:
import std.stdio;
void main() {
size_t x = 10;
writefln("%d", x, x);
}
On Wed, Jun 26, 2013 at 09:07:30PM +0200, Adam D. Ruppe wrote:
> On Wednesday, 26 June 2013 at 18:54:17 UTC, H. S. Teoh wrote:
> >>import std.stdio;
> >>void main() {
> >>size_t x = 10;
> >>writefln("%d", x, x);
> >>}
> >>
> >>In a modern statically typed language I'd like such code to give
On Wednesday, 26 June 2013 at 20:06:43 UTC, H. S. Teoh wrote:
But if the format string is known at compile-time, and there are
extraneous arguments, then it should be a warning / error.
We can't do that in D today, unless we do a writefln!"fmt"(args)
in addition to writefln(fmt, args...);
tb
26-Jun-2013 22:52, H. S. Teoh пишет:
[snip]
Then throw in the array formatters %(...%), and D format strings will
totally blow C's stdio out of the water.
They are _range_ formatters. Hence infinitely more powerful :)
--
Dmitry Olshansky
On Thu, Jun 27, 2013 at 12:17:24AM +0400, Dmitry Olshansky wrote:
> 26-Jun-2013 22:52, H. S. Teoh пишет:
> [snip]
> >Then throw in the array formatters %(...%), and D format strings will
> >totally blow C's stdio out of the water.
> >
> They are _range_ formatters. Hence infinitely more powerful :)
On 6/26/13, Andrei Alexandrescu wrote:
> Actually this is good because it allows to customize the format string
> to print only a subset of available information (I've actually used this).
Note that this works:
writefln("%d", x, x);
But the following throws since v2.061:
writeln(format("%d", x
27-Jun-2013 00:24, H. S. Teoh пишет:
On Thu, Jun 27, 2013 at 12:17:24AM +0400, Dmitry Olshansky wrote:
26-Jun-2013 22:52, H. S. Teoh пишет:
[snip]
Then throw in the array formatters %(...%), and D format strings will
totally blow C's stdio out of the water.
They are _range_ formatters. Hence
Andrei Alexandrescu:
Actually this is good because it allows to customize the format
string to print only a subset of available information (I've
actually used this).
Your use case is a special case that breaks a general rule. That
behavour is surprising, and it risks hiding some information
Am Wed, 26 Jun 2013 22:13:29 +0200
schrieb "Adam D. Ruppe" :
> On Wednesday, 26 June 2013 at 20:06:43 UTC, H. S. Teoh wrote:
> > But if the format string is known at compile-time, and there are
> > extraneous arguments, then it should be a warning / error.
>
> We can't do that in D today, unless
On Wednesday, 26 June 2013 at 20:51:54 UTC, Marco Leise wrote:
So the compiler would eagerly turn arguments into compile-time
parameters and offer some trait to check if a particular
instantiation of writefln made 'fmt' a template argument ?
Yeah, something like that. Or making literals a diffe
Am 26.06.2013 20:52, schrieb H. S. Teoh:
On Wed, Jun 26, 2013 at 08:08:08PM +0200, bearophile wrote:
An interesting blog post found through Reddit:
http://randomascii.wordpress.com/2013/06/24/two-years-and-thousands-of-bugs-of-/
[...]
The most common problem they find are errors in the format
On Wed, Jun 26, 2013 at 11:47:32PM +0200, Paulo Pinto wrote:
> Am 26.06.2013 20:52, schrieb H. S. Teoh:
[...]
> >None of my C++ code uses iostream. I still find stdio.h more
> >comfortable to use, in spite of its many problems. One of the most
> >annoying features of iostream is the abuse of operat
On 6/26/2013 11:08 AM, bearophile wrote:
A simpler example:
enum INPUT_VALUE = 2;
void f(uint flags) {
if (flags | INPUT_VALUE) {}
}
I have just added it to Bugzilla:
http://d.puremagic.com/issues/show_bug.cgi?id=10480
We've discussed this one before. I oppose it, on grounds I added to
On 6/26/2013 2:47 PM, Paulo Pinto wrote:
I have been an adept of iostreams since day one and never understood why people
complain so much about them or the operator<< and operator>>
for that matter.
Even if you can get past the execrable look of it, it suffers from at least 3
terrible technica
On 6/26/2013 3:56 PM, Walter Bright wrote:
On 6/26/2013 2:47 PM, Paulo Pinto wrote:
I have been an adept of iostreams since day one and never understood why people
complain so much about them or the operator<< and operator>>
for that matter.
Even if you can get past the execrable look of it, i
On Wednesday, June 26, 2013 23:47:32 Paulo Pinto wrote:
> I have been an adept of iostreams since day one and never understood why
> people complain so much about them or the operator<< and operator>>
> for that matter.
I actually like them (particularly because I really don't like how primitive
On 06/27/2013 01:01 AM, Walter Bright wrote:
On 6/26/2013 3:56 PM, Walter Bright wrote:
On 6/26/2013 2:47 PM, Paulo Pinto wrote:
I have been an adept of iostreams since day one and never understood
why people
complain so much about them or the operator<< and operator>>
for that matter.
Even i
On 6/26/2013 4:48 PM, Timon Gehr wrote:
On 06/27/2013 01:01 AM, Walter Bright wrote:
On 6/26/2013 3:56 PM, Walter Bright wrote:
On 6/26/2013 2:47 PM, Paulo Pinto wrote:
I have been an adept of iostreams since day one and never understood
why people
complain so much about them or the operator<<
On 27/06/13 10:33, Walter Bright wrote:
On 6/26/2013 4:48 PM, Timon Gehr wrote:
On 06/27/2013 01:01 AM, Walter Bright wrote:
On 6/26/2013 3:56 PM, Walter Bright wrote:
On 6/26/2013 2:47 PM, Paulo Pinto wrote:
I have been an adept of iostreams since day one and never understood
why people
comp
On 6/26/13 1:50 PM, bearophile wrote:
Andrei Alexandrescu:
Actually this is good because it allows to customize the format string
to print only a subset of available information (I've actually used
this).
Your use case is a special case that breaks a general rule.
There's no special case he
On 6/26/13 1:31 PM, Andrej Mitrovic wrote:
On 6/26/13, Andrei Alexandrescu wrote:
Actually this is good because it allows to customize the format string
to print only a subset of available information (I've actually used this).
Note that this works:
writefln("%d", x, x);
But the following t
On 6/26/13 4:48 PM, Timon Gehr wrote:
On 06/27/2013 01:01 AM, Walter Bright wrote:
Oh, and the cake topper is IOStreams performs badly, too.
Yes, but that's just a default.
std::ios_base::sync_with_stdio(false);
std::cin.tie(0);
That's the least of iostreams' efficiency problems.
Andrei
On 6/26/13 2:47 PM, Paulo Pinto wrote:
Am 26.06.2013 20:52, schrieb H. S. Teoh:
On Wed, Jun 26, 2013 at 08:08:08PM +0200, bearophile wrote:
An interesting blog post found through Reddit:
http://randomascii.wordpress.com/2013/06/24/two-years-and-thousands-of-bugs-of-/
[...]
The most common p
On 6/27/13, Andrei Alexandrescu wrote:
> I think that's a bug in format that we need to fix.
Absolutely. We must remove informative error messages and implement
sloppy APIs in the standard library.
On 6/26/13 7:38 PM, Andrej Mitrovic wrote:
On 6/27/13, Andrei Alexandrescu wrote:
I think that's a bug in format that we need to fix.
Absolutely. We must remove informative error messages and implement
sloppy APIs in the standard library.
Apologies for the overly curt reply, which I have no
On 6/26/13 12:53 PM, dennis luehring wrote:
Am 26.06.2013 21:33, schrieb Andrei Alexandrescu:
On 6/26/13 11:08 AM, bearophile wrote:
On the other hand this D program prints just
"10" with no errors, ignoring the second x:
import std.stdio;
void main() {
size_t x = 10;
writefln("%d", x, x);
}
On Thursday, 27 June 2013 at 02:40:53 UTC, Andrei Alexandrescu
wrote:
You are wrong.
format has thrown exceptions with such code since v2.000 (that's
the year 2007). It's only in v2.061 that it has finally gotten an
informative error message in the exception it throws.
Forcing D's writef to
On 6/27/13, Andrei Alexandrescu wrote:
> Apologies for the overly curt reply, which I have now canceled. OK let's
> do this: aside from sarcasm, do you have good arguments to line up to
> back up your opinion?
format has thrown exceptions with such code since v2.000 (that's the
year 2007). It's o
On Wednesday, June 26, 2013 19:18:27 Andrei Alexandrescu wrote:
> On 6/26/13 1:50 PM, bearophile wrote:
> > Andrei Alexandrescu:
> >> Actually this is good because it allows to customize the format string
> >> to print only a subset of available information (I've actually used
> >> this).
> >
> >
On 6/26/2013 12:03 PM, H. S. Teoh wrote:
But yeah, that's bad practice and the compiler should warn about it. The
reason it doesn't, though, IIRC is because of generic code, where it
would suck to have to special-case when two template arguments actually
alias the same thing.
It can also occur
On 27/06/13 12:17, Andrei Alexandrescu wrote:
On 6/26/13 1:31 PM, Andrej Mitrovic wrote:
On 6/26/13, Andrei Alexandrescu wrote:
Actually this is good because it allows to customize the format string
to print only a subset of available information (I've actually used
this).
Note that this wor
On Thu, Jun 27, 2013 at 01:56:31PM +1000, Peter Williams wrote:
[...]
> While you're fixing it can you modify it so that the format string
> can specify the order in which the arguments are replaced? This is
> very important for i18n. I apologize if it can already do this but
> I was unable to fi
On 27/06/13 14:20, H. S. Teoh wrote:
On Thu, Jun 27, 2013 at 01:56:31PM +1000, Peter Williams wrote:
[...]
While you're fixing it can you modify it so that the format string
can specify the order in which the arguments are replaced? This is
very important for i18n. I apologize if it can alread
On 6/26/13 8:05 PM, Andrej Mitrovic wrote:
If you are the type of programmer who often tests their own code, why
are you passing more arguments than needed to format?
My point is they're needed.
Andrei
On 6/26/13 10:35 PM, Peter Williams wrote:
On 27/06/13 14:20, H. S. Teoh wrote:
On Thu, Jun 27, 2013 at 01:56:31PM +1000, Peter Williams wrote:
[...]
While you're fixing it can you modify it so that the format string
can specify the order in which the arguments are replaced? This is
very import
On 6/26/13 8:26 PM, Andrej Mitrovic wrote:
The way I see it, write/writef is primarily used for debugging and
benefits having some lax features, whereas format is used in more
heavy-duty work where it's important not to screw things up at the
call site.
Then I think all the more format should a
On 6/26/13 8:36 PM, Jonathan M Davis wrote:
On Wednesday, June 26, 2013 19:18:27 Andrei Alexandrescu wrote:
On 6/26/13 1:50 PM, bearophile wrote:
Andrei Alexandrescu:
Actually this is good because it allows to customize the format string
to print only a subset of available information (I've ac
On Wednesday, June 26, 2013 23:49:41 Andrei Alexandrescu wrote:
> The only point I'd negotiate would be to not throw with positional
> arguments, and throw with sequential arguments. All code that cares uses
> positional specifiers anyway.
That sounds like a good compromise.
- Jonathan M Davis
On Wednesday, June 26, 2013 23:47:15 Andrei Alexandrescu wrote:
> >>> That
> >>> behavour is surprising, and it risks hiding some information silently.
> >>
> >> Doesn't surprise me one bit.
> >
> > Well, it shocks most of us.
>
> I'm also not moved by argumentum ad populum.
ad populum obviousl
On 6/26/13 11:59 PM, Jonathan M Davis wrote:
On Wednesday, June 26, 2013 23:47:15 Andrei Alexandrescu wrote:
That
behavour is surprising, and it risks hiding some information silently.
Doesn't surprise me one bit.
Well, it shocks most of us.
I'm also not moved by argumentum ad populum.
a
On 6/26/13 11:59 PM, Jonathan M Davis wrote:
I'm just pointing out that ignoring what the majority
thinks is not necessarily a good idea.
Of course. In this case it is.
Andrei
On Thursday, 27 June 2013 at 02:25:54 UTC, Andrei Alexandrescu
wrote:
On 6/26/13 2:47 PM, Paulo Pinto wrote:
Am 26.06.2013 20:52, schrieb H. S. Teoh:
On Wed, Jun 26, 2013 at 08:08:08PM +0200, bearophile wrote:
An interesting blog post found through Reddit:
http://randomascii.wordpress.com/201
On Wednesday, 26 June 2013 at 22:56:41 UTC, Walter Bright wrote:
On 6/26/2013 2:47 PM, Paulo Pinto wrote:
I have been an adept of iostreams since day one and never
understood why people
complain so much about them or the operator<< and operator>>
for that matter.
Even if you can get past the
On Thursday, 27 June 2013 at 06:59:49 UTC, Jonathan M Davis wrote:
ad populum obviously isn't enough. But if we make a design
decision that
favors 1% of our user base and causes problems for the other
99%, then I think
that we've made a big mistake. And while having most everyone
disagree with
On Wednesday, 26 June 2013 at 22:04:39 UTC, H. S. Teoh wrote:
On Wed, Jun 26, 2013 at 11:47:32PM +0200, Paulo Pinto wrote:
Am 26.06.2013 20:52, schrieb H. S. Teoh:
[...]
>None of my C++ code uses iostream. I still find stdio.h more
>comfortable to use, in spite of its many problems. One of the
On Thursday, 27 June 2013 at 07:33:16 UTC, Paulo Pinto wrote:
On Wednesday, 26 June 2013 at 22:56:41 UTC, Walter Bright wrote:
On 6/26/2013 2:47 PM, Paulo Pinto wrote:
I have been an adept of iostreams since day one and never
understood why people
complain so much about them or the operator<<
On Thursday, 27 June 2013 at 02:17:09 UTC, Andrei Alexandrescu
wrote:
On 6/26/13 1:31 PM, Andrej Mitrovic wrote:
On 6/26/13, Andrei Alexandrescu
wrote:
Actually this is good because it allows to customize the
format string
to print only a subset of available information (I've
actually used th
On Wednesday, 26 June 2013 at 18:08:10 UTC, bearophile wrote:
[cut]
The most common problem they find are errors in the format
string of printf-like functions (despite the code is C++):
The top type of bug that /analyze finds is format string errors
– mismatches between printf-style format str
On Wednesday, 26 June 2013 at 20:50:03 UTC, bearophile wrote:
If you want a special behavour you should use a special
function as partialWritefln that ignores arguments not present
in the format string.
Or maybe just define a new format specifier (%z, for 'zap'?) to
ignore one or more argumen
Jonathan M Davis:
Andrei Alexandrescu:
The only point I'd negotiate would be to not throw with
positional arguments, and throw with sequential arguments.
All code that cares uses positional specifiers anyway.
That sounds like a good compromise.
OK :-)
Bye,
bearophile
On Thursday, 27 June 2013 at 06:59:49 UTC, Jonathan M Davis wrote:
But if we make a design decision that favors 1% of our userbase
I really think we all need to be more careful about these kinds
of statements. I often see posts on the newsgroup where someone
says "feature/function X is totall
On 6/27/13, Andrei Alexandrescu wrote:
> NO! This is exactly the kind of code that is buggy and useless. The
> right use cases involve more arguments than format specifiers.
I mistyped that, I meant:
format("%s", 1, 2); // no exceptions in future release
safeFormat("%s", 1, 2); // exception th
On Thursday, 27 June 2013 at 13:11:55 UTC, Andrej Mitrovic wrote:
I mistyped that, I meant:
format("%s", 1, 2); // no exceptions in future release
safeFormat("%s", 1, 2); // exception thrown
I think if there's going to be a new function anyway, it might as
well be more like the ctFormat bea
On 6/27/13, Andrej Mitrovic wrote:
> On 6/27/13, Andrei Alexandrescu wrote:
>> NO! This is exactly the kind of code that is buggy and useless. The
>> right use cases involve more arguments than format specifiers.
>
> I mistyped that, I meant:
>
> format("%s", 1, 2); // no exceptions in future re
On 6/27/13, Adam D. Ruppe wrote:
> I think if there's going to be a new function anyway, it might as
> well be more like the ctFormat bearophile mentioned, and check it
> at compile time.
Yeah but it's not always possible to know what the formatting string
is. For example, maybe you have an enum
Andrej Mitrovic:
Yeah but it's not always possible to know what the formatting
string
is. For example, maybe you have an enum array of format strings
but a
runtime index into this array which you pass to format at
runtime.
I've ported C samples before that used this style of formatting.
In
On 06/27/13 13:16, Nicolas Sicard wrote:
> On Wednesday, 26 June 2013 at 20:50:03 UTC, bearophile wrote:
>> If you want a special behavour you should use a special function as
>> partialWritefln that ignores arguments not present in the format string.
>
> Or maybe just define a new format specifi
Andrei Alexandrescu:
But the bottom line is I don't think we need to force anything
on anybody. If anything, we could split up the internal format
implementation and provide format and safeFormat functions.
format("%s %s", 1); // no exceptions
NO! This is exactly the kind of code that is bu
On Thursday, 27 June 2013 at 19:22:08 UTC, bearophile wrote:
(also why is it 1-based?):
It is specified that way in the Single Unix Specification for
format strings.
I'm not sure why they did it that way, but if we changed it, that
would be surprising since the format string is otherwise si
On Thursday, June 27, 2013 13:47:53 Adam D. Ruppe wrote:
> On Thursday, 27 June 2013 at 06:59:49 UTC, Jonathan M Davis wrote:
> > But if we make a design decision that favors 1% of our userbase
>
> I really think we all need to be more careful about these kinds
> of statements. I often see posts o
On 27/06/13 23:33, bearophile wrote:
Andrej Mitrovic:
Yeah but it's not always possible to know what the formatting string
is. For example, maybe you have an enum array of format strings but a
runtime index into this array which you pass to format at runtime.
I've ported C samples before that u
On 28/06/13 05:52, Jonathan M Davis wrote:
On Thursday, June 27, 2013 13:47:53 Adam D. Ruppe wrote:
On Thursday, 27 June 2013 at 06:59:49 UTC, Jonathan M Davis wrote:
But if we make a design decision that favors 1% of our userbase
I really think we all need to be more careful about these kind
On Friday, June 28, 2013 10:44:36 Peter Williams wrote:
> On 28/06/13 05:52, Jonathan M Davis wrote:
> > On Thursday, June 27, 2013 13:47:53 Adam D. Ruppe wrote:
> >> On Thursday, 27 June 2013 at 06:59:49 UTC, Jonathan M Davis wrote:
> >>> But if we make a design decision that favors 1% of our user
On 28/06/13 11:47, Jonathan M Davis wrote:
On Friday, June 28, 2013 10:44:36 Peter Williams wrote:
On 28/06/13 05:52, Jonathan M Davis wrote:
On Thursday, June 27, 2013 13:47:53 Adam D. Ruppe wrote:
On Thursday, 27 June 2013 at 06:59:49 UTC, Jonathan M Davis wrote:
But if we make a design dec
On 6/27/2013 8:22 PM, Peter Williams wrote:
Yes, but voting is very seldom the best way so decide a technical issue. You
want the best technical solution not the one supported by the best lobbyists.
A sound technical argument can trump votes. There are enough cases of votes
overriding technic
On Friday, June 28, 2013 00:48:20 Walter Bright wrote:
> On 6/27/2013 8:22 PM, Peter Williams wrote:
> > Yes, but voting is very seldom the best way so decide a technical issue.
> > You want the best technical solution not the one supported by the best
> > lobbyists.
> A sound technical argument c
83 matches
Mail list logo
