X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_50,SPF_PASS X-Spam-Check-By: sourceware.org Message-ID: From: Jay To: cygwin Subject: RE: jmp_buf size? Date: Wed, 4 Feb 2009 23:00:00 +0000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com What is up with the size of jmp_buf? It appears that setjmp.h confuses bytes and ints, specifically in the Cygwi= n case. _JBLEN should be 13, not 13*4. or #define _JBTYPE to char, but that doesn't work as easily. ? =20 =20 I applied a local hack workaround, something like: =20 =20 typedef unsigned char JBTYPE __attribute(align(4));=20=20 #define _JBTYPE _JBTYPE=20 #include=20=20 =20 =20 Though my larger goal, of implementing (deprecated-in-favor-of-pthreads) Po= six get/make/set/swapcontext I gave up on anyway, at least via layering ove= r setjmp/longjmp. They may be implementable via Win32 fibers, though the ov= erall thing still perhaps dodgy and useless ("user more threads"...). =20 =20 I realize that jmp_buf is something "deep" and system specific, not to be m= essed with lightly, but I'm also pretty darn certain that Cygwin declares i= ts own jmp_buf incorrectly. I also realize that larger than needed is safe, "just" wasteful, and possib= ly "future proof". It still seems like a mistake. =20 - Jay -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/