On 5/22/2020 10:33 AM, rikki cattermole wrote:
To me at least, this butchers @safe/trusted/system into a system that is near
useless for guarantees for an entire program.
It never attempted to guarantee safety in code that was never compiled with a D
compiler. It's impossible to do that. No
On Saturday, 23 May 2020 at 03:29:44 UTC, Daniel C wrote:
On Saturday, 23 May 2020 at 03:25:12 UTC, Daniel C wrote:
I'm building my app without dub. I've now put all the source
files into the same folder as my project and I'm still seeing
the same undefined symbol issue.
I should say, I put
On Saturday, 23 May 2020 at 03:25:12 UTC, Daniel C wrote:
On Saturday, 23 May 2020 at 01:23:38 UTC, Mike Parker wrote:
What download are you referring to? I don't have any library
files in the git repository, and I don't know of any downloads
from the duo repository.
Huh.. I'm not sure, it
On Saturday, 23 May 2020 at 01:23:38 UTC, Mike Parker wrote:
What download are you referring to? I don't have any library
files in the git repository, and I don't know of any downloads
from the duo repository.
Huh.. I'm not sure, it must have gotten there when I dub'd
something lol. Sorry
On Saturday, 23 May 2020 at 03:25:12 UTC, Daniel C wrote:
I'm building my app without dub. I've now put all the source
files into the same folder as my project and I'm still seeing
the same undefined symbol issue.
I should say, I put the bindbc library into a subfolder. So it's
like this:
On Friday, 22 May 2020 at 22:20:55 UTC, Daniel C wrote:
There is a library file included in the dub repository
download: https://code.dlang.org/packages/bindbc-sdl
What download are you referring to? I don't have any library
files in the git repository, and I don't know of any downloads
On 5/22/2020 10:54 AM, Atila Neves wrote:
BTW, you should fix that invalid attribute, freeing a pointer is never @safe
unless you can guarantee nobody else has a copy of that pointer (and
considering it's passed by value, the CALLER still has that pointer!)
You're completely right.
@live is
There are no binary files provided in the bindbc-sdl repository.
https://github.com/BindBC/bindbc-sdl
It is a binding, it should match 1:1 definition wise to the C
definition.
There is a library file included in the dub repository download:
https://code.dlang.org/packages/bindbc-sdl
Also,
On Friday, 22 May 2020 at 12:25:23 UTC, jmh530 wrote:
On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
[snip]
Thank you for your reply.
How about some time before this DIP is fully in the language, a
compiler flag is added that will produce warnings for when
extern prototypes
On Friday, 22 May 2020 at 18:27:42 UTC, Atila Neves wrote:
Sorry, I didn't express myself well. I meant that the user can
still mark functions as @system, they just have to do it
explicitly.
Hm, DPP might be of help here. Becuse I quess you are going to
make sure it'll mark everything
On Friday, 22 May 2020 at 19:16:26 UTC, ag0aep6g wrote:
I for one liked it better when it had that aspiration. And I
was contributing towards that goal (latest PR was merged just
yesterday, coincidentally [1]).
[1] https://github.com/dlang/dlang.org/pull/2773
Thank you for that PR, by the
On 22.05.20 20:24, Atila Neves wrote:
On Friday, 22 May 2020 at 18:11:28 UTC, ag0aep6g wrote:
So the DIP itself wasn't good enough to convince you.
Had that been the case, I would have rejected it.
You said the DIP as written felt "icky". And only after a chat with
Walter did that feeling
On Friday, 22 May 2020 at 18:32:59 UTC, Steven Schveighoffer
wrote:
So the solution is -- make the compiler be dumb for you? If you
are going to incorrectly put @safe on it, I want you to have to
do it because YOU made a conscious decision to be careless, not
have it done for you because you
On Friday, 22 May 2020 at 18:44:09 UTC, Steven Schveighoffer
wrote:
[snip]
You are using library fubar.
fubar defines a function foo:
I agree with most of what you said.
I was trying to make the point that this is a contrived example
where we know for sure that one function should be
On Friday, 22 May 2020 at 18:34:32 UTC, Gregory wrote:
[snip]
Why are you assuming that the only thing wrong with
useClibrary() is that it would use a C declaration that is
@system? All @system code I've written is @system and wouldn't
compile to @safe even if extern(C) declarations are
On 5/22/20 1:52 PM, jmh530 wrote:
On Friday, 22 May 2020 at 16:47:34 UTC, Steven Schveighoffer wrote:
[snip]
You can't, you don't control that code, someone else does (this is
important, you can declare extern(C) functions anywhere, even locally).
You can make a separate module with one
On Friday, 22 May 2020 at 17:54:26 UTC, Atila Neves wrote:
On Friday, 22 May 2020 at 17:41:38 UTC, Steven Schveighoffer
And so, you are free to pepper your @safe code with dangling
pointers. Sure, you can claim that the C++ library didn't
"corrupt your code", which is the case for ALL
On 5/22/20 1:54 PM, Atila Neves wrote:
My point is that the result of making declarations implicity @system
instead of @safe would make people just slap @safe on them without
really thinking about it to get their code to compile. Like I did.
So the solution is -- make the compiler be dumb for
On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
Consider the common (because that's how D started out) case of:
- clibrary.d
T massage_data(... many parameters ...);
... 200 more such declarations ...
- app.d --
import clibrary;
void
On Friday, 22 May 2020 at 18:17:29 UTC, ag0aep6g wrote:
On 22.05.20 19:54, Atila Neves wrote:
We care. Annotations become explicit. Do I think this is
ideal? No.
"Annotations become explicit." - What now? I probably
misunderstand that sentence, but DIP 1028 does not require
explicit
On 22.05.20 19:12, Atila Neves wrote:
Flipping the default will cause more incorrect code to fail to compile.
Yes, there's a cost, which is carefully vetting extern(C) and
extern(C++) declarations. The decision came down to finding this an
acceptable trade-off.
You can still carefully vet
On Friday, 22 May 2020 at 18:11:28 UTC, ag0aep6g wrote:
So the DIP itself wasn't good enough to convince you.
Had that been the case, I would have rejected it.
Your reasoning is fine when you're dealing with a function that
has a safe interface. I.e., it can only corrupt your code when
it's
On 22.05.20 19:54, Atila Neves wrote:
Right. And the point I was trying to make wasn't "look at what I did,
it's cool". No, what I did was dumb. So dumb it took you no time at all
to point out one of my mistakes. My point is that the result of making
declarations implicity @system instead of
On Friday, 22 May 2020 at 17:40:59 UTC, Atila Neves wrote:
[snip]
That is a failure of the language that should be resolved.
And how do you suggest we fix it?
@safe as whitelist instead of blacklist.
When the compiler cannot verify that it is @safe, then it cannot
be @safe.
On 22.05.20 19:07, Atila Neves wrote:
Personally and initially, I would have preferred it if non-extern(D)
declarations were implicitly @system. I understood Walter's argument
about special cases and how they're bad, but the thought of them being
@safe made me feel, for lack of a better word,
On Fri, May 22, 2020 at 05:26:03PM +, Adam D. Ruppe via
Digitalmars-d-announce wrote:
[...]
> int snprintf(char[] buf, const char* fmt, ...) {
>return c.snprintf(buf.ptr, buf.length, fmt, ...);
> }
>
> Well, lol, that's not exactly *correct* thanks to the possibility of
> format string
On 23/05/2020 5:40 AM, Atila Neves wrote:
On Friday, 22 May 2020 at 17:33:11 UTC, rikki cattermole wrote:
On 23/05/2020 5:07 AM, Atila Neves wrote:
[...]
It is not about the linkage.
The problem is solely does the compiler have the source to the
function body to verify it?
That's what I
Perhaps not the ideal solution, but would a compiler flag, e.g.
--strict-safe, that ensures the compiler errors on un-@trusted
non-D function prototypes be appropriate? This way, those who do
work on mission-critical stuff can feel a tad better.
On Friday, 22 May 2020 at 16:47:34 UTC, Steven Schveighoffer
wrote:
[snip]
You can't, you don't control that code, someone else does (this
is important, you can declare extern(C) functions anywhere,
even locally).
You can make a separate module with one function that just calls
the `free`
On Friday, 22 May 2020 at 17:41:38 UTC, Steven Schveighoffer
wrote:
On 5/22/20 1:07 PM, Atila Neves wrote:
And so I was convinced that everything being @safe is actually
ok, especially because in real life, most C/C++ APIs aren't
going to secretly corrupt your code.
Yes, it can, but not
On Friday, 22 May 2020 at 17:07:37 UTC, Atila Neves wrote:
And so I was convinced that everything being @safe is actually
ok, especially because in real life, most C/C++ APIs aren't
going to secretly corrupt your code.
Uh? There's plenty of C/C++ code out there with api that when
"used in
On Friday, 22 May 2020 at 17:33:11 UTC, rikki cattermole wrote:
On 23/05/2020 5:07 AM, Atila Neves wrote:
[...]
It is not about the linkage.
The problem is solely does the compiler have the source to the
function body to verify it?
That's what I meant, sorry for not making it clearer.
On 5/22/20 1:07 PM, Atila Neves wrote:
And so I was convinced that everything being @safe is actually ok,
especially because in real life, most C/C++ APIs aren't going to
secretly corrupt your code.
Yes, it can, but not secretly. Just obviously and easily. Note this
function:
On 23/05/2020 5:07 AM, Atila Neves wrote:
On Friday, 22 May 2020 at 12:28:56 UTC, rikki cattermole wrote:
On 23/05/2020 12:19 AM, Joseph Rushton Wakeling wrote:
With the rationale laid out clearly as it is here, I do have some
responses in mind. But before sharing them, I'd like to know
On Friday, 22 May 2020 at 17:07:37 UTC, Atila Neves wrote:
And so I was convinced that everything being @safe is actually
ok, especially because in real life, most C/C++ APIs aren't
going to secretly corrupt your code.
I wrote up a thing about this earlier then deleted it because I
didn't
On 22.05.20 18:43, Adam D. Ruppe wrote:
On Friday, 22 May 2020 at 16:39:42 UTC, jmh530 wrote:
Fortunately, the above point can be more easily fixed by making `free`
@system
With the o/b system `free` might actually work out OK
free(new int);
On Friday, 22 May 2020 at 14:37:04 UTC, bachmeier wrote:
On Friday, 22 May 2020 at 13:57:27 UTC, Mike Parker wrote:
[...]
I think the source of the problem is that Walter's DIPs require
the community to prove that Walter's proposal is so bad that he
needs to reject it. Anyone else's
On Friday, 22 May 2020 at 14:13:20 UTC, Paul Backus wrote:
On Friday, 22 May 2020 at 13:58:14 UTC, bachmeier wrote:
On Friday, 22 May 2020 at 03:36:03 UTC, Paul Backus wrote:
This is the nightmare scenario that people are worried about:
safety violations
being introduced *silently* into
On Friday, 22 May 2020 at 12:28:56 UTC, rikki cattermole wrote:
On 23/05/2020 12:19 AM, Joseph Rushton Wakeling wrote:
With the rationale laid out clearly as it is here, I do have
some responses in mind. But before sharing them, I'd like to
know whether that would be useful right now: I've no
On Friday, 22 May 2020 at 03:57:22 UTC, H. S. Teoh wrote:
On Thu, May 21, 2020 at 06:22:19PM -0700, Walter Bright via
Digitalmars-d-announce wrote:
I have made these points before, but I'll summarize them here
for convenient referral.
[...]
Thank you. This makes your position clear, even if
On Thursday, 21 May 2020 at 23:49:22 UTC, Bruce Carneal wrote:
On Thursday, 21 May 2020 at 16:32:32 UTC, Adam D. Ruppe wrote:
On Thursday, 21 May 2020 at 16:14:02 UTC, Seb wrote:
[...]
ditto, I think we should have like a seven person elected DIP
committee who pass/fail things by majority
On Fri, May 22, 2020 at 04:39:42PM +, jmh530 via Digitalmars-d-announce
wrote:
[...]
> This comes back to a point I had made on one of the original DIP
> discussion threads that one issue is that @safe is a blacklist of
> things you can't do rather than a whitelist of allowed things.
[...]
On 5/22/20 12:39 PM, jmh530 wrote:
On Friday, 22 May 2020 at 16:03:00 UTC, Steven Schveighoffer wrote:
[snip]
Fortunately, the above point can be more easily fixed by making `free`
@system, which will then require annotating every subsequent piece of
code that touches it. It's annoying
On Fri, May 22, 2020 at 12:03:00PM -0400, Steven Schveighoffer via
Digitalmars-d-announce wrote:
[...]
> Or worse, it's not discovered and then D's already shaky reputation
> for @safe code is destroyed when a hacker exploits the memory
> corruption in fully-marked @safe code.
[...]
TBH, this
On Friday, 22 May 2020 at 16:39:42 UTC, jmh530 wrote:
Fortunately, the above point can be more easily fixed by making
`free` @system
With the o/b system `free` might actually work out OK
On Friday, 22 May 2020 at 16:03:00 UTC, Steven Schveighoffer
wrote:
[snip]
Fortunately, the above point can be more easily fixed by making
`free` @system, which will then require annotating every
subsequent piece of code that touches it. It's annoying
transition, but it's do-able. The
On Thursday, 21 May 2020 at 13:51:34 UTC, Mike Parker wrote:
DIP 1028, "Make @safe the Default", has been accepted without
comment.
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1028.md
I've made a draft PR to try and address the potential safety
issue discussed in this thread.
On 5/22/20 6:13 AM, Dukc wrote:
Wrong :-(. The scenario is this:
```
@safe void foo(int* p)
{ import customfreefunction.noannotations;
p.free;
p.free;
}
```
Now, this will not compile, because `free` is `@system`. But if `free`
is in unannotated module, this will compile after the
On Friday, 22 May 2020 at 13:57:27 UTC, Mike Parker wrote:
The DIP review process is not intended for community approval
or rejection of DIPs. It's not a democratic voting process.
The community needs to unite and fix this. It is an ineffectual
process that leads to worse results for the
On 22.05.20 16:49, bachmeier wrote:
On Friday, 22 May 2020 at 14:38:09 UTC, Timon Gehr wrote:
On 22.05.20 15:58, bachmeier wrote:
...
Honest question: What is the use case for an
absolutely-positively-has-to-be-safe program that calls C code? Why
would anyone ever do that? C is not and will
On Friday, 22 May 2020 at 14:37:04 UTC, bachmeier wrote:
I think the source of the problem is that Walter's DIPs require
the community to prove that Walter's proposal is so bad that he
needs to reject it. Anyone else's proposal has to prove that
it's worthy of being added to the language.
On Friday, 22 May 2020 at 14:43:27 UTC, bachmeier wrote:
If you're compiling a program that calls into C, you know
that's what you're doing, so you know you've given up any
guarantees of safety.
The entire problem is that with DIP 1028, I *don't* know what I'm
doing, because the compiler
On Friday, 22 May 2020 at 13:57:27 UTC, Mike Parker wrote:
On Friday, 22 May 2020 at 12:47:04 UTC, matheus wrote:
As an end user, I'd like to know if this language will be
guided by community or one person, because it seems the
"democracy" is very shallow right now.
And again why waste
On Friday, 22 May 2020 at 14:38:09 UTC, Timon Gehr wrote:
On 22.05.20 15:58, bachmeier wrote:
...
Honest question: What is the use case for an
absolutely-positively-has-to-be-safe program that calls C
code? Why would anyone ever do that? C is not and will never
be a safe language. "Someone
On Friday, 22 May 2020 at 14:13:20 UTC, Paul Backus wrote:
On Friday, 22 May 2020 at 13:58:14 UTC, bachmeier wrote:
On Friday, 22 May 2020 at 03:36:03 UTC, Paul Backus wrote:
This is the nightmare scenario that people are worried about:
safety violations
being introduced *silently* into
On 22.05.20 15:58, bachmeier wrote:
...
Honest question: What is the use case for an
absolutely-positively-has-to-be-safe program that calls C code? Why
would anyone ever do that? C is not and will never be a safe language.
"Someone looked at that blob of horrendous C code and thinks it's
On Friday, 22 May 2020 at 13:57:27 UTC, Mike Parker wrote:
On Friday, 22 May 2020 at 12:47:04 UTC, matheus wrote:
As an end user, I'd like to know if this language will be
guided by community or one person, because it seems the
"democracy" is very shallow right now.
And again why waste
On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
3. Wrap the call to massage_data() with:
() @trusted { massage_data(parameters); } ();
The correct solution is to encapsulate the C functions as-needed
with a higher level API - and this is somewhat commonly done
already and -
On Friday, 22 May 2020 at 13:58:14 UTC, bachmeier wrote:
On Friday, 22 May 2020 at 03:36:03 UTC, Paul Backus wrote:
This is the nightmare scenario that people are worried about:
safety violations
being introduced *silently* into existing, correct D code.
Honest question: What is the use case
On Friday, 22 May 2020 at 05:37:55 UTC, Walter Bright wrote:
On 5/21/2020 8:36 PM, Paul Backus wrote:
Something ought to be done to prevent this. It doesn't have to
be the exact
proposal from the discussion thread, but doing nothing and
allowing widespread
silent breakage cannot possibly be
On Friday, 22 May 2020 at 03:36:03 UTC, Paul Backus wrote:
Someone has created bindings for a C library and published them
on
code.dlang.org. Because they were written prior to DIP 1028,
the author assumed
that @system was the default, and didn't bother to add explicit
annotations to
@system
On Friday, 22 May 2020 at 12:47:04 UTC, matheus wrote:
As an end user, I'd like to know if this language will be
guided by community or one person, because it seems the
"democracy" is very shallow right now.
And again why waste time with this process plus 2 rounds of
discussion?
I mean
On Friday, 22 May 2020 at 13:16:50 UTC, Johannes Loher wrote:
... But unfortunately, sometimes it still really feels like
DIPs from the language maintainers and DIPs from others are
handled quite differently by the maintainers.
That's was my point about "democracy", maybe not a right word.
On 22.05.20 03:22, Walter Bright wrote:
This is Obviously A Good Idea. Why would I oppose it?
1. I've been hittin' the crack pipe again.
2. I was secretly convinced, but wanted to save face.
3. I make decisions based on consultation with my astrologer.
4. I am evil.
5. You are
On Friday, 22 May 2020 at 12:47:04 UTC, matheus wrote:
On Friday, 22 May 2020 at 12:28:56 UTC, rikki cattermole wrote:
Although it seems an improvement has been made to how he needs
to respond to the DIP assessment. It should also include a
statement from Atila as well given his position.
On Friday, 22 May 2020 at 12:28:56 UTC, rikki cattermole wrote:
Although it seems an improvement has been made to how he needs
to respond to the DIP assessment. It should also include a
statement from Atila as well given his position.
One thing that need to be clear and for I read it was not
On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
[snip]
Thank you for your reply.
How about some time before this DIP is fully in the language, a
compiler flag is added that will produce warnings for when extern
prototypes without explicit @safe/@trusted/@system are used? Or
On 23/05/2020 12:19 AM, Joseph Rushton Wakeling wrote:
With the rationale laid out clearly as it is here, I do have some
responses in mind. But before sharing them, I'd like to know whether
that would be useful right now: I've no wish to just press for a
re-hashing of conversations that have
On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
I have made these points before, but I'll summarize them here
for convenient referral.
Thanks Walter. I really appreciate you taking the time to do
this, as it's obviously no fun to be getting a big tide of
negativity in this way.
On 5/22/20 4:24 AM, ag0aep6g wrote:
By the way, I don't think you have acknowledged Steven's idea [3] at
all, yet.
Yes, he did. With more nitpicking as a rebuttal, but I'm not really
interested in having more discussions about this DIP or that proposal.
I can see that happening. A simple example would be:
extern (C) void free(void* p);
...
free(p);
free(p);
The thing is, you are no worse off than now. If free() can be
misused by calling it from system code, it can be misused by
calling it from safe code.
Wrong :-(. The
First, thank you for the explanation! I have a few observations
though, mainly that the exception analogy feels like more an
argument against the DIP than for it. And I also have an
alternative proposal that might be considered?
On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
On Thursday, 21 May 2020 at 16:13:57 UTC, zoujiaqing wrote:
Hunt Framework is a full stack Web framework based on DLang
language.
Designed for rapid development of Web servers, similar PHP's
Laravel、Java's Spring、Python's Django!
## This major update is as follows:
1. safety - related
On Thursday, 21 May 2020 at 16:13:57 UTC, zoujiaqing wrote:
Hunt Framework is a full stack Web framework based on DLang
language.
Designed for rapid development of Web servers, similar PHP's
Laravel、Java's Spring、Python's Django!
## This major update is as follows:
1. safety - related
On 22.05.20 03:22, Walter Bright wrote:
This is Obviously A Good Idea. Why would I oppose it?
1. I've been hittin' the crack pipe again.
2. I was secretly convinced, but wanted to save face.
3. I make decisions based on consultation with my astrologer.
4. I am evil.
The sarcasm is not
On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
I have made these points before, but I'll summarize them here
for convenient referral.
of material indicating, among other things, that even
really good programmers can screw up when it comes to language
design now and then.
On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
I have made these points before, but I'll summarize them here
for convenient referral.
[...]
Thank's for the reasoning, that should be added to the DIP
acceptance since the beginning.
Stated that we need to live with that, I'm
77 matches
Mail list logo
