Wireshark-dev: Re: [Wireshark-dev] [Wireshark-bugs] [Bug 1179] cmake build integration + dbus +
On Monday 06 November 2006 11:16 pm, Ulf Lamping wrote:
> bugzilla-daemon@xxxxxxxxxxxxx wrote:
> > Please do not confuse the bug that I may have introduced, and the
> > wireshark/glib bugs.
>
> THERE ARE NO WIRESHARK BUGS THAT YOU'VE FIXED (beside some very
> unimportant memory leaks)!!!
>
and some uninitialized variables, use of stale pointer and stale file
descriptor ...
They are not unimportant or important memory leak, they are all leaks that
needs to be fixed.
> There are "crashes" in the dumpcap code as you've not used it as
> designed. Then you've fixed the newly occuring problems at the wrong
> places.
A robust a software is a software that can be modified and enhanced without
collaping like a card castle. Wireshark is everything but robust.
>
> Randomly setting a pointer to NULL somewhere in the code and waiting for
> the program to crash would show exactly the same problems.
>
> I won't give you any further examples as I will only get in return that
> the WS code was badly designed before and there are bugs in other pieces
> of the code that needs to be fixed for your code to run.
>
I kindly ask you where are the bug you find, the only response is the complain
about the some pointer has been tested, some pointer that has been set to
NULL after being freed !
These are not bugs but is an effort to make wireshark more robust and less
error prone. What's wrong with that ?
> > Where are the bugs you find that are not related to glib ?
> > Could you explain me why you treat the code as "buggy by design" ? Be
> > constructive and propose something better.
>
> I was constructive several times and only got the response that you
> disagree with my (and other core developers) points of view.
>
> With "buggy by design" I mean that you seem to simply ignore how the
> code was written before,
> partially fix problems introduced by your own changes and then complain
> that the Wireshark code needs to be fixed.
>
Written with tons of globals variables, 2000 lines functions, non thread safe,
pointer not tested, memory leak, uninitialized variables etc.... A weekly
update due to multiple vulnerabilities.
> I just don't want to spend any more time discussing on that level,
>
> Regards, ULFL
______________________________________________________________________________
--- NOTICE ---
CONFIDENTIALITY - This email and any attachments are confidential and are
intended for the addressee only. If you have received this message by
mistake, please contact us immediately and then delete the message from your
system. You must not copy, distribute, disclose or act upon the contents of
this email. Thank you.
PERSONAL DATA PROTECTION (Law by Decree 30.06.2003 n. 196) - Personal and
corporate data submitted will be used in a correct, transparent and lawful
manner. The data collected will be processed in paper or computerized form for
the performance of contractual and lawful obligations as well as for the
effective management of business relationship. Data may be disclosed, in Italy
or abroad, for the purpose above mentioned to third parties which cooperate
with Telsey, agents, banks, factoring companies, credit recovering companies,
credit insurance companies, professional and consultants, and shipping
companies. In relation to the same purposes, data may be processed by the
following classes of executors or processors: management; administration
department; logistics and purchase department; sales department; post sales
department quality department; R&D department; IT department; legal department.
The data processor is Telsey S.p.A. The data subject may exercise all the
rights set forth in art. 7 of Law by Decree 30.06.2003 n. 196 as reported in
in the following link http://www.telsey.it/privacy.jsp.
______________________________________________________________________________
798t8RfNa6Dl8Ilf
