Re: implicit linkage
On Mon, 13 Oct 2014 08:18:57 +0100
Jonathan Dowland <jmtd@debian.org> wrote:
> On Sun, Oct 12, 2014 at 02:48:55PM -0400, Steve Litt wrote:
> > On Sun, 12 Oct 2014 19:02:08 +0100 Martin Read <zen75502@zen.co.uk>
> > wrote:
> > > On 12/10/14 18:13, John Hasler wrote:
> > > > You have no problem with an 1800 line function?
> ...
> > > I have a problem with 1800 line functions in general;
> ...
> > I have no problem with an 1800 line function.
> ...
>
> *What* 1800 line function? The commit URI that was shared was an
> 1894-line *file* with a large function definition starting at line
> 638 and ending at 1890. That's a 1252-line function.
OK, %s/1800/1252/g
I have a hunch the guy I replied to would have had as much of a problem
with a 1252 line function as an 1800 line one. My Ruby friends
disparage functions over 30 lines long. I view function lengths as an
implementation detail and don't worry too much about them. The code
looked reasonable to me.
>
> Not only that but you're looking at a commit dating from August last
> year. The function doesn't even exist any more in current systemd[1].
> There are no functions of even a 100 lines length in that file now.
>
> [1]
> http://cgit.freedesktop.org/systemd/systemd/tree/src/core/dbus-manager.c
I'm not that concerned about function lengths anyway.
>
>
> > What I *DO* have a problem with is the guy's welding pam onto his
> > new init, and welding other critical and former separate OS
> > functionalities onto his "toolset", preventing (either technically
> > or by them being removed from the packages) former modules from
> > being used.
>
> Which guy is that? The commit that the URI referenced was written by
> Lennart Poettering, so I guess you mean him;
Yep.
> but that commit didn't
> touch the file that was being complained about. Maybe you mean one of
> the other 17 people who have contributed to that file?
I wasn't talking about that commit, I was talking about what has been
done, and what Poettering has stated his goal is.
>
> > If I were to maintain his code, before reducing the 1800 line
> > function, I'd do something about the function with 20 arguments,
> > with each argument including a function call. I'd replace all of
> > that with a struct pointer.
>
> I'd start with *reading the code* if I were you; something you guys
> clearly aren't doing.
OK, nothing in that code was that important. I *did* notice a function
with 20 arguments, and I, personally, would substitute a struct pointer
for that. But, as I said before, my objection to systemd isn't coding
style.
>
> But if you get past that you'll be pleased to discover that such
> clean ups and refactors are happening quite often. See e.g.
> df2d202e6ed4001a21c6512c244acad5d4706c87 ("bus: let's simplify things
> by getting rid of unnecessary bus parameters"). I'll leave you to
> guess the author of that one.
I couldn't find that, but once again, I'm not saying anything about the
coding style. As a matter of fact, the thrust of my post was basically
that I'm not concerned about the referenced code's coding style, I'm
concerned about the macro-architecture.
SteveT
Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance
Reply to: