Re: [libdc1394-devel] MS Windows patch: avoiding clutter
Capture and control API for IIDC compliant cameras
Brought to you by:
ddouxchamps,
gordp
From: Vladimir A. <vl...@ya...> - 2007-08-14 02:09:47
|
--- Damien Douxchamps <ddo...@is...> wrote: >> Sorry, but I doubt anybody can read that message ;) >> >> Damien Sorry, that yahoo web mail again. I'll have to subscribe from different address. In the mean time here is that email again, now composed in icedove >> Hi Vladimir, > > On Fri, 2007-08-10 at 18:48 -0700, Vladimir Avdonin wrote: >> Hi, > > > > I submitted new version of patch to sf patch tracker. It >> removes the dll export prefix by exporting all symbols. It is updated to svn >> head as > > OK, at least I can read the 3 first lines of your email ;) Anyway, many > thanks for the update, it's *much* better this way. A couple of minor > questions: > > 1) regarding the new function "dc1394_free()". I don't fully understand > why it's necessary, but I'm not a C guru so I will let other tell what > they think about it. However, if it is indeed required then its name > should be more descriptive. Currently it looks like anything can be > freed by this function, while the intent is to free camera structs only. > Or maybe to free the camera vector (64 in length)? Please clarify. This is to address the situation when libdc1394 is used with application linked with different memory management library than libdc1394 itself. The dc1394_find_cameras allocates the memory using malloc version from library linked to libdc1394, and the application shall call free from the same library. On msw libdc1394 is built using gcc, but may be linked to application build with ms visual c and application will call its own version of free, which results in runtime error. dc1394_free will call correct version of free. I imagine that this situation may also happen in other cases, for example, when application is linked with some memory debugging library. So in order to be portable applications shall call dc1394_free. You may rename it to any other name you find better relaying its function > > 2) why are error handling macros not compiled for windows? Do you have a > replacing error handling mechanism? These macros are turned of by _MSC_VER predefined macro - it checks for microsoft compiler. not microsoft windows. When windows application is compiled with gcc the macros are still there. The reason they are turned off on msc is that these macros use variable arguments with gcc specific syntax which is not supported by ms compiler. > > 3) in dc1394/Makefile.am, "msw" has replaced "juju" in the definition of > DIST_SUBDIRS. I suppose that it's a typo and that msw should be added ;) > These macros are turned off by _MSC_VER predefined macro - it checks for microsoft compiler. not microsoft windows. When windows application is compiled with gcc the macros are still there. The reason they are turned off on msc is that these macros use variable arguments with gcc specific syntax which is not supported by ms compiler. > If no one has other comments I will merge the patch as soon as these > points are clarified. > > Thanks, > > Damien > > -- > _ Damien йЂШеОЯ Douxchamps > ('- Assistant Professor > //\ Image Processing Laboratory, NAIST > V_/_ http://damien.douxchamps.net/ > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Mailing list for libdc1394-devel > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libdc1394-devel > Regards, Vladimir |