Mail Archives: cygwin/2002/08/05/20:58:31
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;
> free(digitList);
>};
>
>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
>behaviour.
no two objects are using digitList, hence no crossing over into the
twilight-zone.
>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.
mmmmm....
>Anyway, so you should THANK cygwin for finding the bugs in your
>code.
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:
http://photos.msn.com/support/worldwide.aspx
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -