Who is aldot again?

[Rob Landley]

On Saturday 15 October 2005 16:16, Bernhard Fischer wrote:
> On Sat, Oct 15, 2005 at 02:18:06PM -0500, Rob Landley wrote:
> >Regarding svn 11872:
> >
> >I spent a _long_ time trying to get loop.c to work at all reliably, so I
> > have an interest in it.
>
> I don't think i broke it, did i?
>
> >Erik didn't touch the file.  You're changing the date ranges on somebody
> >_else's_ copyrights.
>
> Reverted. I was under the impression that it was a project-wide
> copyright, which may be updated on behalf of the project coordinator.

Unfortunately, that's not how copyright law works. :)

I doubt Erik would object, but you can't modify somebody else's copyright for 
them, or give somebody else your copyright without a "written instrument of 
conveyance" and all that fun stuff.

These files mostly have a group copyright, and the interesting thing is really 
going to be who is going to assert rights to them and has a provable claim.  
If you're going to, add your name to the list with your own date range, but 
don't be suprised if you then start to get email with support questions. :)

This is sadly out of date (predates DMCA among other things) but still a good 
intro to the basics:
http://www.faqs.org/faqs/law/copyright/faq/

> >You argue against ? : because it's a documented gnu extension (and
> > definitely
>
> No. I'm arguing against it as omitting the middle expression is a gnu
> extension.

Are you going to argue against all the other gnu extensions we use?

find . -name "*.[ch]" | xargs grep __attribute_ | wc
     89     589    7503

> >not the only gnu extension we use, and this one has been picked up by
> > other compilers, such as intel's C compiler and TCC, which want to be
> > able to compile the Linux kernel).  Yet you also object to // comments
> > which are c99.
>
> Yes they are c99. But e.g. c89 compilers choke on them.

1.1 won't compile under a c89 compiler.  1.1 isn't _intended_ to compile under 
a c89 compiler.

> Furthermore (and 
> this is not an argument) it looks so much like C++ and is highly irritating
> if you see // and are in C.

I agree that this is not an argument.

> >Why does using c99 types but not c99 comments make sense?  You can't use
> >standards compliance as an argument against ? : while simultaneously
> > arguing against // which is in the standard.
> >
> >In this case, however, your change is saving us nine bytes under gcc
> > 3.3.5.  I don't understand why (_weird_ optimizer glitch), but I'm not
> > going to argue against it.  Mentioning this in the checkin as the
> > _reason_ (and not some ISO
>
> Well, it wasn't the reason for it :)

It's a reason not to revert it.  Hopefully a newer compiler than 3.3 will make 
the issue moot with a better optimizer.  (I'll let you know how 4.0.2 shapes 
up, I've got it building stuff against uClibc, but my change to busybox to 
add "tar --exclude" broke tar completely, and I'm waiting for vodz to take a 
look at it before trying to do more damage myself).

> >thing you yourself aren't adhering to in your checkin) would be a good
> > thing.
>
> Where did i not adhere that ISO thing in the checkin? Do you mean the
> use of "a?a:b" ?

Reverting the //, which is ISO C 99.  You're not revering our increasingly 
pervasive use of C99 types when we actually care whether something is 16 or 
32 bits, and a compiler that can handle them can handle //.

> I don't have the spec handy and don't have a "pure" and strict iso C
> compiler at hand, just this obscure one which tells me it knows about
> c94:

Does busybox build under that currently?

> # cat expr.c
> #include <stdio.h>
> int main(void) {
>         int a = 1;
>         int b = a ? 0 : 1;
>         return b;
> }
> # cc -isoc94 -check -msg_enable level3  -o ex expr.c ; echo $?

You have to feed it a -pedantic flag in order to get it to complain?

This is not a realistic test.  You're asking for compatability with a now 
obsolete standard in a new, as yet unreleased version of the project.

If you were talking about 1.0, then maybe.  But notice how loop.c is _old_ 
(and flaky) in 1.0.

Rob