At 12:38 PM 1/12/00 +0100, Jean-Marc Lasgouttes wrote:
> >>>>> "Lindsay" == R Lindsay Todd <[EMAIL PROTECTED]> writes:
>
>Until yesterday, I would have said that _all_ systems except solaris7
>use const char* ;) I have added some code in configure which is
>supposed to detect this situation, although I can't test it, obviously.
I'd think something along the lines of the casts used to arguments
to select() would be the way to go...
>Lindsay> 2) In src/spellchecker.C, about line 359, the FD_ZERO macro
>Lindsay> is used. When compiled, there is a complaint on this line
>Lindsay> that bzero is missing a prototype. FD_ZERO uses bzero.
>
>Lindsay> As a kludge, I added a #include <strings.h>. But I think
>Lindsay> a more portable solution would be to have configure check if
>Lindsay> bzero is prototype'd and available, defining a macro in terms
>Lindsay> of memset otherwise, and making sure code can use either or
>Lindsay> both of bzero and memset.
>
>And what about prototyping bzero ourselves? How unportable would that
>be? Hmm...
>
>BTRW, do you get an error or a warning?
This actually yielded a compilation error.
As far as prototyping bzero: I'd think there may be cases where one of
the header files already has a prototype, and it is likely to be using
char* instead of void* as the type of the first argument. Generally I
have found that providing my own prototypes for system functions eventually
breaks portability. (But most of my programming is with ANSI C, where
the prototype is (usually) optional.)
It looks like AIX has a C++ stdlib.h file that defines bzero, as well as other
stdlib.h functions. This #undefs bzero before specifying the prototype.
Would it harm anything to have configure look for stdlib.h, and #include
that in spellchecker.C if it exists? I wouldn't expect it to.
Looking at the OpenGroup spec's, bzero is supposed to be defined in
strings.h (yes, strings, not string). But then again, FD_ZERO should
only require sys/time.h. Which suggests the AIX behaviour is not
standards-conforming. But of course, the spec's are for ANSI C, not
C++. So who knows what the behaviour should be...
Maybe the right solution is to see which of these header files are needed
to make FD_ZERO work: sys/time.h, stdlib.h, strings.h. (After all, it is
FD_ZERO we want, not bzero.) Since the set of header files you are
already using is working for most systems, this ought to do the trick.
This could be done in configure.
/Lindsay
R. Lindsay Todd email: [EMAIL PROTECTED]
Senior Systems Programmer phone: 518-276-2605
Rensselaer Polytechnic Institute FAX: 518-276-2809
Troy, NY 12180-3590 WWW: http://www.rpi.edu/~toddr
