RE: BCB 5.0 Compilation Issues

[Stephen F. Booth]

I'll reply to all of your messages in one (I've inserted text from other
e-mails somewhat haphazardly).

> From another message
In compiling cgicc 3.2.1 with BCB 5.0, still attempting to find out
what's going on that causes a GPF on startup before we get to main(),
I've found that there are some "#ifdef WIN32" preprocessor directives
which, unfortunately, do not yield the expected results, since BCB
defines __WIN32__, not WIN32.  If I manually define WIN32 as part of the
project options, all compiles well; otherwise I get compiler errors in
cgicc.cpp when the macros VERSION and HOST are not found.  Perhaps

#if defined(WIN32) || defined(__WIN32__)

is needed, instead, although I'd be surprised if other compiler vendors
define WIN32 without any leading underscores.  (Still haven't installed
my play-toy copy of VC++!)
< end

Interesting.  I think I may invent my own macro, CGICC_WIN, that will be
defined in CgiDefs.h if WIN32 or __WIN32__ is defined.  This way I won't
have to have a bunch of conditional preprocessor directives throughout
the code.

> start
This leads me to a question which doesn't really affect me, but I'm
curious: on non-Win32 platforms, how do the getVersion() and getHost()
methods compile successfully if HOST and VERSION aren't defined
anywhere?  Or is there some "configure" installation-time magic that
occurs?
< stop

On GNU/Linux, there is a file called config.h that is automatically
generated at configure time which includes various macros that define
system parameters, available functions, etc.  HOST and VERSION are
defined in this file.

> start
The call to isspace() in CgiEnvironment.cpp is, I believe, missing the
std:: namespace specifier.  (See D.5.2 and .3 of the standard.)  I think
it should
read:

    if(STDNS isspace(*data_iter) == 0)

Otherwise I get undefined function errors.
< stop

I haven't been able to find a definitive answer on this.  'C++
Programming Language, Third Edition' mentions the functions but says
nothing about namespaces.  You're probably right on this one- I'll check
the gcc headers and see if they shed any more light on the matter.

> Here are the rest of the things I encountered while getting cgicc
3.2.1 to
> compile with Borland C++ Builder 5.0.
> 
> 1.  Warnings of "Conversion may lose significant digits" on the middle
> three
> lines of hexToChar() in CgiUtils.p:
> 
>   char digit;
>   digit = (first >= 'A' ? ((first & 0xDF) - 'A') + 10 : (first -
'0'));
>   digit *= 16;
>   digit += (second >= 'A' ? ((second & 0xDF) - 'A') + 10 : (second -
> '0'));
>   return digit;
> 
> This has always annoyed me, but serves a valid purpose IMHO:
calculations
> take place as integers, which means you can indeed screw yourself
> unintentionally when implicitly converting back to char.  If, however,
you
> declare digit as an int, and explicitly cast in the return, the
warnings
> go
> away, and your code self-documents the already-assumed-to-be-safe
> conversion
> with the presence of static_cast:
> 
>   int digit;
>   digit = (first >= 'A' ? ((first & 0xDF) - 'A') + 10 : (first -
'0'));
>   digit *= 16;
>   digit += (second >= 'A' ? ((second & 0xDF) - 'A') + 10 : (second -
> '0'));
>   return static_cast<char>(digit);
> 
> Do other compilers complain about this?

Point taken.  In fact, this function/set of functions has always annoyed
me because it relies on the host character encoding (of the compiler at
compile-time) to be US-ASCII.  There is no way that it would work
correctly on EBCDIC systems, or any other system whose lower 0x80 bytes
aren't compatible with US-ASCII.  I guess to be safer about it, I should
hardcode the hex values for the characters instead of the character
literals themselves.  This makes the code less readable but more
portable.  However, it still assumes that the incoming text (from the
GET/POST method) is in US-ASCII.  On an aside, HTTP/1.1 (RFC 2068)
describes a charset parameter that allows any charset to be specified.
I'm unclear how the library would/should work when unescaping characters
encoded in ISO-2022 for example.  


> 2.  The line:
> 
>   fDataType = dataType.empty() ? "text/plain" : dataType;
> 
> in the FormFile constructor causes a "Two operands must evaluate to
the
> same
> type" error.  However, I believe this is a compiler bug, since 5.16.3
says
> "an attempt is made to convert each of those operands to the type of
the
> other", and I'd think the std::string constructor that accepts a char
*
> could be used to convert the character data to a std::string.  I must
> admit
> I don't fully understand the detailed rules in that clause by which
> compilers are supposed to make the attempt, though.
> 
> My solution makes the types of the operands explicitly the same:
> 
>   fDataType = dataType.empty() ? STDNS string("text/plain") :
dataType;

I've heard this one somewhere before :).  OK, OK, I'll change it to work
with your broken compiler!  

> ...So it turns out these were the only two additional things.  And
once I
> made sure that all three of my toolkit static library, the cgicc
static
> library, and my application got rid of the darn -tWM (multithreading
> enabling) compiler option, accessible only in the raw project
> configuration
> file and not through the IDE, I no longer get the runtime GPF's--I'm
> running
> my cgicc application just fine...!  Grr.  Ah well.

No GPFs is always a good thing!