httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@worldgate.com>
Subject Re: cvs commit: apache-1.3/src/os/unix os.c
Date Sun, 19 Apr 1998 16:40:45 GMT
On Sun, 19 Apr 1998, Ben Laurie wrote:

> Ralf S. Engelschall wrote:
> > 
> > In article <Pine.BSF.3.95q.980419094206.24867A-100000@valis.worldgate.com>
you wrote:
> > 
> > > Is there any advantage to not just casting it for all platforms?
> > 
> > > I think that if you think OSF1 and FreeBSD will be the only platforms that
> > > do this, you will be quite mistaken, and having long lists of OSes in code
> > > isn't nice when it isn't necessayr.
> > 
> > Hmmm.... I don't know if it isn't necessary to cast always. What is ANSI C's
> > rule here: When I have a "const char *" and pass this to a function which
> > wants a "char *", the cast is needed or the compiler complains with
> > "discarding char". Ok. And on the other hand? When I've a "const char *" and
> > the function wants a "const char *" but I cast with "char *". Is this always
> > ok this way around? I'm not sure. Definitive comments?
> 
> Yes, it is always OK to add a const. Removing one isn't. OTOH, casting
> for all platforms is bad, if you don't have to, coz one day it'll bite
> you.

I don't see the big problem in this case because we are just changing a
datatype that we know what it is to something that is the same type.  It
isn't like casting a datatype that could differ or forcing one type into
another.

> 
> Anyway, why does dlopen() not have const? Is it actually going to change
> the string?

No, the prototype just isn't const.  It was before, then was changed to
not be to match up with crt0.c, then was changed back to match when crt0.c
was fixed.


Mime
View raw message