Re: stripping binaries from LDC2

[max haughton via Digitalmars-d-learn]

On Monday, 7 February 2022 at 14:20:31 UTC, Arjan wrote:

On Monday, 7 February 2022 at 13:14:19 UTC, max haughton wrote:

On Monday, 7 February 2022 at 12:16:53 UTC, Arjan wrote:
In c++ our release builds are build `-O2 -g` and the 
resulting binaries are stripped with GNU/strip.

Is this also possible with LDC2 generated binaries for D code?
So build D code with `-O2 -g` and then strip the resulting 
binary?


Why build with debug info if you're going to strip it anyway?


The stripped release binaries are going to the client, when a 
problem occurs get a core dump, using the core dump + the 
original binary / symbol gives full debug info off site.


It is common practice.


Then yes, you can do that.

D works in basically exactly the same way C++ does in this regard.

Re: stripping binaries from LDC2

[Arjan via Digitalmars-d-learn]

On Monday, 7 February 2022 at 13:14:19 UTC, max haughton wrote:

On Monday, 7 February 2022 at 12:16:53 UTC, Arjan wrote:
In c++ our release builds are build `-O2 -g` and the resulting 
binaries are stripped with GNU/strip.

Is this also possible with LDC2 generated binaries for D code?
So build D code with `-O2 -g` and then strip the resulting 
binary?


Why build with debug info if you're going to strip it anyway?


The stripped release binaries are going to the client, when a 
problem occurs get a core dump, using the core dump + the 
original binary / symbol gives full debug info off site.


It is common practice.

Re: stripping binaries from LDC2

[max haughton via Digitalmars-d-learn]

On Monday, 7 February 2022 at 12:16:53 UTC, Arjan wrote:
In c++ our release builds are build `-O2 -g` and the resulting 
binaries are stripped with GNU/strip.

Is this also possible with LDC2 generated binaries for D code?
So build D code with `-O2 -g` and then strip the resulting 
binary?


Why build with debug info if you're going to strip it anyway?

stripping binaries from LDC2

[Arjan via Digitalmars-d-learn]

In c++ our release builds are build `-O2 -g` and the resulting 
binaries are stripped with GNU/strip.

Is this also possible with LDC2 generated binaries for D code?
So build D code with `-O2 -g` and then strip the resulting binary?

Re: ldc executable crashes with this code

[bauss via Digitalmars-d-learn]

On Saturday, 5 February 2022 at 03:02:37 UTC, forkit wrote:
On Friday, 4 February 2022 at 15:58:19 UTC, Stanislav Blinov 
wrote:


..
...
As others have already stated, casting immutability away is 
something that has to be supported, e.g. to interface with 
const-agnostic APIs. `@safe` requires such casts to be more 
verbose, with good reason.


I concede ;-)

That the compiler knows this is @safe:
cast(char[])iStr.dup;

and this is not @safe:
cast(char[])iStr;

is sufficent.


The compiler doesn't know what you think it knows in this 
scenario.


It doesn't know what function you intended to use originally, in 
this case .dup.


So what do you expect the compiler to tell you when you do the 
following?


```d
cast(char[])iStr
```

It's not actually invalid code and only invalid under @safe IFF 
the result is mutated.


To the compiler everything is actually fine in that scenario.

The compiler also doesn't know that when you cast to char[] that 
you want to get a mutable duplicate of the string, because it 
doesn't have such a concept. It doesn't know .dup is actually the 
function you want to call, because there could be an ocean of 
different functions that you want to call that returns a mutable 
reference of the type.


In fact by giving it a cast you tell the compiler "I know what 
type this really is" and thus the compiler just says "okay". It 
won't complain when you tell it you know what you're doing, 
similarly to calling a @trusted function under @safe, you tell 
the compiler "I know this function is safe, even though it's not 
marked as safe" and thus the compiler will not actually complain 
if the function wasn't safe.

Re: iteration over directories is unsafe

[bauss via Digitalmars-d-learn]

On Saturday, 5 February 2022 at 23:26:21 UTC, forkit wrote:
It is not possible to do a simple iteration over directories in 
@safe mode.


Really? I have to resort to unsafe??


//

module test;
@safe: // nope. no can do.

import std;

void main()
{
auto dFiles = dirEntries("", "*.{d,di}", SpanMode.depth);
foreach(d; dFiles)
writeln(d.name);
}

//


Well it can't be "truly" safe since it requires a call to the 
system to retrieve the directory entries.


While yeah, from common sense it's most likely safe from the 
perspective of a user, then it's not true safety as there are no 
safety guarantees as it's an external call.


I would argue that D should move towards marking certain system 
functions as trusted.