Subject: RE: Any C++ Client Source Code?

From: Bob Evans <[email-masked]>
Date: Fri, 18 Aug 2000 10:41:50 -0500

Hi Ted,
> Can't you just slap 
> 'extern "C" {}'
> around the dhclient declarations?

It's not quite so simple.  In addition to the above, I have to:
1) add function signatures inside the function definitions and delete them
underneath:
void f(a)
int a; {
...to...
void f(int a) {
2) the C++ keywords "new" and "class" are used as variables/structs
throughout the code, for example, in common/memory.c. I have to remap these
to something different.
3) I have to add many explicit casts which the C++ compiler is demanding.

Thanks, Bob.

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]]
> Sent: Friday, August 18, 2000 10:29 AM
> To: [email-masked]
> Cc: DHCPv4 discussion list
> Subject: Re: Any C++ Client Source Code? 
> 
> 
> 
> > I am integrating ISC's C source into our C++ environment 
> (Solaris).  This is
> > proving to be a tedious exercise.
> 
> It seems like it would be about a day's work, right?
> 
> > Are there any C++/Unix sources available
> > for DHCP clients?  We need to develop a customized client for our
> > application.
> 
> There is a Java DHCP library that might help you, but of course that
> would require rototilling as well.  Can't you just slap 
> 'extern "C" {}'
> around the dhclient declarations?
> 
> 			       _MelloN_
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Aug 2000 12:00:09 -0400

The latest DHCP code is moving away from K&R, and in fact won't build
on K&R compilers.   So I'm all in favor of any efforts to de-K&R the
code, and would be happy to work with you on this (although I don't
have time to do it myself, unfortunately).   This would mean that at
least you wouldn't have to redo this work in future versions.

> throughout the code, for example, in common/memory.c. I have to remap these

Good point.   Again, this is something that should be fixed - there's
no reason why the code should be gratuitously incompatible with C++.

> 3) I have to add many explicit casts which the C++ compiler is demanding.

Again, I have tried very hard to make the very latest code, which is
only available from anoncvs, compile even with an extremely pedantic
compiler.   Working from that code, the set of these errors that I
would expect you to find should be much smaller than with, e.g.,
3.0b1pl17 or 2.0pl4.

			       _MelloN_

---

From: "Barr Hibbs" <[email-masked]>
Date: Fri, 18 Aug 2000 10:47:24 -0700

> least you wouldn't have to redo this work in future versions.
...interesting.....

One of my local modifications (because we originally had to compile on
ANSI-only mainframes) was to install ANSI function prototyping throughout,
and to segregate the K&R style code so as to preserve the original while
primarily using ANSI

> compiler.
...to deal with our flakely mainframe compiler, which went nutso over casts,
I had to do exactly the same thing...  as well as change a number of macro
definitions (like TIME) which interfered with defined system calls

believe me I understand how much work is involved in doing this!!

--Barr