Re: 9999999999999999.0 - 9999999999999998.0

[Jesse Phillips via Digitalmars-d-learn]

On Sunday, 6 January 2019 at 00:20:40 UTC, Samir wrote:


[1] https://news.ycombinator.com/item?id=18832155
[2] https://en.wikipedia.org/wiki/IEEE_754


Since you got your answer you may also like
http://dconf.org/2016/talks/clugston.html

Re: D man pages

[Adam D. Ruppe via Digitalmars-d-learn]

On Sunday, 6 January 2019 at 02:23:20 UTC, H. S. Teoh wrote:
But something like Adam Ruppe's adrdox could possibly be the 
basis for translating individual module symbols into manpages 
perhaps?


The approach I'd take is actually converting my generated html to 
text and just piping it through less. Or if we specifically want 
man, convert the html into man syntax (there's enough semantic 
information there to do the conversion).


http://arsdnet.net/arsd/dman.png

But that's the result of about 5 mins of work... though I really 
like my hyperlinks and actually kinda prefer the browser for that 
reason (tho making a custom little terminal browser to handle the 
links is p tempting)

Re: D man pages

[H. S. Teoh via Digitalmars-d-learn]

On Sat, Jan 05, 2019 at 09:59:27PM +, kdevel via Digitalmars-d-learn wrote:
> For years I missed the man pages of the C++ standard library and now
> found out that some Linux distros provide them as extra package. The
> man pages are not generated by a default during a GCC bootstrap
> install but need an explicit make doc-install-man in the corresponding
> doc directory of libstdc++.
> 
> Is there any such mechanism to generate man pages for D/Phobos?
> 
> Stefan

The current ddoc-based scheme may not be flexible enough to generate man
pages (though I could be wrong).  But something like Adam Ruppe's adrdox
could possibly be the basis for translating individual module symbols
into manpages perhaps?

Though I have to warn, working with troff/groff syntax is probably not
going to be pretty, esp. given the laxness / HTML-specificity of your
typical Phobos doc comment.  But perhaps it could be made to work...
Question is, who's gonna do the grunt work?


T

-- 
Computers shouldn't beep through the keyhole.

Re: 9999999999999999.0 - 9999999999999998.0

[Adam D. Ruppe via Digitalmars-d-learn]

On Sunday, 6 January 2019 at 00:20:40 UTC, Samir wrote:

import std.stdio: writeln;
void main(){
writeln(cast(double).0-9998.0);
}


That's because it is done at compile time, since both are 
compile-time constants. The compiler will evaluate it using the 
maximum precision available to the compiler, ignoring your 
request to cast it to double (which annoys some people who value 
predictability over precision btw). At different precisions, you 
get different results.


I suggest breaking it up into a different variable to force a 
runtime evaluation instead of using the compiler's constant 
folding.


import std.stdio: writeln;
void main(){
double d = .0;
writeln(d-9998.0);
}


This gives 1. Making it float instead of double, you get 
something different. With real (which btw is higher precision, 
but terrible speed), you get 1 - this is what the compiler 
happened to use at compile time.

9999999999999999.0 - 9999999999999998.0

[Samir via Digitalmars-d-learn]

I saw the following thread[1] today on Hacker News that discusses 
an article that compares how various languages compute 
.0 - 9998.0.  A surprisingly large 
number of languages return 2 as the answer.  I ran the following 
which returned 1:


import std.stdio: writeln;
void main(){
writeln(cast(double).0-9998.0);
}

I don't know anything about IEEE 754[2] which, according to the 
HN discussion, is the standard for floating point arthimetic, but 
was pleasantly surprised to see how D handles this.  Does anyone 
know why?


Thanks
Samir

[1] https://news.ycombinator.com/item?id=18832155
[2] https://en.wikipedia.org/wiki/IEEE_754

GCC 4.9.4 + GDC-patch: internal compiler error in libphobos/src/std/math.d:8040:47

[kdevel via Digitalmars-d-learn]

I applied the head

   commit ce249d880969111384d17f744687e427c843f1d4
   Merge: 8a6b7a4 0e517e4
   Author: Eugene Wissner 
   Date:   Tue Apr 10 15:37:32 2018 +0200

   Merge pull request #647 from belka-ew/gdc-49up

   Merge branch gdc-5 into gdc-4.9

of branch gdc-4.9 on top of gcc-4.9.4 and got this error:

/bin/sh ../libtool --tag=D   --mode=compile 
/scratch/mockbuild1/bld-4.9.4/gcc-objdir/./gcc/gdc 
-B/scratch/mockbuild1/bld-4.9.4/gcc-objdir/./gcc/ 
-B/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/bin/ 
-B/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/lib/ -isystem 
/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/include -isystem 
/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/sys-include -O2 
-g  -nostdinc -pipe -Wno-deprecated -I 
/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libphobos/src -I 
/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libphobos/libdruntime -I 
../libdruntime -I . -c -o std/net/curl.lo 
/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libphobos/src/std/net/curl.d
libtool: compile:  
/scratch/mockbuild1/bld-4.9.4/gcc-objdir/./gcc/gdc 
-B/scratch/mockbuild1/bld-4.9.4/gcc-objdir/./gcc/ 
-B/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/bin/ 
-B/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/lib/ -isystem 
/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/include -isystem 
/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/sys-include -O2 -g 
-nostdinc -pipe -Wno-deprecated -I 
/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libphobos/src -I 
/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libphobos/libdruntime -I 
../libdruntime -I . -c 
/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libphobos/src/std/net/curl.d  -fPIC -fversion=Shared -o std/net/.libs/curl.o

/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libphobos/src/std/math.d:8040:47: 
internal compiler error: Speicherzugriffsfehler
 return cast(Unqual!T) (T(1) << bsr(val) + type);
   ^
0x9e3b0f crash_signal
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/toplev.c:337
0xeb7af0 htab_hash_string
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libiberty/hashtab.c:839
0x7bc0f7 external_ref_hasher::hash(external_ref const*)
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/dwarf2out.c:7510
0x7bc0f7 hash_tablexcallocator>::find_slot(external_ref const*, insert_option)

   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/hash-table.h:505
0x7bc0f7 lookup_external_ref
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/dwarf2out.c:7538
0x7bc19d optimize_external_refs_1
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/dwarf2out.c:7576
0x7bc1c8 optimize_external_refs_1
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/dwarf2out.c:7580
0x7bc5ed optimize_external_refs
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/dwarf2out.c:7630
0x7bc9a5 output_comp_unit
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/dwarf2out.c:8816
0x7d7319 dwarf2out_finish
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/dwarf2out.c:24301
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Is GCC 4.9 still maintained?

D man pages

[kdevel via Digitalmars-d-learn]

For years I missed the man pages of the C++ standard library and 
now found out that some Linux distros provide them as extra 
package. The man pages are not generated by a default during a 
GCC bootstrap install but need an explicit make doc-install-man 
in the corresponding doc directory of libstdc++.


Is there any such mechanism to generate man pages for D/Phobos?

Stefan

Re: Vibe.d throw link error

[bauss via Digitalmars-d-learn]

On Saturday, 5 January 2019 at 18:44:33 UTC, greatsam4sure wrote:

On Friday, 4 January 2019 at 09:56:14 UTC, bauss wrote:

On Friday, 4 January 2019 at 09:48:55 UTC, greatsam4sure wrote:

On Thursday, 3 January 2019 at 04:57:57 UTC, Me wrote:
On Thursday, 3 January 2019 at 00:23:50 UTC, greatsam4sure 
wrote:

[...]


Windows 10 --- got it
VibeD project --- got it
Error --- got it

What exactly were you trying to do? What you have given so 
far offers no incite. Try providing a bit more information, 
offending code, cli command and associated arguments used, 
etc...



Really don't know the cause.  All dependence are up to date.

No offending code to the best of my knowledge.

All I did create a vibe.d project using dub unit HelloWorld 
--type=vibe.d


After which run the program in 's code using dub.

All dependence compile but after showing linking, it will 
throw link error.


I have run vibe.d project before. It just straight forward


Try to compile with -a=x86_mscoff if you're on Windows at 
least.






Thanks this work for me.  What is the reason I must add 
-a=x86-mscoff to dub before my code compiles.


What can I do to compile or run vibe.d project without adding 
-a=x86-mscoff to dub


Thanks in advance


Because the default linker for DMD is buggy so using the 
Microsoft linker will do the job.

Re: Vibe.d throw link error

[greatsam4sure via Digitalmars-d-learn]

On Friday, 4 January 2019 at 09:56:14 UTC, bauss wrote:

On Friday, 4 January 2019 at 09:48:55 UTC, greatsam4sure wrote:

On Thursday, 3 January 2019 at 04:57:57 UTC, Me wrote:
On Thursday, 3 January 2019 at 00:23:50 UTC, greatsam4sure 
wrote:

[...]


Windows 10 --- got it
VibeD project --- got it
Error --- got it

What exactly were you trying to do? What you have given so 
far offers no incite. Try providing a bit more information, 
offending code, cli command and associated arguments used, 
etc...



Really don't know the cause.  All dependence are up to date.

No offending code to the best of my knowledge.

All I did create a vibe.d project using dub unit HelloWorld 
--type=vibe.d


After which run the program in 's code using dub.

All dependence compile but after showing linking, it will 
throw link error.


I have run vibe.d project before. It just straight forward


Try to compile with -a=x86_mscoff if you're on Windows at least.






Thanks this work for me.  What is the reason I must add 
-a=x86-mscoff to dub before my code compiles.


What can I do to compile or run vibe.d project without adding 
-a=x86-mscoff to dub


Thanks in advance

Re: Co-developing application and library

[Neia Neutuladh via Digitalmars-d-learn]

On Sat, 05 Jan 2019 17:44:27 +, Neia Neutuladh wrote:
> 2. Different build configurations. The same source code has two
> different build targets; the executable doesn't depend on the library.
> Or, with enough bludgeoning, you can make the executable depend on the
> library.

Hit 'send' too soon.

The build configuration way would be:

---
# dub.sdl
configuration "exe" {
  targetType "executable"
}
configuration "lib" {
  targetType "staticLibrary"
  excludedSourceFiles "src/cli/*"
}
---

Then you'd build with:

dub build --config=lib
dub build --config=exe

To make this version of things yield an executable depending on a library, 
you'd use something like:

---
# dub.sdl
configuration "exe" {
  targetType "executable"
  excludedSourceFiles "src/lib/*"
  importPaths "src/lib"
  libs "-L." "-L-l:libmyproject.so"
}
configuration "lib" {
  targetType "sharedLibrary"
  excludedSourceFiles "src/cli/*"
}
---

The one advantage of this is being able to use shared libraries. It's 
awkward.

Re: Co-developing application and library

[Neia Neutuladh via Digitalmars-d-learn]

On Sat, 05 Jan 2019 13:01:24 +, Russel Winder wrote:
> Dub seems to have the inbuilt assumption that libraries are dependencies
> that do not change except via a formal release when you developing an
> application.
> Clearly there is the workflow where you want to amend the library but
> not release as a part of developing an application. Does Dub have a way
> of doing this, I haven't been able to infer one to date. But I am a
> beginner at Dub.

There are a few ways to do this:

1. Path dependency, as Alex mentioned.
2. Different build configurations. The same source code has two different 
build targets; the executable doesn't depend on the library. Or, with 
enough bludgeoning, you can make the executable depend on the library.
3. Subprojects.
4. dub add-local on the library, as Mike Parker mentioned.

I wouldn't depend on ~master because (a) that won't change until you 
commit stuff and (b) it might require also running dub upgrade to get the 
new source code.

The subproject way of doing things:

---
# dub.sdl
name "myproject"
targetType "none"
# So we build the child projects
dependency "myproject:lib" version="*"
dependency "myproject:exe" version="*"
# To define the child projects
subPackage "./lib"
subPackage "./exe"
---

---
# exe/dub.sdl
name "exe"
dependency "myproject:lib" version="*"
targetType "executable"
---

This will intuit a project structure like:

  dub.sdl
  exe/
dub.sdl
src/
  lib/
dub.sdl
src/

But if you prefer, you can modify that with "sourcePaths" in the 
subpackage dub.sdls.

Re: Compile time opAssign/@property constraints

[Jacob Shtokolov via Digitalmars-d-learn]

On Friday, 4 January 2019 at 14:36:16 UTC, Mike Parker wrote:

v is a run-time value, not available at compile time.


Sorry about that, looks like if I edit the text in the 
run.dlang.io editor, the link also gets updated. I was using 
"void opAssign(T)(T v)" in the initial example, but it seems that 
I got the idea.


So even if I'd write opAssign or @property as a template 
function, I won't be able to get their arguments at compile time 
because every template takes different set of arguments: for 
compile time and for run time.


And due to the fact that D is calling opAssign as 
obj.opAssign(arg) and not as obj.opAssign!(arg)(arg), this is not 
possible to get the runtime arguments.


On Saturday, 5 January 2019 at 01:38:43 UTC, Jonathan M Davis 
wrote:

I suggest that you read

https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time

IIRC, it's still a work in progress, but it should give you a 
much clearer idea of how CTFE fits into things.


Many thanks for this article! Now I understand it much better.

So it seems that the only "true way" is to use the struct 
invariant feature, but this will work only at run time.


It turned out that I just want some compile-time mechanism 
(static analyzer?) that will validate (solve) all reachable 
constraints in the program.


Then I'd like to reformulate the question: is there any tools or 
compiler features that are capable of validating asserts at 
compile time?


Thanks!

Re: Co-developing application and library

[Mike Parker via Digitalmars-d-learn]

On Saturday, 5 January 2019 at 15:17:28 UTC, Mike Parker wrote:
On Saturday, 5 January 2019 at 13:01:24 UTC, Russel Winder 
wrote:
Dub seems to have the inbuilt assumption that libraries are 
dependencies that do not change except via a formal release 
when you developing an application. Clearly there is the 
workflow where you want to amend the library but not release 
as a part of developing an application. Does Dub have a way of 
doing this, I haven't been able to infer one to date. But I am 
a beginner at Dub.


What I do is use `dub add-local /path/to/lib 0.0.1` and use 
that explicit version for development. That way, whatever 
repository branch is currently active in that directory becomes 
version 0.0.1 and I can make use of any changes.


Alternatively, I sometimes use the path to the library rather 
than a version specification in the package recipe. With the 
SDLang format:


dependency mylib path="path/to/lib"

Re: Co-developing application and library

[Mike Parker via Digitalmars-d-learn]

On Saturday, 5 January 2019 at 13:01:24 UTC, Russel Winder wrote:
Dub seems to have the inbuilt assumption that libraries are 
dependencies that do not change except via a formal release 
when you developing an application. Clearly there is the 
workflow where you want to amend the library but not release as 
a part of developing an application. Does Dub have a way of 
doing this, I haven't been able to infer one to date. But I am 
a beginner at Dub.


What I do is use `dub add-local /path/to/lib 0.0.1` and use that 
explicit version for development. That way, whatever repository 
branch is currently active in that directory becomes version 
0.0.1 and I can make use of any changes.

Re: Co-developing application and library

[Nicholas Wilson via Digitalmars-d-learn]

On Saturday, 5 January 2019 at 13:01:24 UTC, Russel Winder wrote:
Dub seems to have the inbuilt assumption that libraries are 
dependencies that do not change except via a formal release 
when you developing an application. Clearly there is the 
workflow where you want to amend the library but not release as 
a part of developing an application. Does Dub have a way of 
doing this, I haven't been able to infer one to date. But I am 
a beginner at Dub.


you can depend on ~master as a version, I'm not sure if you have 
to tell it to refresh what is has.

Re: Understanding SIGSEGV issues

[Nicholas Wilson via Digitalmars-d-learn]

On Saturday, 5 January 2019 at 12:14:15 UTC, Russel Winder wrote:
Indeed. I should do that to see if I can reproduce the problem 
to submit a proper bug report.


File_Ptr is wrapping a dvb_file * from libdvbv5 to try and make 
things a bit for D and to ensure RAII. libdvbv5 is a C API with 
classic C approach to handling objects and data structures.


My DStep/with manual binding is at 
https://github.com/russel/libdvbv5_d and the application using 
it (which is causing the problems) is at 
https://github.com/russel/DVBTune


Your problem possibly (probably?) stems from

auto channelsData = TransmitterData(args[1]).scan(frontendId);

The temporary TransmitterData(args[1]) is, well, temporary and 
its destructor runs after that expression is done. As the 
returned object from scan references data from the temporary, you 
have a stale pointer.


I have a feeling that I am really not doing things in a D 
idiomatic way.


Some driveby style comments then:


bool opEquals()(const FrontendId other) const {
if (this is other) return true;
if (other is null) return false;
		return this.adapter_number == other.adapter_number && 
this.frontend_number == other.frontend_number;

}


The compiler generated default opEquals will do basically the 
same thing. Ditto for the other types. You usually want to take a 
const ref for opEquals since there is no point copying it.



if (other is null)


I'm surprised the compiler doesn't warn or error on that as the 
only way that could make sense would be if it had an alias this 
to a pointer type.


You should consider reference counting your pointer wrapper 
types, FrontendParameters_Ptr/File_Ptr/ScanHandler_Ptr


You seem to like const, good! You don't need to take `const int`s 
as parameters, you're getting a copy anyway. You have a bunch of 
redundant casts as well.


I'll have another looks tomorrow when I'm a bit more awake.

Re: Co-developing application and library

[Alex via Digitalmars-d-learn]

On Saturday, 5 January 2019 at 13:01:24 UTC, Russel Winder wrote:
Dub seems to have the inbuilt assumption that libraries are 
dependencies that do not change except via a formal release 
when you developing an application. Clearly there is the 
workflow where you want to amend the library but not release as 
a part of developing an application. Does Dub have a way of 
doing this, I haven't been able to infer one to date. But I am 
a beginner at Dub.


I solved this by adding
"libraryName" : {"path" : "relative/path/to/library"}

to the dependency block

Co-developing application and library

[Russel Winder via Digitalmars-d-learn]

Dub seems to have the inbuilt assumption that libraries are dependencies that
do not change except via a formal release when you developing an application.
Clearly there is the workflow where you want to amend the library but not
release as a part of developing an application. Does Dub have a way of doing
this, I haven't been able to infer one to date. But I am a beginner at Dub.

-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



signature.asc
Description: This is a digitally signed message part

Re: Understanding SIGSEGV issues

[Russel Winder via Digitalmars-d-learn]

On Sat, 2019-01-05 at 11:30 +, Nicholas Wilson via Digitalmars-d-learn
wrote:
> 
[…]
> Could you post a minimised example? Its a bit hard to guess 
> without one.

Indeed. I should do that to see if I can reproduce the problem to submit a
proper bug report.

[…]
>  From the name, File_Ptr sounds like it is wrapping a reference to 
> a resource. So compare with C's FILE/ D's File which is a 
> reference counted wrapper of a FILE*. Would you ever use a File* 
> (or a FILE**)? Probably not, I never have.

File_Ptr is wrapping a dvb_file * from libdvbv5 to try and make things a bit
for D and to ensure RAII. libdvbv5 is a C API with classic C approach to
handling objects and data structures.

My DStep/with manual binding is at https://github.com/russel/libdvbv5_d and
the application using it (which is causing the problems) is at 
https://github.com/russel/DVBTune

I have a feeling that I am really not doing things in a D idiomatic way.

-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



signature.asc
Description: This is a digitally signed message part

Re: Understanding SIGSEGV issues

[Nicholas Wilson via Digitalmars-d-learn]

On Saturday, 5 January 2019 at 10:52:48 UTC, Russel Winder wrote:
I found the problem and then two minutes later read your email 
and bingo we have found the problem.


Well done.

Previously I had used File_Ptr* and on this occasion I was 
using File_Ptr and there was no copy constructor because I have 
@disable this(this). Except that clearly copying a value is not 
copying a value in this case. Clearly this situation is what is 
causing the destructor to be called on an unconstructed value. 
But I have no idea why.


Could you post a minimised example? Its a bit hard to guess 
without one.


The question now, of course, is should I have been using 
File_Ptr instead of File_Ptr* in the first place. I am 
beginning to think I should have been. More thinking needed.


From the name, File_Ptr sounds like it is wrapping a reference to 
a resource. So compare with C's FILE/ D's File which is a 
reference counted wrapper of a FILE*. Would you ever use a File* 
(or a FILE**)? Probably not, I never have.

Re: Understanding SIGSEGV issues

[Russel Winder via Digitalmars-d-learn]

On Sat, 2019-01-05 at 10:52 +, Russel Winder wrote:
> On Sat, 2019-01-05 at 10:31 +, Nicholas Wilson via Digitalmars-d-learn
> wrote:
> […]
> > Maybe it is a problem with copying a File_Ptr (e.g. missing a 
> > increase of the reference count)? Like, `auto a = File_Ptr(); { 
> > auto b = a; }` and b calls the destructor on scope exit.
> > That would be consistent with having problems copying to object 
> > to pass to writeln.
> 
> I found the problem and then two minutes later read your email and bingo we
> have found the problem.
> 
> Previously I had used File_Ptr* and on this occasion I was using File_Ptr
> and
> there was no copy constructor because I have @disable this(this). Except
> that
> clearly copying a value is not copying a value in this case. Clearly this
> situation is what is causing the destructor to be called on an unconstructed
> value. But I have no idea why.
> 
> The question now, of course, is should I have been using File_Ptr instead of
> File_Ptr* in the first place. I am beginning to think I should have been.
> More
> thinking needed.

Switching to using File_Ptr* I now get the SIGSEGV at the end of main as you
were thinking before. Oh f###.

This code used to work. :-(

-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



signature.asc
Description: This is a digitally signed message part

Re: Understanding SIGSEGV issues

[Russel Winder via Digitalmars-d-learn]

On Sat, 2019-01-05 at 10:31 +, Nicholas Wilson via Digitalmars-d-learn
wrote:
[…]
> 
> Maybe it is a problem with copying a File_Ptr (e.g. missing a 
> increase of the reference count)? Like, `auto a = File_Ptr(); { 
> auto b = a; }` and b calls the destructor on scope exit.
> That would be consistent with having problems copying to object 
> to pass to writeln.

I found the problem and then two minutes later read your email and bingo we
have found the problem.

Previously I had used File_Ptr* and on this occasion I was using File_Ptr and
there was no copy constructor because I have @disable this(this). Except that
clearly copying a value is not copying a value in this case. Clearly this
situation is what is causing the destructor to be called on an unconstructed
value. But I have no idea why.

The question now, of course, is should I have been using File_Ptr instead of
File_Ptr* in the first place. I am beginning to think I should have been. More
thinking needed.

-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



signature.asc
Description: This is a digitally signed message part

Re: Understanding SIGSEGV issues

[Nicholas Wilson via Digitalmars-d-learn]

On Saturday, 5 January 2019 at 07:34:17 UTC, Russel Winder wrote:
TransmitterData has a destructor defined but with no code in 
it. This used to work fine – but I cannot be certain which 
version of LDC that was.


The problem does seem to be in the construction of the 
TransmitterData object because a destructor is being called on 
the File_Ptr field as part of the transmitterData constructor.


As you can see from the stack trace #3, the File_Ptr is null. 
The solution to this is to either ensure it is initialised in 
the constructor of TransmitterData, or account for it possibly 
being null by defining a destructor for TransmitterData.


For some reason it seems File_Ptr.~this() is being called before
File_Ptr.this() in the TransmitterData.this(). This is totally 
weird.


Having added some writeln statements:

(gdb) bt
#0  0x555932e0 in dvb_file_free (dvb_file=0x0) at 
dvb_file.d:276
#1  0x55592fbc in types.File_Ptr.~this() (this=...) at 
types.d:83
#2  0x5558cdf6 in 
_D3std6format__T14formattedWriteTSQBg5stdio4File17LockingTextWriterTaTS5types8File_PtrZQCtFKQChxAaQBcZk (w=..., fmt=..., _param_2=...) at /usr/lib/ldc/x86_64-linux-gnu/include/d/std/format.d:472


Maybe it is a problem with copying a File_Ptr (e.g. missing a 
increase of the reference count)? Like, `auto a = File_Ptr(); { 
auto b = a; }` and b calls the destructor on scope exit.
That would be consistent with having problems copying to object 
to pass to writeln.