Sam TH wrote:
> On Mon, Dec 04, 2000 at 01:12:17AM +0100, Branko Uibej wrote:
>
>> Sam TH wrote:
>>
>>> The problem is with the const. I couldn't find anything about the
>>> standard either way in a quick Google search.
>>
>> Conversion from non-const -> const is implicit and always allowed. If MW
>> is so strict as to flag that as an error, then I'm sorry to say that it
>> isn't a C compiler. :-(
>
>
> Fortunately, it turned out that those const casts were *not*
> neccessary, and a mistaken report on my part. See
> <20001203043555.B10844@uchicago.edu>.
Ah, great, thanks. I take that back, then.
>> I'm a bit concerned about all these casts going into the codebase (yeah,
>> we've had this discussion before). GCC is not lenient about type
>> conversions, either, and it wasn't complaining.
>
>
> I think Greg converted almost all of the casts into different
> defitions of either the variable or the function in question. So you
> neednt worry.
I saw that afterwards, yes.
>> Would it be very terrible to require GCC for building Subversion, for
>> development, that is? Right now it won't compile out of the box with IBM
>> xlc on AIX, HP cc on HP-UX or Sun's Workshop cc on Solaris, so why
>> should we start peppering the code with casts just to cater to MW? GCC
>> should run quite nicely on BeOS.
>>
>> Certainly we'll need to support the various native compilers for 1.0,
>> but this is /not/ the way to do that. Whatever portability support we
>> need must be provided by APR and, failing that, by our own configure tests.
>
>
> But when, precisely, are you willing to change the code to work on
> other compilers? GCC probably would run nicely on that machine, but
> 1) it has a limited hard disk, most of which is used, and 2) just
> running the APR configure on it take about 15 minutes. So putting GCC
> on it would be quite a bit of effort.
I may have sounded a bit harsh, so let me esplain. I'm not /against/
supporting other compilers. Exactly the opposite, in fact. I just want
to point out that such support must be offered by (a) APR where API
portability is concerned, and (b) configury for compiler options, etc.
Any changes in Subversion code (and most especially casts, IMO) must be
kept at a minimum.
While we're at it, would you like to contribute the various configury
bits necessary to support MW? I'm sure such contributions would be very
welcome. We need a framework for supporting various compiers, so this
would be an ideal opportunity to start building one.
> Conversely, why exactly is it important to be able to do implicit
> casts on the signedness of characters, for example?
Such casts are invalid. I've never heard of GCC allowing them. In fact
... oh, (expletive), GCC really /does/ keep quiet about those without
-pedantic. So wee need to add -pedantic to the maintainer-mode options
for GCC. I'll do that if nobody objects.
> Wouldn't it make
> more sense to write code that doesn't require those casts?
Absolutely.
> And is it
> really so difficult not to use unimlemented parts of the C99 standard?
Not at all. Don't misunderstand me: I'd like to see the Subversion code
stay as portable as possible. That means ignoring C99 (as I said, there
ain't no such thing as a C99 compiler yet) and avoiding casts (which can
hide potential portability problems), among other things. There are
other criteria to take into account, too -- for instance, it was decided
from the beginning that Subversion will not support old K+R compilers.
So ANSI C89 (or ISO C90, whichever you prefer) is the language being used.
--
Brane �ibej
home: <brane_at_xbc.nu> http://www.xbc.nu/brane/
work: <branko.cibej_at_hermes.si> http://www.hermes-softlab.com/
ACM: <brane_at_acm.org> http://www.acm.org/
Received on Sat Oct 21 14:36:16 2006