[Tomas Kukosa <tomas.kukosa@xxxxxxxxxxx>]

Hi,
  I would have one question. Is it really necessary to use g_strdp() in following code 
(from packet-camel.c)?

  if (pinfo->private_data != NULL){
    version_ptr = strrchr(pinfo->private_data,'.');
    if (version_ptr) {
      version_str = g_strdup(version_ptr+1);
      application_context_version = atoi(version_str);
      g_free(version_str);
    }
  }

I guess following code should do the same:

  if (pinfo->private_data != NULL){
    version_ptr = strrchr(pinfo->private_data,'.');
    if (version_ptr) {
      application_context_version = atoi(version_ptr+1);
    }
  }

Maybe, I have omitted something and g_strdup() is really necessary.

Regards,
  Tom


ronnie sahlberg wrote:

> List,
>
> In my crusade to refactor all the sub-optimal memory management APIs
> into EMEMified functions (memory allocations that are automatic free()
> and have either a packet or capturefile allocation lifetime)
> I start to see that for the less well-maintained (i.e. not core
> TCP/IP, NAS or Telco protocols) there are memleaks and suboptimal code
> all over the map.
>
> Memleaks come in two kinds :
> The ones that are obvious, where memory is allocated temporarily
> during a single packet decode and never released
> and non-obvious ones where memory is allocated but "forgotten" due to
> an exception being raised.
>
>
> This reinforces my belief that we really should over time rip out all
> glib code and replace it with our own APIs.
>
>
> Gerald, maybe we should start a Janitor project? Where people can chip
> in and do reviews and look for the more obvious issues and at the same
> time get familiar with the code?  This would be a good starting point
> for someone wanting to get into developing ethereal software.
> (This is a HUGE amount of work and i dont think i can realistically do
> this on my own).
>
>
> The task is pretty easy, especially if one only focuses on the obvious
> memleaks and mem allocation uses, leaving the more hairy or difficult
> to trace allocation lifetimes until later.
> Im willing to mentor anyone being new to the ethereal source code
> wanting to help out.
>
>
> Gerald, what about an ethereal-janitor sub project and mailing list?
>
> First item I would propose
> Grep for g_malloc() in all the dissectors and pick them one by one,
> trace the allocation, lifespan and release of all memory and replace
> all the trivial ones one by one with ep/se_alloc().
> Do the trivial ones with obviously correct fixes first and leave the
> others for later.
>
>
>
> Anyone want to chip in?  There are still 140 g_malloc()s left in
> epan/dissectors  and if my current experience is worth anything  
> probably half of them will have obvious memleaks (i.e. never g_free())
> and virtually all the others have non-obvious ones (exception raised
> between g_malloc() and g_free() and no CLEANUP_PUSH or simiar kludge)
>
>
> raise your hand if you want to help out, its pretty boring work but
> should really be done.
> help in this very welcomed.
>
>
> best regards
>    ronnie sahlberg
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev

--
_________________________________________________

ANF DATA              ANF DATA spol. s r. o.
a SIEMENS Company     MediaHall, Bidláky 20
                      639 00 Brno
                      Czech Republic
Tomáš Kukosa          Tel.: +420 - 533 337 227
PSE ECT PSS 2         Fax : +420 - 533 337 252
Room: 2.64            mailto:tomas.kukosa@xxxxxxxxxxx
_________________________________________________