#ifdef __WIN32__ # define OPEN_MODE_OVERWRITE "wb"# define OPEN_MODE_WRITE "w+b" # define OPEN_MODE_READ "rb" #else # define OPEN_MODE_OVERWRITE "w" # define OPEN_MODE_WRITE "w+b" # define OPEN_MODE_READ "rb" #endif /* __WIN32__ */
Because windows' fopen() by default opens files in "text mode" which causes fread() to do character translations -- for examle CRLF = LF, \0 = EOF, etc. Since this code tries to be portable, we define these macros to make windows fopen() and fread() behave more like fopen() and fread() in POSIX environments. On 9/13/07, Daniel Corbe <[EMAIL PROTECTED]> wrote: > > Rob, > > I've tried building my app on both debug and release, and the same thing > happens. You're saying there may be something wrong with my > build environment? I'm not entirely convinced of that but I won't rule it > out as a possibility. > > > I'm running Visual C++ Express 2005 (which is basically VC8, if you > actually paid for a copy) > Microsoft Windows 2003 Server R2 Platform SDK > > > It's all basically the latest and greatest non-beta stuff that Microsoft > has out right now. > > > libxml2-2.6.30 (binary) as gotten from: > http://www.zlatkovic.com/libxml.en.html > > > Why would I run into heap corruption issues unless there's something > blatantly wrong with xmlDocDump. > > > My understanding of HEAP vs STACK memory is that local variables come from > the stack and global variables along with anything malloc() comes off of the > heap. Heap memory is essentially limited only by the amount of physical RAM > and virtual memory in your machine whereas your call stack is generally > limited to 1Mbit per thread by default on Windows. > > > If anything I would say that there's a stack corruption issue here, not a > heap corruption issue, and that could easily be caused somewhere else in the > code (my code) without me noticing. > > > The default stack size in most Linux distributions is unlimited or some > very high number so I could easily see how I may have missed a stack issue. > Issues with the heap tend to be more visible (in the form of crashes) and > obvious (dereferencing null or uninitialized pointers, reading/writing > out-of-bounds, etc) > > > That's a semantic point at any rate. > > > It's beginning to look like I'm going to need to fetch the source and > compile it myself so that I can give you more useful debugging information > :( > > > xmlDocDump is the cleaner approach in this case than xmlSaveFile. The > reason being is that the xmlSaveFile documentation clearly states that > compression is used by default if it is compiled in to the library and this > is a bad thing for general deployment. > > > -Daniel > > > On 9/13/07, Rob Richards <[EMAIL PROTECTED]> wrote: > > > > Daniel Corbe wrote: > > > Sorry but I must reject this notion. You're trying to say that it's > > > broken the way I'm using it, but just on Windows? Because like I said > > > on Linux it runs fine. > > I am saying that it was either that or you are mixing release and debug > > versions and probably running into a problem on the HEAP somewhere. > > Just to make sure this wasn't something new, I did try your example code > > and it worked flawlessly (hardcoding path names of course and using "wb" > > for mode as I have no idea what you defined OPEN_MODE_OVERWRITE as). > > > > I used both a debug version of libxml2 and my calling executable. They > > were both built with VS 2005 and I'll test again later building the > > executeable against a VC6 version of libxml2. > > > > > > > > I'm trying to do something EXTREMELY simple here. See below. In my > > > experience if xmlReadFile fails I get a bunch of things to stderr > > > about why and my program then exists. > > > > > > And I have also verified with a debugger that mtp3 is indeed a valid > > > pointer. So if mtp3 is a valid and parsed and my FILE*xml is also a > > > valid pointer, xmlDocDump would have no reason to fail. > > > > > > I have attached some screenshots highlighting the failure. > > > > > > /* Begin code snippet */ > > > xmlDocPtr mtp3; > > > FILE *xml; > > > > > > mtp3 = xmlReadFile(config->MTP3filename, NULL, 0); > > > xml = fopen(config->MTP3filename, FOPEN_MODE_OVERWRITE); > > > if (!xml || ferror(xml)) > > > { > > > > > > outputf("ERROR WRITING MTP3 XML File: %s\n", strerror(errno)); > > > } > > > else > > > { > > > xmlDocDump(xml, mtp3); > > > fclose(xml); > > > } > > Try a debug version of libxml2 and if it crashes then, you should be > > able to find out why at least because I cannot reproduce your crash. > > > > Rob > > > > >
_______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
