[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Results of egrep -l '^<<<<<<< |^=======$|^>>>>>>> |^\|\|\|\|\|\|\| '

From: Greg A. Woods
Subject: Re: Results of egrep -l '^<<<<<<< |^=======$|^>>>>>>> |^\|\|\|\|\|\|\| '
Date: Thu, 19 Jul 2001 16:11:23 -0400 (EDT)

[ On Thursday, July 19, 2001 at 14:33:55 (-0400), Noel L Yap wrote: ]
> Subject: Re: Results of egrep -l '^<<<<<<< |^=======$|^>>>>>>> 
> |^\|\|\|\|\|\|\| '
> What problems are you talking about?  Who has complained about them (aside 
> from
> you)?

Well, I know there was at least one developer on the devel-cvs list who
complained and asked for the change to be reverted until consensus could
be reached.  I'd certainly have complained then too if other
circumstances hadn't prevailed at the time.  I suspect the change was
not reverted simply because one other developer did agree with Jim at
the time, and given who it was I suspect no amount of debate at the time
could have resulted in any consensus.  Yes I'm not giving names because
as far as I know the devel-cvs list was/is private.

IIRC there was also a debate about this issue way back in the depths of
time too (i.e. well before the days of Jim Kingdon's direct involvement
with CVS, back when CVS development was still in its prime and when
there was still a real leader directing it), and obviously the checks
still produced an error up until Jim made his change....

> I don't understand the analogy.  Before his change, CVS would take it upon
> itself to "know" that you absolutely don't want a file checked in, now, it'll
> warn you that you might not want to do what you're doing.  Saying the former
> behaviour is correct is akin to saying that C compilers should never allow you
> to compile code that will result in a NULL pointer dereference or a buffer
> overflow (when it can find this info out statically, of course).

My analogy had to do with whether or not you understand which tool to
use for the job and whether or not you arbitrarily change your tools
just because it seemed convenient to do so at the moment, and be damned
all the proper uses you or others might need them for in the future.

As for whether your analogy makes sense or not will depend on whether
you're a die-hard machine code programmer who always has a noose around
his neck, or whether you maybe learned a much more useful, safer,
language such as smalltalk.

In smalltalk you can try to write such errant code of course, but when
you submit it to the bytecode compiler you'll get an error back.
Interestingly that error message will be inserted right into the code
where the error is (and the error text is selected in the editor too so
you just have to cut it with one keystroke before you correct the error)
[at least thats how it works in smalltalk-80 and its modern derrivatives
such as squeak].  If you try again to submit the code with the error
and/or the error message still in it you'll just get back another error,
written right into your code, again.

Other types of run-time errors in smalltalk result in the immediate
invocation of an error notifier.  You can then either fix the code and
proceed, invoke a debugger, proceed anyway (and usually cause a mess),
or abort the execution completely.  You could change the interpreter to
not pop up the notifier, I guess, but that would be very un-smalltalk
like.  Given the dynamic nature of smalltalk this notifier isn't much
different than the compiler stopping on an error.

Of course your analogy is based on some very flawed concepts about how
the C language actually works in practice too.  Yes a C compiler could
prevent you from writing code that explicitly de-referenced NULL, and
some do, GNU egcs-1.1.2, for example:

        $ cat tnull.c
                int foo = *(0);
        $ cc tnull.c
        tnull.c: In function `main':
        tnull.c:3: invalid type argument of `unary *'

However it's literally impossible for a C compiler to do that kind of
check for arbitrary code since the compiler cannot know what possible
values might be assigned to a pointer at run-time:

        $ cat tnull2.c
                int *p;
                int foo;
                p = (int *) 0;
                foo = *(p);

Yes, anyone capable of reading simple C like this will leap to the
obvious conclusion, but what if the expression was more complex?

        p1 = 1;
        p2 = 1;
        p = p1 - p2;

Instead some compilers insert run-time checks to catch such
run-time-only errors, and others rely on the underlying operating system
to trap them.

        $ cc tnull2.c
        $ ./a.out
        Memory fault 

I think CVS is more like smalltalk than C or assembler though.

                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]