Re: memory.h header

On Thu, 27 Feb 2020, 10bxjfhf wrote:

> In working to get my app to compile and run, I have run into an issue at some 
> point along the way which I eventually traced to the naming of a header in 
> the magick sub-directory.
>
> The file 'memory.h' caused conflicts with the another header of the same 
> name, possibly with that from the standard C library. The problem showed 
> while I was experimenting with the Magick API and went away if I switched to 
> use the Magick++ API.

Before memcpy() and other such functions were standardized to be 
declared in string.h, there were some/many legacy implementations 
which put them in memory.h.  As a result, it is still common for there 
to be a memory.h to support code which includes it.

> Because of this, this file is not an issue for me at this time, but I was 
> just wondering if it might not be better to rename this file to make it less 
> generic and more GM related?
>
> For files with same name I can adjust the paths in the MSVC IDE once I 
> recognize the cause, but it would be much simpler, safer and quicker to aviod 
> the issue altogether.

This MSVC weakness is really annoying.  The GraphicsMagick code always 
includes its own memory.h like "magick/memory.h" so if the include 
path includes the parent of "magick" all should be safe.  If the 
include path also includes the contents of the "magick" directory, 
then there may be problems.  Hopefully the GraphicsMagick project 
itself does not have this issue.  A solution is to always include 
GraphicsMagick headers like "magick/api.h" and make sure that the 
using project does not directly include headers from the magick 
directory

Bob
-- 
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt