This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: BUG - Cygwin to GNU CC compatibility

Hi Ernest,

If your program runs on a bunch of systems, well, you're just lucky,
because the bugs are in your code, not in cygwin.
i doubt the efforts of the cygwin group can surpass those of borland
and GCC and now after recieving your mail visual c++
It seems that all these systems can produce perfectly running
executables, running both on linux, solaris and windows.

I don't think there is any luck involved in this, there is a bug and it
needs to be fixed. out of the 4 compilers i compiled this code on only
cygwin was the one to fail.

You've provided a
constructor (whitespace edited to make this email shorter)

DigitList::DigitList(DigitList const &diglst) {
    *this = diglst;

this is a perfectly valid copy constructor.

which just invokes, implicitly, the default copy constructor. This
default copy constructor would look something like this:

DigitList::DigitList(DigitList &diglst) {
    this.digitList = diglist.digitList; // *** This line
    this.listSize = diglist.listSize;
when you do the copy constructor the whole object and its variable
contents is copied automaically no need for any of the stuff you
just wrote.

The line I've marked with a *** is the trouble maker -- it makes an
alias for the pointer member digitList (which is effectively an
int*). When you copy a DigitList using this copy ctor, you get two
DigitLists sharing a single digitList pointer.

The program does not any any way use any variable more than once,
not in the test that i have given you nor in the actuall class code.
So what you are saying is not possible, and hence if you think it
is occuring instead of writing about it, just give a simple answer
like on line so and so this is happening. if you give an example of
it then i will accept your argument :D

Now, in your dtor:

DigitList::~DigitList() {
   listSize = 0;

you free digitList. But if two objects sharing a digitList both delete
the same pointer, then you've crossed over into the realm of undefined
no two objects are using digitList, hence no crossing over into the

The implementation is allowed to do anything now: it can
keep running without a problem, it can crash (as cygwin's newlib is
apparently doing) or it can send dirty pictures of itself to the
White House.

Anyway, so you should THANK cygwin for finding the bugs in your
I  found a bug in cygwin not the other way round. it can't handle
not initialised object parameter passing or something else.

BTW, 1) why are you using free and malloc instead of new and
delete, anyway?
if you actually looked at the code, malloc was used for the
initialisation of a structure not a class, i don't know where you
come from but on earth we use malloc to initialise and structure
on memory according to its size.

and 2) Why are you writing a class like DigitList in the
first place -- why not simply use a vector<int>? and
becuase its my prerogative to write such a class, i do not
want to use the stl.

3) I've only pointed out ONE of your memory management bugs. There are plenty more in this code.
feel free to point out more if you can find any, i will continue issue
this as a bug to cygwin.
until either a patch comes along or someone can explain why it works
on every other os and compiler except for when its compiled by cygwin.

MSN Photos is the easiest way to share and print your photos:

Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]