Segmentation fault driven of a null reference in a c++ header file - c++

Question

Can anyone find out what is wrong with the following part of code:
private:
TUcdFileReader& operator = (const TUcdFileReader& r) { Fail; return *((TUcdFileReader *) 0); }
TUcdFileReader(const TUcdFileReader& r) { Fail; }
This belongs to a header file in a c library (SNAP) which I use in my code. When I compile my code in a linux based system, the below warning shows up:
Snap-2.1/glib-core/unicode.h(1678): warning #327: NULL reference is not allowed
TUcdFileReader& operator = (const TUcdFileReader& r) { Fail; return *((TUcdFileReader *) 0); }
Which in overall lead me to a segmentation fault as follows: (and I suspect it is because of the above warning)
WARNING: Job died due to SIGSEGV - Invalid memory reference
I dont write the whole header file since it is long and makes confusion, but it is the address of it: http://snap.stanford.edu/snap/doc/snapuser-ref/dd/d90/unicode_8h_source.html
Here I wrote the bigger part of header file that uses TUcdFileReader:
protected:
class TUcdFileReader
{
protected:
TChA buf;
public:
TChA comment; // contains '#' and everything after it
protected:
FILE *f;
int putBackCh;
int GetCh() {
if (putBackCh >= 0) { int c = putBackCh; putBackCh = EOF; return c; }
return fgetc(f); }
void PutBack(int c) { Assert(putBackCh == EOF); putBackCh = c; }
// Returns 'false' iff the EOF was encountered before anything was read.
bool ReadNextLine() {
buf.Clr(); comment.Clr();
bool inComment = false, first = true;
while (true) {
int c = GetCh();
if (c == EOF) return ! first;
else if (c == 13) {
c = GetCh(); if (c != 10) PutBack(c);
return true; }
else if (c == 10) return true;
else if (c == '#') inComment = true;
if (! inComment) buf += char(c);
else comment += char(c); }
/*first = false;*/}
private:
TUcdFileReader& operator = (const TUcdFileReader& r) { Fail; return *((TUcdFileReader *) 0); }
TUcdFileReader(const TUcdFileReader& r) { Fail; }
public:
TUcdFileReader() : f(0) { }
TUcdFileReader(const TStr& fileName) : f(0), putBackCh(EOF) { Open(fileName); }
void Open(const TStr& fileName) { Close(); f = fopen(fileName.CStr(), "rt"); IAssertR(f, fileName); putBackCh = EOF; }
void Close() { putBackCh = EOF; if (f) { fclose(f); f = 0; }}
~TUcdFileReader() { Close(); }
bool GetNextLine(TStrV& dest) {
dest.Clr();
while (true) {
if (! ReadNextLine()) return false;
TStr line = buf; line.ToTrunc();
if (line.Len() <= 0) continue;
line.SplitOnAllCh(';', dest, false);
for (int i = 0; i < dest.Len(); i++) dest[i].ToTrunc();
return true; }}
static int ParseCodePoint(const TStr& s) {
int c; bool ok = s.IsHexInt(true, 0, 0x10ffff, c); IAssertR(ok, s); return c; }
static void ParseCodePointList(const TStr& s, TIntV& dest, bool ClrDestP = true) { // space-separated list
if (ClrDestP) dest.Clr();
TStrV parts; s.SplitOnWs(parts);
for (int i = 0; i < parts.Len(); i++) {
int c; bool ok = parts[i].IsHexInt(true, 0, 0x10ffff, c); IAssertR(ok, s);
dest.Add(c); } }
static void ParseCodePointRange(const TStr& s, int& from, int &to) { // xxxx or xxxx..yyyy
int i = s.SearchStr(".."); if (i < 0) { from = ParseCodePoint(s); to = from; return; }
from = ParseCodePoint(s.GetSubStr(0, i - 1));
to = ParseCodePoint(s.GetSubStr(i + 2, s.Len() - 1)); }
};
Further, the only place that TUcdFileReader is called :
class TSubcatHelper
{
public:
bool hasCat; TUniChSubCategory subCat;
TStrH invalidCatCodes;
TUniChDb &owner;
TSubcatHelper(TUniChDb &owner_) : owner(owner_) { }
void ProcessComment(TUniChDb::TUcdFileReader &reader)
{
....

Answer 1

The class TUcdFileReader is specifically defined as NOT having assignment or copy constructors, i.e.
private:
TUcdFileReader& operator = (const TUcdFileReader& r)
{ Fail; return *((TUcdFileReader *) 0); }
TUcdFileReader(const TUcdFileReader& r) { Fail; }
looks like they are meant to fail.
Somewhere in the code they are being called - if you replacing those with:
private:
TUcdFileReader& operator = (const TUcdFileReader& r); //**not implemented**
TUcdFileReader(const TUcdFileReader& r); //**not implemented**
then you'd get a linker error. Best fix would be (if possible) to implement them.