On Friday, 19 May 2017 at 23:56:55 UTC, Dominikus Dittes Scherkl
wrote:
On Friday, 19 May 2017 at 22:06:59 UTC, Moritz Maxeiner wrote:
On Friday, 19 May 2017 at 20:54:40 UTC, Dominikus Dittes
Scherkl wrote:
I take this to mean the programmer who wrote the library, not
every user of the
On Friday, 19 May 2017 at 22:06:59 UTC, Moritz Maxeiner wrote:
On Friday, 19 May 2017 at 20:54:40 UTC, Dominikus Dittes
Scherkl wrote:
I take this to mean the programmer who wrote the library, not
every user of the library.
I take this to mean any programmer that ends up compiling it
(if
On Friday, 19 May 2017 at 20:54:40 UTC, Dominikus Dittes Scherkl
wrote:
On Friday, 19 May 2017 at 20:19:46 UTC, Moritz Maxeiner wrote:
On Friday, 19 May 2017 at 17:21:23 UTC, Dominikus Dittes
Scherkl wrote:
You cannot promise to the compiler that the code is memory
safe since you have no
On Friday, 19 May 2017 at 20:19:46 UTC, Moritz Maxeiner wrote:
On Friday, 19 May 2017 at 17:21:23 UTC, Dominikus Dittes
Scherkl wrote:
You cannot promise to the compiler that the code is memory
safe since you have no knowledge of what it actually does.
No. @trusted is about trust: you cannot
On Friday, 19 May 2017 at 17:21:23 UTC, Dominikus Dittes Scherkl
wrote:
On Friday, 19 May 2017 at 15:52:52 UTC, Moritz Maxeiner wrote:
On Friday, 19 May 2017 at 15:12:20 UTC, Steven Schveighoffer
I don't expect people to use Phobos and audit all the
@trusted blocks personally.
As long as
On Friday, 19 May 2017 at 15:52:52 UTC, Moritz Maxeiner wrote:
On Friday, 19 May 2017 at 15:12:20 UTC, Steven Schveighoffer
I don't expect people to use Phobos and audit all the @trusted
blocks personally.
As long as they don't actually call them, that's reasonable.
But if your application
On 5/19/17 12:29 PM, Timon Gehr wrote:
On 19.05.2017 17:12, Steven Schveighoffer wrote:
I mean libraries which only contain @safe and @system calls.
i.e.:
$ grep -R '@trusted' libsafe | wc -l
0
mixin("@"~"trusted void nasty(){ corruptAllTheMemory(); }");
Yeah. There's that. But I think
On Friday, 19 May 2017 at 16:29:59 UTC, Timon Gehr wrote:
On 19.05.2017 17:12, Steven Schveighoffer wrote:
I mean libraries which only contain @safe and @system calls.
i.e.:
$ grep -R '@trusted' libsafe | wc -l
0
mixin("@"~"trusted void nasty(){ corruptAllTheMemory(); }");
dmd -vcg-ast
On 19.05.2017 17:12, Steven Schveighoffer wrote:
I mean libraries which only contain @safe and @system calls.
i.e.:
$ grep -R '@trusted' libsafe | wc -l
0
mixin("@"~"trusted void nasty(){ corruptAllTheMemory(); }");
On Friday, 19 May 2017 at 15:12:20 UTC, Steven Schveighoffer
wrote:
On 5/19/17 9:46 AM, Moritz Maxeiner wrote:
On Friday, 19 May 2017 at 11:53:57 UTC, Steven Schveighoffer
wrote:
This provides a foundation to build completely @safe
libraries.
Agreed if you mean libraries being marked
On 5/19/17 9:46 AM, Moritz Maxeiner wrote:
On Friday, 19 May 2017 at 11:53:57 UTC, Steven Schveighoffer wrote:
This provides a foundation to build completely @safe libraries.
Agreed if you mean libraries being marked completely as @safe (which I
assume).
Disagreed if you mean libraries that
On Friday, 19 May 2017 at 11:53:57 UTC, Steven Schveighoffer
wrote:
On 5/19/17 5:12 AM, Moritz Maxeiner wrote:
On Thursday, 18 May 2017 at 12:12:18 UTC, Steven Schveighoffer
wrote:
[...]
We still allow unsafe operations inside @safe code, using
@trusted.
This is a necessary evil, but it's so
On 5/19/17 5:12 AM, Moritz Maxeiner wrote:
On Thursday, 18 May 2017 at 12:12:18 UTC, Steven Schveighoffer wrote:
[...]
We still allow unsafe operations inside @safe code, using @trusted.
This is a necessary evil, but it's so very important that the base
libraries (druntime and phobos) keep
On Thursday, 18 May 2017 at 18:15:28 UTC, Stanislav Blinov wrote:
On Thursday, 18 May 2017 at 17:53:52 UTC, H. S. Teoh wrote:
In the long run, I fear that if there are too many @trusted
blocks in a given codebase (not necessarily Phobos), it will
become too onerous to review, and could lead
On Thursday, 18 May 2017 at 12:12:18 UTC, Steven Schveighoffer
wrote:
[...]
We still allow unsafe operations inside @safe code, using
@trusted. This is a necessary evil, but it's so very important
that the base libraries (druntime and phobos) keep this to a
minimum, and that we review those
On 5/18/2017 10:53 AM, H. S. Teoh via Digitalmars-d wrote:
Yes, and that is why it's a grave concern that Phobos has (or used to
have) giant blocks of code under the heading `@trusted:`. Even entire
functions marked @trusted are a concern, to me, if the function is more
than 5-10 lines long.
On Thursday, 18 May 2017 at 17:53:52 UTC, H. S. Teoh wrote:
In the long run, I fear that if there are too many @trusted
blocks in a given codebase (not necessarily Phobos), it will
become too onerous to review, and could lead to hidden exploits
that are overlooked by reviewers. I don't know
On Thu, May 18, 2017 at 08:12:18AM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
[...]
> Of course. But what business people would see is a huge company like
> facebook being marginalized by a small startup, and having the
> analysts say "well, it's mostly because they used Rust/D". The
On 5/18/17 12:40 AM, H. S. Teoh via Digitalmars-d wrote:
On Wed, May 17, 2017 at 08:58:31PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
On 5/17/17 8:27 PM, H. S. Teoh via Digitalmars-d wrote:
[...]
What will cause a shift is a continuous business loss.
If business A and B are
On Thursday, 18 May 2017 at 08:24:18 UTC, Walter Bright wrote:
On 5/17/2017 10:07 PM, Patrick Schluter wrote:
D requires afaict at least a 32 bit system
Yes.
You've said this some times before but never explained why
there's such a limitation? I've actually used GDC to run code on
8bit
On Thursday, 18 May 2017 at 08:24:18 UTC, Walter Bright wrote:
On 5/17/2017 10:07 PM, Patrick Schluter wrote:
D requires afaict at least a 32 bit system
Yes.
What are the technical limitations of this?
*LLVM has 16bit targets
*Nobody would use druntime on 16bit anyway and would not generate
On 5/17/2017 10:07 PM, Patrick Schluter wrote:
D requires afaict at least a 32 bit system
Yes.
with virtual memory,
No.
On Thursday, 18 May 2017 at 06:36:55 UTC, Paulo Pinto wrote:
On Thursday, 18 May 2017 at 05:07:38 UTC, Patrick Schluter
wrote:
On Thursday, 18 May 2017 at 00:58:31 UTC, Steven Schveighoffer
wrote:
On 5/17/17 8:27 PM, H. S. Teoh via Digitalmars-d wrote:
[...]
What will cause a shift is a
On Thursday, 18 May 2017 at 00:58:31 UTC, Steven Schveighoffer
wrote:
On 5/17/17 8:27 PM, H. S. Teoh via Digitalmars-d wrote:
[...]
What will cause a shift is a continuous business loss.
If business A and B are competing in the same space, and
business A has a larger market share, but
On Thursday, 18 May 2017 at 05:07:38 UTC, Patrick Schluter wrote:
On Thursday, 18 May 2017 at 00:58:31 UTC, Steven Schveighoffer
wrote:
On 5/17/17 8:27 PM, H. S. Teoh via Digitalmars-d wrote:
[...]
What will cause a shift is a continuous business loss.
If business A and B are competing in
On Wed, 2017-05-17 at 17:27 -0700, H. S. Teoh via Digitalmars-d wrote:
> […]
> odds are heavily stacked against a language change. Most management
> are
> concerned (and in many cases, rightly so) about the cost of rewriting
> decades-old "proven" software as opposed to merely plugging the holes
>
On Thursday, 18 May 2017 at 00:58:31 UTC, Steven Schveighoffer
wrote:
On 5/17/17 8:27 PM, H. S. Teoh via Digitalmars-d wrote:
On Wed, May 17, 2017 at 04:16:59PM -0700, Walter Bright via
Digitalmars-d wrote:
On 5/17/2017 1:46 PM, H. S. Teoh via Digitalmars-d wrote:
[...]
It may not be the
On Wednesday, 17 May 2017 at 20:41:43 UTC, Walter Bright wrote:
On 5/17/2017 3:21 AM, Joakim wrote:
Hmm, this talk has become the most-viewed from this DConf, by
far beating
Scott's keynote. Wonder how, as this seems to be the only
link to it, hasn't
been posted on reddit/HN. I guess people
On Wed, May 17, 2017 at 08:58:31PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
> On 5/17/17 8:27 PM, H. S. Teoh via Digitalmars-d wrote:
[...]
> What will cause a shift is a continuous business loss.
>
> If business A and B are competing in the same space, and business A
> has a larger
On 5/17/17 8:27 PM, H. S. Teoh via Digitalmars-d wrote:
On Wed, May 17, 2017 at 04:16:59PM -0700, Walter Bright via Digitalmars-d wrote:
On 5/17/2017 1:46 PM, H. S. Teoh via Digitalmars-d wrote:
People aren't willing to accept that their cherished choice of
language may have been the wrong
On Wed, May 17, 2017 at 04:16:59PM -0700, Walter Bright via Digitalmars-d wrote:
> On 5/17/2017 1:46 PM, H. S. Teoh via Digitalmars-d wrote:
> > People aren't willing to accept that their cherished choice of
> > language may have been the wrong one, especially if they have
> > invested much of
On 5/17/2017 1:46 PM, H. S. Teoh via Digitalmars-d wrote:
People aren't willing to accept that their cherished choice of language
may have been the wrong one, especially if they have invested much of
their lives in mastering said language.
It may not be the developers that initiate this
On Wed, May 17, 2017 at 01:41:43PM -0700, Walter Bright via Digitalmars-d wrote:
> On 5/17/2017 3:21 AM, Joakim wrote:
> > Hmm, this talk has become the most-viewed from this DConf, by far
> > beating Scott's keynote. Wonder how, as this seems to be the only
> > link to it, hasn't been posted on
On 5/17/2017 3:21 AM, Joakim wrote:
Hmm, this talk has become the most-viewed from this DConf, by far beating
Scott's keynote. Wonder how, as this seems to be the only link to it, hasn't
been posted on reddit/HN. I guess people like panels, the process panel last
year is one of the most viewed
On Friday, 12 May 2017 at 18:52:43 UTC, Joakim wrote:
On Saturday, 6 May 2017 at 09:53:52 UTC, qznc wrote:
On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote:
[...]
Hm, Sociomantic removes the live captures the next day?
One request: Chop the panel discussion into one clip per
On 5/16/2017 10:29 AM, Steven Schveighoffer wrote:
1 week later: WanaCry. Both Walter and WanaCry start with W. Hm
No need to breed mosquitos to promote a cure for malaria :-)
On 5/16/17 11:19 AM, Walter Bright wrote:
On 5/5/2017 11:26 PM, Joakim wrote:
Walter: I believe memory safety will kill C.
I can't find any definitive explanation of what the Wannacry exploit is.
One person told me it was an overflow bug, another that it was
truncation from converting 32 to
On Tuesday, 16 May 2017 at 15:19:54 UTC, Walter Bright wrote:
On 5/5/2017 11:26 PM, Joakim wrote:
Walter: I believe memory safety will kill C.
I can't find any definitive explanation of what the Wannacry
exploit is. One person told me it was an overflow bug, another
that it was truncation
On 5/5/2017 11:26 PM, Joakim wrote:
Walter: I believe memory safety will kill C.
I can't find any definitive explanation of what the Wannacry exploit is. One
person told me it was an overflow bug, another that it was truncation from
converting 32 to 16 bits.
Anyhow, the Wannacry disaster
On Sunday, 14 May 2017 at 21:01:40 UTC, Jack Stouffer wrote:
On Sunday, 14 May 2017 at 10:10:41 UTC, Dibyendu Majumdar wrote:
b) If you want to do things that C allows you to do, then Rust
is no more safer than C.
That's the entire bloody point isn't it? Maybe you shouldn't be
doing a lot of
On Sunday, 14 May 2017 at 21:01:40 UTC, Jack Stouffer wrote:
On Sunday, 14 May 2017 at 10:10:41 UTC, Dibyendu Majumdar wrote:
b) If you want to do things that C allows you to do, then Rust
is no more safer than C.
That's the entire bloody point isn't it? Maybe you shouldn't be
doing a lot of
On Sunday, 14 May 2017 at 10:10:41 UTC, Dibyendu Majumdar wrote:
In real terms though tools like ASAN and Valgrind if used from
the start usually allow you to catch most of the issues. Most
likely even better tools for C will come about in time.
See Walter's comment earlier in this thread and
On Sunday, 14 May 2017 at 19:10:05 UTC, Ola Fosheim Grøstad wrote:
On Sunday, 14 May 2017 at 16:44:10 UTC, Patrick Schluter wrote:
What does that snippet do ? What should it do?
int caca(void)
{
for(int i=0x; i!=0x8000; i++)
printf("coucou");
}
Implicit coercion is a design
On Sunday, 14 May 2017 at 16:44:10 UTC, Patrick Schluter wrote:
What does that snippet do ? What should it do?
int caca(void)
{
for(int i=0x; i!=0x8000; i++)
printf("coucou");
}
Implicit coercion is a design bug in both C and D... :-P
What does that snippet do ? What should it do?
int caca(void)
{
for(int i=0x; i!=0x8000; i++)
printf("coucou");
}
On Sunday, 14 May 2017 at 12:07:40 UTC, Timon Gehr wrote:
On 14.05.2017 11:42, Patrick Schluter wrote:
But completely removing the code when one encounters for
example:
if(val+1 == INT_MIN) is simply nuts.
Why? This is simple dead code elimination. The programmer
clearly must have known
On Sunday, 14 May 2017 at 09:42:05 UTC, Patrick Schluter wrote:
But completely removing the code when one encounters for
example: if(val+1 == INT_MIN) is simply nuts.
Removing such code is precisely what dmd does:
https://issues.dlang.org/show_bug.cgi?id=16268
On Sunday, 14 May 2017 at 09:56:18 UTC, Dibyendu Majumdar wrote:
On Sunday, 14 May 2017 at 02:11:36 UTC, bachmeier wrote:
On Sunday, 14 May 2017 at 00:05:56 UTC, Dibyendu Majumdar
wrote:
(a) Trust the programmer.
I don't understand this point. C doesn't offer the programmer
much to work
On 14.05.2017 11:42, Patrick Schluter wrote:
...
(a) Trust the programmer.
(b) Don't prevent the programmer from doing what needs to be done.
(c) Keep the language small and simple.
(d) Provide only one way to do an operation.
(e) Make it fast, even if it is not guaranteed to be portable.
(f)
On Wednesday, 10 May 2017 at 12:18:40 UTC, Patrick Schluter wrote:
On Wednesday, 10 May 2017 at 11:16:57 UTC, Atila Neves wrote:
[...]
The likelihood of a randomly picked C/C++ programmer not even
knowing what a profiler is, much less having used one, is
extremely high in my experience. I
On Sunday, 14 May 2017 at 01:30:47 UTC, Jack Stouffer wrote:
On Sunday, 14 May 2017 at 00:05:56 UTC, Dibyendu Majumdar wrote:
(a) Trust the programmer.
That's the first and most deadly mistake. Buffer overflows and
null pointers alone have caused hundreds of millions of dollars
of damages.
On Sunday, 14 May 2017 at 02:11:36 UTC, bachmeier wrote:
On Sunday, 14 May 2017 at 00:05:56 UTC, Dibyendu Majumdar wrote:
(a) Trust the programmer.
I don't understand this point. C doesn't offer the programmer
much to work with. If you trust the programmer, shouldn't that
mean you provide
On Sunday, 14 May 2017 at 02:11:36 UTC, bachmeier wrote:
On Sunday, 14 May 2017 at 00:05:56 UTC, Dibyendu Majumdar wrote:
(a) Trust the programmer.
I don't understand this point. C doesn't offer the programmer
much to work with. If you trust the programmer, shouldn't that
mean you provide
On Sunday, 14 May 2017 at 00:05:56 UTC, Dibyendu Majumdar wrote:
On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote:
Walter: I believe memory safety will kill C.
Hi,
I think that comparing languages like D to C is not
appropriate. C is a high level assembler and has different
design
On Sunday, 14 May 2017 at 01:30:47 UTC, Jack Stouffer wrote:
It almost happened with Toyota. The auto industry has a C
coding convention for safety called MISRA C, and it was brought
up in court as to why Toyota's acceleration problems were
entirely their fault. You can bet this will be
On Sunday, 14 May 2017 at 00:05:56 UTC, Dibyendu Majumdar wrote:
(a) Trust the programmer.
I don't understand this point. C doesn't offer the programmer
much to work with. If you trust the programmer, shouldn't that
mean you provide a large set of tools and let them decide which
parts to
On Sunday, 14 May 2017 at 00:05:56 UTC, Dibyendu Majumdar wrote:
(a) Trust the programmer.
That's the first and most deadly mistake. Buffer overflows and
null pointers alone have caused hundreds of millions of dollars
of damages. I think we can say that this trust is misplaced.
(b) Don't
On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote:
Walter: I believe memory safety will kill C.
Hi,
I think that comparing languages like D to C is not appropriate.
C is a high level assembler and has different design goals. A
useful document to refer to is:
On Friday, 12 May 2017 at 04:08:52 UTC, Laeeth Isharc wrote:
build tool. We have extern(C++) which is great, and no other
language has it.
Objective-C++/Swift.
Maybe it's wrong to think about there being one true inheritor
of the mantle of C and C++. Maybe no new language will gain
the
On Friday, 12 May 2017 at 18:52:43 UTC, Joakim wrote:
On Saturday, 6 May 2017 at 09:53:52 UTC, qznc wrote:
On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote:
[...]
Hm, Sociomantic removes the live captures the next day?
One request: Chop the panel discussion into one clip per
On Saturday, 6 May 2017 at 09:53:52 UTC, qznc wrote:
On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote:
[...]
Hm, Sociomantic removes the live captures the next day?
One request: Chop the panel discussion into one clip per
question/topic, please. Alternatively, provide some means to
On 2017-05-09 16:13, Walter Bright wrote:
I agree. But one inevitably runs into problems relying on valgrind and
other third party tools:
1. it isn't part of the language
2. it may not be available on your platform
3. somebody has to find it, install it, and integrate it into the
dev/test
On Friday, May 12, 2017 04:08:52 Laeeth Isharc via Digitalmars-d wrote:
> And I am sure Walter is right about the importance of memory
> safety. But outside of certain areas D isn't in a battle with
> Rust; memory safety is one more appealing modern feature of D.
> To say it's important to get it
On Thursday, 11 May 2017 at 15:53:40 UTC, Jonathan M Davis wrote:
On Monday, May 08, 2017 23:15:12 H. S. Teoh via Digitalmars-d
wrote:
Recently I've had the dubious privilege of being part of a
department wide push on the part of my employer to audit our
codebases (mostly C, with a smattering
On 05/11/2017 10:20 PM, Nick Sabalausky (Abscissa) wrote:
On 05/10/2017 02:28 AM, H. S. Teoh via Digitalmars-d wrote:
I'm on the fence about the former. My current theory is that being
forced to write "proper" code even while refactoring actually helps the
quality of the resulting code.
I
On 05/10/2017 02:28 AM, H. S. Teoh via Digitalmars-d wrote:
I'd much rather the compiler say "Hey, you! This piece of code is
probably wrong, so please fix it! If it was intentional, please write it
another way that makes that clear!" - and abort with a compile error.
In the vast majority of
On 05/11/2017 11:53 AM, Jonathan M Davis via Digitalmars-d wrote:
In a way, it's amazing how successful folks can be with software that's
quite buggy. A _lot_ of software works just "well enough" that it gets the
job done but is actually pretty terrible. And I've had coworkers argue to me
On 05/10/2017 08:06 AM, Patrick Schluter wrote:
On Wednesday, 10 May 2017 at 06:28:31 UTC, H. S. Teoh wrote:
On Tue, May 09, 2017 at 09:19:08PM -0400, Nick Sabalausky
[...]
Perhaps I'm just being cynical, but my current unfounded hypothesis is
that the majority of C/C++ programmers ...
Just
On Thursday, 11 May 2017 at 21:20:35 UTC, Jack Stouffer wrote:
On Tuesday, 9 May 2017 at 14:13:31 UTC, Walter Bright wrote:
2. it may not be available on your platform
I just had to use valgrind for the first time in years at work
(mostly Python code there) and I realized that there's no
On Tuesday, 9 May 2017 at 14:13:31 UTC, Walter Bright wrote:
2. it may not be available on your platform
I just had to use valgrind for the first time in years at work
(mostly Python code there) and I realized that there's no version
that works on the latest OS X version. So valgrind runs on
On Thursday, 11 May 2017 at 09:39:57 UTC, Kagamin wrote:
https://bugs.chromium.org/p/project-zero/issues/detail?id=1252=5 - a
vulnerability in an application that doesn't go on the internet.
This link got me thinking: When will we see the first class
action lawsuit for criminal negligence
On Wednesday, 10 May 2017 at 17:51:38 UTC, H. S. Teoh wrote:
Haha, I guess I'm not as good of a C coder as I'd like to think
I am. :-D
That comment puts you ahead of the pack already :)
On Monday, May 08, 2017 23:15:12 H. S. Teoh via Digitalmars-d wrote:
> Recently I've had the dubious privilege of being part of a department
> wide push on the part of my employer to audit our codebases (mostly C,
> with a smattering of C++ and other code, all dealing with various levels
> of
On Thursday, 11 May 2017 at 09:39:57 UTC, Kagamin wrote:
On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote:
Walter: Anything that goes on the internet.
https://bugs.chromium.org/p/project-zero/issues/detail?id=1252=5 - a
vulnerability in an application that doesn't go on the internet.
On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote:
Walter: Anything that goes on the internet.
https://bugs.chromium.org/p/project-zero/issues/detail?id=1252=5 - a
vulnerability in an application that doesn't go on the internet.
On Wednesday, 10 May 2017 at 18:58:35 UTC, H. S. Teoh wrote:
On Wed, May 10, 2017 at 11:16:57AM +, Atila Neves via
Digitalmars-d wrote: [...]
[...]
Very nice! Reminds me of an incident many years ago where I
"optimized" a shell script that took >2 days to generate a
report by rewriting
On Wed, May 10, 2017 at 12:06:46PM +, Patrick Schluter via Digitalmars-d
wrote:
> On Wednesday, 10 May 2017 at 06:28:31 UTC, H. S. Teoh wrote:
> > On Tue, May 09, 2017 at 09:19:08PM -0400, Nick Sabalausky
> [...]
> > Perhaps I'm just being cynical, but my current unfounded hypothesis
> > is
On Wed, May 10, 2017 at 11:16:57AM +, Atila Neves via Digitalmars-d wrote:
[...]
> The likelihood of a randomly picked C/C++ programmer not even knowing
> what a profiler is, much less having used one, is extremely high in my
> experience. I worked with a lot of embedded C programmers with
>
On Wed, May 10, 2017 at 12:34:05PM +, Guillaume Boucher via Digitalmars-d
wrote:
[...]
> In modern C and with GLib (which makes use of a gcc/clang extension) you can
> write this as:
>
> gboolean myfunc(blah_t *blah, bleh_t *bleh, bluh_t *bluh) {
> /* Cleanup everything automatically
On Wed, May 10, 2017 at 04:38:48AM -0700, Ali Çehreli via Digitalmars-d wrote:
> On 05/09/2017 10:26 PM, H. S. Teoh via Digitalmars-d wrote:
> > On Wed, May 10, 2017 at 01:32:33AM +, Jack Stouffer via Digitalmars-d
> wrote:
> >> On Wednesday, 10 May 2017 at 00:30:42 UTC, H. S. Teoh wrote:
On Wednesday, 10 May 2017 at 01:19:08 UTC, Nick Sabalausky
(Abscissa) wrote:
The moral of this story: Sometimes, breaking people's code is
GOOD! ;)
I don't get the hate that compiler warnings get in the D
community.
Sure you can disable them if you don't care, but then don't
complain about
On Wednesday, 10 May 2017 at 11:50:32 UTC, Jonathan M Davis wrote:
On Tuesday, May 09, 2017 07:13:31 Walter Bright via
Digitalmars-d wrote:
On 5/8/2017 1:55 PM, John Carter wrote:
Atila commented at dconf that working with allocators in D code
for the excel wrapper library he had worked on
On Wednesday, 10 May 2017 at 12:18:40 UTC, Patrick Schluter wrote:
On Wednesday, 10 May 2017 at 11:16:57 UTC, Atila Neves wrote:
[...]
The likelihood of a randomly picked C/C++ programmer not even
knowing what a profiler is, much less having used one, is
extremely high in my experience. I
On Wednesday, 10 May 2017 at 05:26:11 UTC, H. S. Teoh wrote:
int myfunc(blah_t *blah, bleh_t *bleh, bluh_t *bluh) {
void *resource1, *resource2, *resource3;
int ret = RET_ERROR;
/* Vet arguments */
if (!blah || !bleh ||
On Wednesday, 10 May 2017 at 11:16:57 UTC, Atila Neves wrote:
[...]
The likelihood of a randomly picked C/C++ programmer not even
knowing what a profiler is, much less having used one, is
extremely high in my experience. I worked with a lot of
embedded C programmers with several years of
On Wednesday, 10 May 2017 at 06:28:31 UTC, H. S. Teoh wrote:
On Tue, May 09, 2017 at 09:19:08PM -0400, Nick Sabalausky
[...]
Perhaps I'm just being cynical, but my current unfounded
hypothesis is that the majority of C/C++ programmers ...
Just a nitpick, could we also please stop conflating
On Tuesday, May 09, 2017 07:13:31 Walter Bright via Digitalmars-d wrote:
> On 5/8/2017 1:55 PM, John Carter wrote:
> > On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote:
> >> Walter: I believe memory safety will kill C.
> >
> > C/C++ has been granted an extension of life by the likes of
On 05/09/2017 10:26 PM, H. S. Teoh via Digitalmars-d wrote:
> On Wed, May 10, 2017 at 01:32:33AM +, Jack Stouffer via
Digitalmars-d wrote:
>> On Wednesday, 10 May 2017 at 00:30:42 UTC, H. S. Teoh wrote:
>>>strncpy(tmp, desc->data1, bufsz);
>>>if (fwrite(tmp,
On Wednesday, 10 May 2017 at 06:28:31 UTC, H. S. Teoh wrote:
On Tue, May 09, 2017 at 09:19:08PM -0400, Nick Sabalausky
(Abscissa) via Digitalmars-d wrote:
On 05/09/2017 08:30 PM, H. S. Teoh via Digitalmars-d wrote:
>
> In this sense I agree with Walter that warnings are
> basically useless,
On 5/10/17 8:28 AM, H. S. Teoh via Digitalmars-d wrote:
C++'s fundamental paradigm has always been "Premature-optimization
oriented programming". C++ promotes POOP.
LOL!!
Perhaps I'm just being cynical, but my current unfounded hypothesis is
that the majority of C/C++ programmers don't use a
On Tue, May 09, 2017 at 09:19:08PM -0400, Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:
> On 05/09/2017 08:30 PM, H. S. Teoh via Digitalmars-d wrote:
> >
> > In this sense I agree with Walter that warnings are basically
> > useless, because they're not enforced. Either something is correct
On Wed, May 10, 2017 at 01:32:33AM +, Jack Stouffer via Digitalmars-d wrote:
> On Wednesday, 10 May 2017 at 00:30:42 UTC, H. S. Teoh wrote:
> > strncpy(tmp, desc->data1, bufsz);
> > if (fwrite(tmp, strlen(tmp), 1, fp) != 1)
> > {
> >
On Wednesday, 10 May 2017 at 00:30:42 UTC, H. S. Teoh wrote:
strncpy(tmp, desc->data1, bufsz);
if (fwrite(tmp, strlen(tmp), 1, fp) != 1)
{
fclose(fp);
unlink("blah");
return
On 05/09/2017 08:30 PM, H. S. Teoh via Digitalmars-d wrote:
In this sense I agree with Walter that warnings are basically useless,
because they're not enforced. Either something is correct and compiles,
or it should be an error that stops compilation. Anything else, and you
start having people
On Tue, May 09, 2017 at 11:09:27PM +, Guillaume Boucher via Digitalmars-d
wrote:
> On Tuesday, 9 May 2017 at 16:55:54 UTC, H. S. Teoh wrote:
> > Ouch. Haha, even I forgot about this particularly lovely aspect of
> > C. Hooray, freely call functions without declaring them, and
> >
On Tuesday, 9 May 2017 at 16:55:54 UTC, H. S. Teoh wrote:
Ouch. Haha, even I forgot about this particularly lovely
aspect of C. Hooray, freely call functions without declaring
them, and "obviously" they return int! Why not?
To be fair, most of your complaints can be fixed by enabling
On Tuesday, 9 May 2017 at 16:55:54 UTC, H. S. Teoh wrote:
On Tue, May 09, 2017 at 08:18:09AM +, Patrick Schluter via
[...]
Ouch. Haha, even I forgot about this particularly lovely
aspect of C. Hooray, freely call functions without declaring
them, and "obviously" they return int! Why not?
On Tue, May 09, 2017 at 07:13:31AM -0700, Walter Bright via Digitalmars-d wrote:
> On 5/8/2017 1:55 PM, John Carter wrote:
> > On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote:
> >
> > > Walter: I believe memory safety will kill C.
> >
> > C/C++ has been granted an extension of life by the
On 05/09/2017 06:29 AM, Adrian Matoga wrote:
On Tuesday, 9 May 2017 at 09:22:13 UTC, Joakim wrote:
On Tuesday, 9 May 2017 at 06:15:12 UTC, H. S. Teoh wrote:
On Mon, May 08, 2017 at 06:33:08PM +, Jerry via Digitalmars-d wrote:
[...]
Is that a subtle joke, or are you being serious?
[...]
On Tue, May 09, 2017 at 08:18:09AM +, Patrick Schluter via Digitalmars-d
wrote:
> On Tuesday, 9 May 2017 at 06:15:12 UTC, H. S. Teoh wrote:
> >
> > int my_func(mytype_t *input, outbuf_t *output_buf,
> > char *buffer, int size)
> > {
> > /* Typical lazy way
1 - 100 of 120 matches
Mail list logo
