fcgio: int instead of int_type

Till Schuberth <till-Eb2pd/[email protected]>
Newsgroups gmane.comp.web.fastcgi.devel
Message-ID <[email protected]>
Hello everyone,

I think I've found a bug.
I'm using FastCGI on an embedded platform and therefore don't have  
enough space for the GNU libstdc++. Hence I tried to link FastCGI  
against uClibc++, but it didn't compile, because in the files  
fcgi-2.4.0/libfcgi/fcgio.[cpp|h] some functions are overridden using  
int as return type. The GNU libstdc++ and uClibc++ are using here  
int_type instead, which is in the case of uClibc++ defined as short int.
I have attached a patch which solves the problem.

Regards,

Till Schuberth

_______________________________________________
FastCGI-developers mailing list
FastCGI-developers-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org
http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers
fcgi-int_type.patch (application/octet-stream, 3 KB)
diff -urN fcgi-2.4.0-orig/configure.in fcgi-2.4.0-patched/configure.in
--- fcgi-2.4.0-orig/configure.in	2003-01-19 18:19:41.000000000 +0100
+++ fcgi-2.4.0-patched/configure.in	2009-08-20 06:59:51.000000000 +0200
@@ -38,6 +38,13 @@
                                [AC_MSG_RESULT(yes)
                                 AC_DEFINE([HAVE_STREAMBUF_CHAR_TYPE], [1], 
                                           [Define if char_type is defined in the context of streambuf])],
+                               [AC_MSG_RESULT(no)])
+                AC_MSG_CHECKING([whether int_type is defined in the context of streambuf])
+                AC_TRY_COMPILE([#include <iostream>],
+                               [class fcgi_streambuf : public std::streambuf { int_type ct; }],
+                               [AC_MSG_RESULT(yes)
+                                AC_DEFINE([HAVE_STREAMBUF_INT_TYPE], [1], 
+                                          [Define if int_type is defined in the context of streambuf])],
                                [AC_MSG_RESULT(no)])],
                [AC_MSG_RESULT(no)])
 AC_SUBST(LIBFCGIXX)
diff -urN fcgi-2.4.0-orig/include/fcgio.h fcgi-2.4.0-patched/include/fcgio.h
--- fcgi-2.4.0-orig/include/fcgio.h	2002-02-25 14:16:11.000000000 +0100
+++ fcgi-2.4.0-patched/include/fcgio.h	2009-08-20 04:14:04.000000000 +0200
@@ -45,6 +45,9 @@
 #if ! HAVE_STREAMBUF_CHAR_TYPE
 typedef char char_type;
 #endif
+#if ! HAVE_STREAMBUF_INT_TYPE
+typedef int int_type;
+#endif
 
 /*
  *  fcgi_streambuf
@@ -71,16 +74,16 @@
 protected:
 
     // Consume the put area (if buffered) and c (if c is not EOF).
-    virtual int overflow(int);
+    virtual int_type overflow(int_type);
 
     // Flush the put area (if buffered) and the FCGX buffer to the client.
     virtual int sync();
 
     // Remove and return the current character.
-    virtual int uflow();
+    virtual int_type uflow();
 
     // Fill the get area (if buffered) and return the current character.
-    virtual int underflow();
+    virtual int_type underflow();
 
     // Use a buffer.  The only reasons that a buffer would be useful is
     // to support the use of the unget()/putback() or seek() methods.  Using
diff -urN fcgi-2.4.0-orig/libfcgi/fcgio.cpp fcgi-2.4.0-patched/libfcgi/fcgio.cpp
--- fcgi-2.4.0-orig/libfcgi/fcgio.cpp	2002-02-24 21:12:22.000000000 +0100
+++ fcgi-2.4.0-patched/libfcgi/fcgio.cpp	2009-08-20 04:14:02.000000000 +0200
@@ -59,7 +59,7 @@
     setbuf(b, bs);    
 }
 
-int fcgi_streambuf::overflow(int c)
+fcgi_streambuf::int_type fcgi_streambuf::overflow(fcgi_streambuf::int_type c)
 {
     if (this->bufsize)
     {
@@ -89,7 +89,7 @@
 }
 
 // uflow() removes the char, underflow() doesn't
-int fcgi_streambuf::uflow() 
+fcgi_streambuf::int_type fcgi_streambuf::uflow() 
 {
     int rv = underflow();
     if (this->bufsize) gbump(1);
@@ -97,7 +97,7 @@
 }
 				
 // Note that the expected behaviour when there is no buffer varies
-int fcgi_streambuf::underflow()
+fcgi_streambuf::int_type fcgi_streambuf::underflow()
 {
     if (this->bufsize)
     {
PGP.sig (application/pgp-signature, 194 B) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.