From boris at codesynthesis.com Tue Aug 3 09:29:50 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Aug 3 09:22:10 2010 Subject: [xsde-users] Free proprietary license for small XML vocabularies Message-ID: Hi, We have introduced a free proprietary license for XSD/e. The new license allows you to use the generated code to handle small XML vocabularies in proprietary (closed-source) applications free of charge and without having to publish your source code. The license allows you to target any number of platforms and upgrade to any future releases of XSD/e. It comes with best-effort, community support via the xsde-users mailing list. For more information as well as for answers to common questions about the new license visit the Free Proprietary License page: http://www.codesynthesis.com/products/xsde/free-license.xhtml Enjoy, Boris From boris at codesynthesis.com Thu Aug 12 09:59:45 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Aug 12 09:50:14 2010 Subject: [xsde-users] Re: [xsd-users] Using a SAX parser in cxx-tree In-Reply-To: <697816250.318611281607315066.JavaMail.root@zimbra36-e6.priv.proxad.net> References: <1618081182.318591281607286205.JavaMail.root@zimbra36-e6.priv.proxad.net> <697816250.318611281607315066.JavaMail.root@zimbra36-e6.priv.proxad.net> Message-ID: <20100812135945.GA4089@onega.codesynthesis.com> Hi Ivan, Can you please send questions about XSD/e to the xsde-users mailing list (CC'ed) instead of xsd-users. Ivan Le Lann writes: > I fed it with a schema with no namespace : > > [...] > > xml_schema::document_simpl doc_s ( > catalog_s.root_serializer (), > catalog_s.root_namespace (), > catalog_s.root_name ()); If your schema doesn't have a target namespace, then you should use this version of the document_simpl constructor: xml_schema::document_simpl doc_s ( catalog_s.root_serializer (), catalog_s.root_name ()); Boris From boris at codesynthesis.com Wed Aug 25 10:37:43 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Aug 25 10:29:24 2010 Subject: [xsde-users] Re: Errors when using VS2008 express and MinGW (latest version) In-Reply-To: References: Message-ID: Hi Terry, In the future please send technical questions like this about XSD/e to the xsde-users mailing list (which I've CC'ed to my reply). Also see the posting guidelines: http://www.codesynthesis.com/support/posting-guidelines.xhtml O'Laughlin, Terry writes: > I guess I still haven't got my build environment stabilized. Not that > I haven't been trying a lot of various things. Just read where you > suggested NOT to use a VS project file. Okay, so I've had the same > error below with VS 2008express and MinGW, both executed using the > command line. If you are planning to target VxWorks 5.x but want to develop on Windows using one of the VC++ compilers, then the most sensible thing to do is to start with VC++ configuration file and then disable all the features that are not available on your target by looking at the VxWorks config file. In your case this would translate to: 1. Take the standard config/config.nmake 2. Look through etc/vxworks/config-5.5.1.make and disable every feature in the above config.nmake file that is not enabled in config-5.5.1.make. This will include things like STL, exceptions, iostream, etc. The resulting configuration will be very minimal which means you won't be able to build most of the examples (they require C++ features that are not available in your configuration). But the 'minimal' example should build and it shows all the major XSD/e operations (parsing, serialization, object model access and modification, error handling, etc) that should be sufficient to get you started. Boris > > I'll eventually get the hang of this. > > Cheers, > > Terry O' > > > > C:\xsde\examples\cxx\hybrid\hello>nmake -f nmakefile > > Microsoft (R) Program Maintenance Utility Version 9.00.30729.01 > Copyright (C) Microsoft Corporation. All rights reserved. > > cl.exe -D_CRT_SECURE_NO_DEPRECATE /I..\..\..\..\libxsde /nologo /W3 /EHs /c /TP driver.cxx /Fodriver.obj > driver.cxx > c:\xsde\examples\cxx\hybrid\hello\hello.hxx(46) : fatal error C1189: #error : the generated code uses long long while t > he XSD/e runtime does not (reconfigure the runtime or add --no-long-long) > NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\cl.exe"' : return code '0x2' > Stop. > > C:\xsde\examples\cxx\hybrid\hello> From klaus at bitstem.com Thu Aug 26 08:09:49 2010 From: klaus at bitstem.com (Klaus Kuehnhammer) Date: Thu Aug 26 08:10:11 2010 Subject: [xsde-users] State stack: memory corruption for stacks >= 8, with patch Message-ID: <1282824589.4036.27.camel@chicken-distillery> Hi, I've run into memory corruption with XSD/E 3.1.0 on Linux, and have found two issues with the way the state stack is handled. For me this happens when the stack is grown beyond its default depth of 8 in a sequence, so to reproduce you need to use XML input that nests the tags at least 8 levels deep. - in stack.ixx (libxsde), push() grows the stack one call too late, causing top() to point beyond the allocated region when the stack size reaches the default of 8. - in the generated _start_element_impl, top() is called once before the recursive state machine calls. If the stack is grown during this, the existing states are copied to a new memory location (grow() in stack.cxx). The element-local reference vs is never updated and still reads from the old, already delete[]'d stack buffer. I'm attaching a patch against the 3.1.0+dep source distribution that fixes these issues for my schema.. i was reluctant to touch anything beyond the choice/sequence validator code generation, so it's entirely possible that the second situation (stale vs) can arise somewhere else too. I avoid the stale vs issue by updating it through a last() method I added to the stack: it gets the element last pushed in, even if the buffer has been grown and moved somewhere else. There might be a more elegant solution. The fix for the first issue simply makes sure grow() is called as soon as the stack is full. Hope that helps! Klaus -- Bitstem Software Klaus Kuehnhammer Wasnergasse 11/5 1200 Wien, Austria +43 664 2133466 klaus@bitstem.com -------------- next part -------------- A non-text attachment was scrubbed... Name: xsde-3.1.0-state-stack.patch Type: text/x-patch Size: 3595 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsde-users/attachments/20100826/50426449/xsde-3.1.0-state-stack.bin From boris at codesynthesis.com Thu Aug 26 10:37:41 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Aug 26 10:29:26 2010 Subject: [xsde-users] State stack: memory corruption for stacks >= 8, with patch In-Reply-To: <1282824589.4036.27.camel@chicken-distillery> References: <1282824589.4036.27.camel@chicken-distillery> Message-ID: Hi Klaus, Klaus Kuehnhammer writes: > - in stack.ixx (libxsde), push() grows the stack one call too late, > causing top() to point beyond the allocated region when the stack size > reaches the default of 8. The bug is actually in top(), not in push(). The top() function incorrectly returns one element past the current. I have fixed this and the patch is available here: http://scm.codesynthesis.com/?p=xsde/xsde.git;a=commitdiff;h=38fc036f9884a0f4c1a6ed1e684dc39938b2539f;hp=ce65e0086daf4458209118e9935609950e387b13 > - in the generated _start_element_impl, top() is called once before the > recursive state machine calls. If the stack is grown during this, the > existing states are copied to a new memory location (grow() in > stack.cxx). The element-local reference vs is never updated and still > reads from the old, already delete[]'d stack buffer. Hm, I analyzed the code in _start_element_impl() and I don't see how this is possible. The only call that can grow the stack is the call to one of compositor functions at the end of the function. But after that call the stack is not accessed. I think here is what happens: because your fix for the first issue is not correct, you are still observing the effect of this bug. In fact, I managed to reproduce it on our tests by lowering the initial capacity. Without the fix under valgrind I see invalid memory accesses while with the fix everything runs cleanly. Can you try to apply the patch above and see if this fixes everything without your patch for the second problem. And thanks for reporting this! Boris From boris at codesynthesis.com Fri Aug 27 14:07:22 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Aug 27 13:59:13 2010 Subject: [xsde-users] State stack: memory corruption for stacks >= 8, with patch In-Reply-To: <1282838786.4036.62.camel@chicken-distillery> References: <1282824589.4036.27.camel@chicken-distillery> <1282838786.4036.62.camel@chicken-distillery> Message-ID: Hi Klaus, I have CC'ed xsde-users to my reply. Klaus Kuehnhammer writes: > I still get the memory issues I described in the second point using your > patch. Yes, you are right. I was concentrating on the code after the loop while it is the code in the loop that has the problem. My solution is to re-implement the stack so that it doesn't move elements: http://scm.codesynthesis.com/?p=xsde/xsde.git;a=commit;h=14b909b25dec8e68f7bcb35e89ce503c5f12967c It will probably be easier to just copy the whole stack.?xx files than apply the patch. Let me know if you get any problems with this. Boris [The rest of the original email follows for context.] > > Putting some printfs in the stack push and start_element code shows that > the stack is definitely grown by something (the (this->*vd->func) > calls? ) before vs is read back: > > push () > { > if (size_ > capacity_) > { > printf("%p: growing stack, old buffer at %p, top %p\n", this, data_, > top()); > #ifdef XSDE_EXCEPTIONS > grow (); > #else > if (error e = grow ()) > return e; > #endif > > printf("%p: new buffer at %p, top %p\n", this, data_, top() ); > } > > ------------------------------------------------------------------------------- > > _start_element_impl (const ::xsde::cxx::ro_string& ns, > const ::xsde::cxx::ro_string& n) > { > ::xsde::cxx::parser::context& ctx = this->_context (); > > v_state_& vs = *static_cast< v_state_* > (this->v_state_stack_.top > ()); > v_state_descr_* vd = vs.data + (vs.size - 1); > printf("set vs\n"); > > if (vd->func == 0 && vd->state == 0) > { > typedef ::xsde::cxx::parser::validating::complex_content base; > if (base::_start_element_impl (ns, n)) > return true; > else > vd->state = 1; > } > > while (vd->func != 0) > { > (this->*vd->func) (vd->state, vd->count, ns, n, true); > > printf("read vs\n"); > vd = vs.data + (vs.size - 1); > > if (vd->state == ~0UL && !ctx.error_type ()) > vd = vs.data + (--vs.size - 1); > else > break; > } > > ------------------------------------------------------------------------------- > > log: > > read vs > set vs > set vs > 0x7feffc5a0: growing stack, old buffer at 0x8511660, top 0x85116d0 > 0x7feffc5a0: new buffer at 0x8513f70, top 0x8513fe0 > 0x7feffc468: growing stack, old buffer at 0x8511720, top 0x85117c8 > 0x7feffc468: new buffer at 0x85140b0, top 0x8514158 > 0x7feffc568: growing stack, old buffer at 0x8511820, top 0x8511827 > 0x7feffc568: new buffer at 0x8514270, top 0x8514277 > 0x7feffc538: growing stack, old buffer at 0x8511870, top 0x8511b48 > 0x7feffc538: new buffer at 0x85142c0, top 0x8514598 > read vs > > after this, valgrind reports reads from the old buffer that has just > been deleted. > > The XML input that triggers this is structured like this: > > > > > > > > > > > > > > > > > > > > > > > > > > > From Terry.O'Laughlin at ipc.com Thu Aug 26 13:37:54 2010 From: Terry.O'Laughlin at ipc.com (O'Laughlin, Terry) Date: Fri Aug 27 14:07:25 2010 Subject: [xsde-users] Error with Build Environment? 'windows.h' file not found; host:Windows target: VxWorks 5.5.1 Message-ID: Windows host VxWorks 5.5.1 (860PPC) target Config\Config.make : I've copied the etc\vxworks\config-5.5.1.make When trying to build the libxsde library on my host platform for the target environment, I receive an error that 'windows.h' cannot be included: no file or directory. This occurs in the file: C:\xsde\libxsde\xsde\c\expat\xmlparse.c :line 11 #include Where am I supposed to pickup the 'windows.h' file? I have 'windows.h' in 3 separate places on my host platform: Vxworks-> \host\x86-win32\i386-pc-mingw32\sys-include VC6++ -> \include VS8 -> \include To do develop using a windows platform, target vxworks, what windows-based compiler environment do I need? How do I install and configure? What does XSD/e build makefiles expect? Being relatively new to vxworks, do I need to set a configuration setting in my VxWorks installation? Why does it need 'windows.h' anyway? The target is VxWorks. I can successfully build the libxsde library on windows, target windows. No Problem. Thanks, Terry O' Terry O'Laughlin Sr. Software Engineer IPC TS Engineering Alliance Sustaining Dept. 777 Commerce Drive Fairfield, CT 06825 phone: 203-339-7987 fax: 203-339-7809 www.ipc.com Terry.O'Laughlin@ipc.com ________________________________ DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems. [cid:green-logo42e4.jpg]Please consider the environment before printing this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: green-logo42e4.jpg Type: image/jpeg Size: 1268 bytes Desc: green-logo42e4.jpg Url : http://codesynthesis.com/pipermail/xsde-users/attachments/20100826/7d660dc3/green-logo42e4.jpg From Terry.O'Laughlin at ipc.com Fri Aug 27 13:25:22 2010 From: Terry.O'Laughlin at ipc.com (O'Laughlin, Terry) Date: Fri Aug 27 14:07:42 2010 Subject: [xsde-users] Rumour has it... enumeration support in V3.2 out soon? Message-ID: Hi, I think I saw in previous postings that V3.2 will be out sometime in Sept. and that it will include support (better) support of XML enumeration data types? I may not be using the correct XML words to describe my request. In fact I'm doing some research on using enumerations with XML and how to define the schema. Our project will be using enumerations (as much as we can). Would it make sense for us to get V3.2 early? (That is without causing you guys grief.) Cheers, Terry O' Terry O'Laughlin Sr. Software Engineer IPC TS Engineering Alliance Sustaining Dept. 777 Commerce Drive Fairfield, CT 06825 phone: 203-339-7987 fax: 203-339-7809 www.ipc.com Terry.O'Laughlin@ipc.com ________________________________ DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems. [cid:green-logo4509.jpg]Please consider the environment before printing this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: green-logo4509.jpg Type: image/jpeg Size: 1268 bytes Desc: green-logo4509.jpg Url : http://codesynthesis.com/pipermail/xsde-users/attachments/20100827/6d64df6d/green-logo4509.jpg From boris at codesynthesis.com Fri Aug 27 14:22:31 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Aug 27 14:14:21 2010 Subject: [xsde-users] Error with Build Environment? 'windows.h' file not found; host:Windows target: VxWorks 5.5.1 In-Reply-To: References: Message-ID: Hi Terry, O'Laughlin, Terry writes: > Windows host > VxWorks 5.5.1 (860PPC) target > Config\Config.make : I've copied the etc\vxworks\config-5.5.1.make > > When trying to build the libxsde library on my host platform for the > target environment, I receive an error that 'windows.h' cannot be > included: no file or directory. To things to double-check: 1. In your config/config.make, XSDE_PLATFORM is set to posix. 2. You are running make (comes with the VxWorks dev environment) and not Microsoft nmake to build libxsde. This can be confusing if you use VC++ for development: you build VC++ version of libxsde with nmake (and config/config.nmake is used) while you build VxWorks version of libxsde with make (and config/config.make is used). Boris From boris at codesynthesis.com Fri Aug 27 14:52:51 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Aug 27 14:44:41 2010 Subject: [xsde-users] Rumour has it... enumeration support in V3.2 out soon? In-Reply-To: References: Message-ID: Hi Terry, O'Laughlin, Terry writes: > I think I saw in previous postings that V3.2 will be out sometime > in Sept. and that it will include support (better) support of XML > enumeration data types? That's correct, though the release will most likely only happen in early October. > Our project will be using enumerations (as much as we can). Would > it make sense for us to get V3.2 early? (That is without causing > you guys grief.) Sure, you can get the latest pre-release from here: http://www.codesynthesis.com/~boris/tmp/xsde-3.2.0.a6-i686-windows.zip Take a look at the NEWS file inside for the new features in this release (there are other things besides the mapping of XML Schema enumerations to C++ enum and validation of enumerations). Boris From klaus at bitstem.com Sat Aug 28 08:33:52 2010 From: klaus at bitstem.com (Klaus Kuehnhammer) Date: Sat Aug 28 08:34:00 2010 Subject: [xsde-users] State stack: memory corruption for stacks >= 8, with patch In-Reply-To: References: <1282824589.4036.27.camel@chicken-distillery> <1282838786.4036.62.camel@chicken-distillery> Message-ID: <1282998832.2071.0.camel@chicken-distillery> Hi Boris, that seems to do it, thanks! Klaus On Fri, 2010-08-27 at 20:07 +0200, Boris Kolpackov wrote: > Hi Klaus, > > I have CC'ed xsde-users to my reply. > > Klaus Kuehnhammer writes: > > > I still get the memory issues I described in the second point using your > > patch. > > Yes, you are right. I was concentrating on the code after the loop > while it is the code in the loop that has the problem. > > My solution is to re-implement the stack so that it doesn't move > elements: > > http://scm.codesynthesis.com/?p=xsde/xsde.git;a=commit;h=14b909b25dec8e68f7bcb35e89ce503c5f12967c > > It will probably be easier to just copy the whole stack.?xx files > than apply the patch. > > Let me know if you get any problems with this. > > Boris > > > [The rest of the original email follows for context.] > > > > > Putting some printfs in the stack push and start_element code shows that > > the stack is definitely grown by something (the (this->*vd->func) > > calls? ) before vs is read back: > > > > push () > > { > > if (size_ > capacity_) > > { > > printf("%p: growing stack, old buffer at %p, top %p\n", this, data_, > > top()); > > #ifdef XSDE_EXCEPTIONS > > grow (); > > #else > > if (error e = grow ()) > > return e; > > #endif > > > > printf("%p: new buffer at %p, top %p\n", this, data_, top() ); > > } > > > > ------------------------------------------------------------------------------- > > > > _start_element_impl (const ::xsde::cxx::ro_string& ns, > > const ::xsde::cxx::ro_string& n) > > { > > ::xsde::cxx::parser::context& ctx = this->_context (); > > > > v_state_& vs = *static_cast< v_state_* > (this->v_state_stack_.top > > ()); > > v_state_descr_* vd = vs.data + (vs.size - 1); > > printf("set vs\n"); > > > > if (vd->func == 0 && vd->state == 0) > > { > > typedef ::xsde::cxx::parser::validating::complex_content base; > > if (base::_start_element_impl (ns, n)) > > return true; > > else > > vd->state = 1; > > } > > > > while (vd->func != 0) > > { > > (this->*vd->func) (vd->state, vd->count, ns, n, true); > > > > printf("read vs\n"); > > vd = vs.data + (vs.size - 1); > > > > if (vd->state == ~0UL && !ctx.error_type ()) > > vd = vs.data + (--vs.size - 1); > > else > > break; > > } > > > > ------------------------------------------------------------------------------- > > > > log: > > > > read vs > > set vs > > set vs > > 0x7feffc5a0: growing stack, old buffer at 0x8511660, top 0x85116d0 > > 0x7feffc5a0: new buffer at 0x8513f70, top 0x8513fe0 > > 0x7feffc468: growing stack, old buffer at 0x8511720, top 0x85117c8 > > 0x7feffc468: new buffer at 0x85140b0, top 0x8514158 > > 0x7feffc568: growing stack, old buffer at 0x8511820, top 0x8511827 > > 0x7feffc568: new buffer at 0x8514270, top 0x8514277 > > 0x7feffc538: growing stack, old buffer at 0x8511870, top 0x8511b48 > > 0x7feffc538: new buffer at 0x85142c0, top 0x8514598 > > read vs > > > > after this, valgrind reports reads from the old buffer that has just > > been deleted. > > > > The XML input that triggers this is structured like this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From Terry.O'Laughlin at ipc.com Sun Aug 29 19:31:54 2010 From: Terry.O'Laughlin at ipc.com (O'Laughlin, Terry) Date: Sun Aug 29 19:31:58 2010 Subject: Solved .... FW: [xsde-users] Error with Build Environment? 'windows.h' file not found; host:Windows target: VxWorks 5.5.1 Message-ID: Hi Boris, My problem was that I didn't do a 'clean' to delete libxsde/xsde/config.h. I originally generated code for the windows target. When I changed my config file to attempt to build VxWorks, well because the config.h file still defined the platform as 'win32' (instead of 'posix' as it should) it tried to include 'windows.h' Deleting config.h, then starting 'make' cleared up this problem. ----------------------------------------------------- Please consider the environment before printing this email. -----Original Message----- From: xsde-users-bounces@codesynthesis.com [mailto:xsde-users-bounces@codesynthesis.com] On Behalf Of O'Laughlin, Terry Sent: Thursday, August 26, 2010 1:38 PM To: xsde-users@codesynthesis.com Subject: [xsde-users] Error with Build Environment? 'windows.h' file not found; host:Windows target: VxWorks 5.5.1 Windows host VxWorks 5.5.1 (860PPC) target Config\Config.make : I've copied the etc\vxworks\config-5.5.1.make When trying to build the libxsde library on my host platform for the target environment, I receive an error that 'windows.h' cannot be included: no file or directory. This occurs in the file: C:\xsde\libxsde\xsde\c\expat\xmlparse.c :line 11 #include Where am I supposed to pickup the 'windows.h' file? I have 'windows.h' in 3 separate places on my host platform: Vxworks-> \host\x86-win32\i386-pc-mingw32\sys-include VC6++ -> \include VS8 -> \include To do develop using a windows platform, target vxworks, what windows-based compiler environment do I need? How do I install and configure? What does XSD/e build makefiles expect? Being relatively new to vxworks, do I need to set a configuration setting in my VxWorks installation? Why does it need 'windows.h' anyway? The target is VxWorks. I can successfully build the libxsde library on windows, target windows. No Problem. Thanks, Terry O' Terry O'Laughlin Sr. Software Engineer IPC TS Engineering Alliance Sustaining Dept. 777 Commerce Drive Fairfield, CT 06825 phone: 203-339-7987 fax: 203-339-7809 www.ipc.com Terry.O'Laughlin@ipc.com ________________________________ DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems. [cid:green-logo42e4.jpg]Please consider the environment before printing this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: green-logo42e4.jpg Type: image/jpeg Size: 1268 bytes Desc: green-logo42e4.jpg Url : http://codesynthesis.com/pipermail/xsde-users/attachments/20100829/48cc80be/green-logo42e4.jpg From Terry.O'Laughlin at ipc.com Sun Aug 29 19:35:48 2010 From: Terry.O'Laughlin at ipc.com (O'Laughlin, Terry) Date: Sun Aug 29 19:35:52 2010 Subject: [xsde-users] C++ style comments cause error when complied by c (old) compiler (gcc 2.96) Message-ID: Target: VxWorks 5.5.1 gcc2.96 PPC860 Host: Win32 C:\xsde_v3.2_posix\libxsde\xsde\c pre.h & post.h contain C++ '//' style comments. Our build environment (gcc2.96) does not like this. Encapsulated C++ comments within C style "/* */' comments. Build completes fine. Terry O'Laughlin Sr. Software Engineer IPC TS Engineering Alliance Sustaining Dept. 777 Commerce Drive Fairfield, CT 06825 phone: 203-339-7987 fax: 203-339-7809 www.ipc.com Terry.O'Laughlin@ipc.com ________________________________ DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems. [cid:green-logofbf.jpg]Please consider the environment before printing this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: green-logofbf.jpg Type: image/jpeg Size: 1268 bytes Desc: green-logofbf.jpg Url : http://codesynthesis.com/pipermail/xsde-users/attachments/20100829/41271249/green-logofbf.jpg From boris at codesynthesis.com Mon Aug 30 09:36:09 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Aug 30 09:28:19 2010 Subject: [xsde-users] C++ style comments cause error when complied by c (old) compiler (gcc 2.96) In-Reply-To: References: Message-ID: Hi Terry, O'Laughlin, Terry writes: > C:\xsde_v3.2_posix\libxsde\xsde\c pre.h & post.h contain C++ '//' style > comments. Our build environment (gcc2.96) does not like this. > Encapsulated C++ comments within C style "/* */' comments. Build > completes fine. Good stuff. I have committed the fix: http://scm.codesynthesis.com/?p=xsde/xsde.git;a=commit;h=ab27d628b1e1500a22597acad013c4b50e5474a9 Thanks for reporting this! Boris