On Saturday, 12 December 2020 at 15:51:46 UTC, Calvin P wrote:
I made a cross build with LDC -g -gdwarf-4 -O0 -D_DEBUG, the
app crash with a report include PC address 0x005e34a9.
[...]
Find the solution:
lldb-11 tests_curl
(lldb) target create "tests_curl"
Current executable set to 'tests_cu
I made a cross build with LDC -g -gdwarf-4 -O0 -D_DEBUG, the app
crash with a report include PC address 0x005e34a9.
Is there a way to find the source location for that PC address?
==4172==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x035dfcf0 at pc 0x005e34a9 bp 0x035dfa20 sp 0x0
I try find a memory issue with ldc -betterC -g -fsanitize=address
-disable-fp-elim, get invalid path to external symbolizer!
Is there a way to print the symbol and line ?
=
==113433==ERROR: AddressSanitizer: heap-buffer-overflow
On Thursday, 19 March 2020 at 23:46:01 UTC, Boris Carvajal wrote:
https://issues.dlang.org/show_bug.cgi?id=20687
https://github.com/dlang/dmd/pull/10946
Thanks very much for such a quick fix.
On Thursday, 19 March 2020 at 13:23:41 UTC, Adam D. Ruppe wrote:
Check the error message there... you already have a function
pointer, no need to use the .funcptr metod.
It is a bit weird though because it actually EXCLUDES the
hidden argument for `this`. I prefer doing wrapper functions
us
On Monday, 16 March 2020 at 18:43:47 UTC, Steven Schveighoffer
wrote:
enum A0 = &A.d;
Note that you can't call it at all, but you can get the
function pointer, and put it into a delegate later by assigning
.funcptr.
void main()
{
A a;
void delegate() dg;
dg.ptr = &a;
dg.func
On Thursday, 19 March 2020 at 06:34:40 UTC, Alex wrote:
A non-static member method can use the context of the struct
where it is defined in. E.g. it could alter a member variable.
This context has to be constructed at run time (and there could
be many instances of the context) and does not exist
I use this code to get member function address on runtime:
=
struct A {
this(){};
}
auto ctor = (&__traits(getMember, A.init,"__ctor")).funcptr;
=
my question is, how to get it in compile time like static
function address:
=
struct A {
void d(){};
sta
I use this code to get member function address on runtime:
=
struct A {
this(){};
}
auto ctor = (&__traits(getMember, A.init,"__ctor")).funcptr;
=
my question is, how to get it in compile time like static
function address:
=
struct A {
void d(){};
sta
On Monday, 9 March 2020 at 19:10:54 UTC, Timon Gehr wrote:
https://wiki.dlang.org/DIP24
Hi , Timon Gehr
Thanks for the reply, very good DIPS.
I think this is very basic work, why the core team not take care
it for such a long time.
On Monday, 9 March 2020 at 13:55:08 UTC, Calvin P wrote:
The current compiler "-i=module_name" option will include
imported modules as source code.
When the module define from di file extension, I think compiler
should avoid treat it as source file.
What do you think?
The use case:
If I
The current compiler "-i=module_name" option will include
imported modules as source code.
When the module define from di file extension, I think compiler
should avoid treat it as source file.
What do you think?
On Monday, 9 March 2020 at 12:14:06 UTC, Adam D. Ruppe wrote:
Here's a wiki page referencing one of the 2013 discussions
https://wiki.dlang.org/Property_Discussion_Wrap-up
though i'll note the thing is older than that.
What especially drove me nuts is people would so often say
"property *synt
On Monday, 9 March 2020 at 09:44:40 UTC, Simen Kjærås wrote:
As written on
https://dlang.org/spec/function.html#property-functions:
WARNING: The definition and usefulness of property functions
is being reviewed, and the implementation is currently
incomplete. Using property functions is not r
Is this a bugs ?
==
struct A {
ref auto opCall(string tmp) scope return {
return this;
}
}
struct B {
A _a;
@property ref auto a() scope return {
return _a;
}
}
extern(C) int main(){
A a;
a("a")
15 matches
Mail list logo
