[TUHS] looking for a quote

[TUHS] looking for a quote

[ron minnich]

A long time ago, dmr wrote about something that IIRC BSD had done he did
not like: unlimited length identifiers in C, maybe? His argument was that
being too general was not a good thing.

Can't quite find the quote, anyone remember it? Would have been ca. 1980.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171207/4202bd3e/attachment.html>

[TUHS] looking for a quote

[Larry McVoy]

Could it have been having a structure field namespace per struct type?
I feel like he and I talked about that, I know that that has always been
a pet peeve of mine, I *much* prefer sbuf.st_size than whatever.size,
the former is instantly a stat structure, the later is a "whatever".

Yeah, I get it, it wasn't scalable, but I wish that there was a way to
encourage that all structure fields be uniquely named, it's awesome for
code readability.

If the kernel and common libraries could have done that, so much better.

On Thu, Dec 07, 2017 at 12:06:54AM +0000, ron minnich wrote:
> A long time ago, dmr wrote about something that IIRC BSD had done he did
> not like: unlimited length identifiers in C, maybe? His argument was that
> being too general was not a good thing.
> 
> Can't quite find the quote, anyone remember it? Would have been ca. 1980.
> 
> ron

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] looking for a quote

[Ralph Corderoy]

Hi Larry,

> I *much* prefer sbuf.st_size than whatever.size, the former is
> instantly a stat structure, the later is a "whatever".

It's awful.  :-)
st.st_size `stutters' and that jars when reading in my head.
If st.size isn't clear from context, then stbuf.size probably is.
Ditto ar_hdr->uid versus hdr->ar_uid.

There's a hierarchy to walking the data structure, and that should be
represented in the identifiers.  So big.little, not b.bg_little.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

[TUHS] looking for a quote

[ron minnich]

I think the issue was when the folks at UCB added very long symbol names to
the C compiler

On Thu, Dec 7, 2017 at 3:50 AM Ralph Corderoy <ralph at inputplus.co.uk> wrote:

> Hi Larry,
>
> > I *much* prefer sbuf.st_size than whatever.size, the former is
> > instantly a stat structure, the later is a "whatever".
>
> It's awful.  :-)
> st.st_size `stutters' and that jars when reading in my head.
> If st.size isn't clear from context, then stbuf.size probably is.
> Ditto ar_hdr->uid versus hdr->ar_uid.
>
> There's a hierarchy to walking the data structure, and that should be
> represented in the identifiers.  So big.little, not b.bg_little.
>
> --
> Cheers, Ralph.
> https://plus.google.com/+RalphCorderoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171207/d6d207fc/attachment.html>

[TUHS] looking for a quote

[Steve Simon]

+100


> On 7 Dec 2017, at 11:50, Ralph Corderoy <ralph at inputplus.co.uk> wrote:
> 
> Hi Larry,
> 
>> I *much* prefer sbuf.st_size than whatever.size, the former is
>> instantly a stat structure, the later is a "whatever".
> 
> It's awful.  :-)
> st.st_size `stutters' and that jars when reading in my head.
> If st.size isn't clear from context, then stbuf.size probably is.
> Ditto ar_hdr->uid versus hdr->ar_uid.
> 
> There's a hierarchy to walking the data structure, and that should be
> represented in the identifiers.  So big.little, not b.bg_little.
> 
> -- 
> Cheers, Ralph.
> https://plus.google.com/+RalphCorderoy

[TUHS] looking for a quote

[Larry McVoy]

The problem is crappy programmers.  Good ones will do what you guys 
want and put the type in the name of the struct instance.  Bad ones
will do s.size and you have no idea what "s" is.  When the compiler
forced the issue the quality of the programmer didn't matter.

I'd love to live in a world of all great programmers.  Unfortunately,
I don't.

On Thu, Dec 07, 2017 at 03:27:40PM +0000, Steve Simon wrote:
> +100
> 
> 
> > On 7 Dec 2017, at 11:50, Ralph Corderoy <ralph at inputplus.co.uk> wrote:
> > 
> > Hi Larry,
> > 
> >> I *much* prefer sbuf.st_size than whatever.size, the former is
> >> instantly a stat structure, the later is a "whatever".
> > 
> > It's awful.  :-)
> > st.st_size `stutters' and that jars when reading in my head.
> > If st.size isn't clear from context, then stbuf.size probably is.
> > Ditto ar_hdr->uid versus hdr->ar_uid.
> > 
> > There's a hierarchy to walking the data structure, and that should be
> > represented in the identifiers.  So big.little, not b.bg_little.
> > 
> > -- 
> > Cheers, Ralph.
> > https://plus.google.com/+RalphCorderoy

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] looking for a quote

[Theodore Ts'o]

On Thu, Dec 07, 2017 at 11:50:24AM +0000, Ralph Corderoy wrote:
> Hi Larry,
> 
> > I *much* prefer sbuf.st_size than whatever.size, the former is
> > instantly a stat structure, the later is a "whatever".
> 
> It's awful.  :-)
> st.st_size `stutters' and that jars when reading in my head.
> If st.size isn't clear from context, then stbuf.size probably is.
> Ditto ar_hdr->uid versus hdr->ar_uid.

The reason why it's useful is that it's much more likely to find
relevant lines of code by using "grep st_size *.[ch]".  If you grep
for "size", there will be way too many false matches.

    	    	       	      	       - Ted

[TUHS] looking for a quote

[Arthur Krewat]

On 12/7/2017 11:24 AM, Theodore Ts'o wrote:
>
> The reason why it's useful is that it's much more likely to find
> relevant lines of code by using "grep st_size *.[ch]".  If you grep
> for "size", there will be way too many false matches.
>
>
I've actually changed variables' or struct members' names based on the 
fact that searching for them in an editor yielded too many bad hits.

But not often ;)

[TUHS] looking for a quote

[Ralph Corderoy]

Hi Ted,

> The reason why it's useful is that it's much more likely to find
> relevant lines of code by using "grep st_size *.[ch]".  If you grep
> for "size", there will be way too many false matches.

True, but hasn't static analysis come on since then?  I don't use them,
but tools like http://ffevotte.github.io/clang-tags/ build on clang's
work to allow queries like finding all mentions of st_size AFAIK.
They'll even cope with two different struct definitions with a st_size
kicking about and use the one you give as a seed reference.

I'm surprised with things like DWARF in ELF that compilers weren't used
to generate a super `ctags' longer ago.  We had cscope, that was Bell
Labs IIRC.  And then there's been GNU GLOBAL, GNU's idutils, ...

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

[TUHS] looking for a quote

[Theodore Ts'o]

On Thu, Dec 07, 2017 at 05:45:00PM +0000, Ralph Corderoy wrote:
> Hi Ted,
> 
> > The reason why it's useful is that it's much more likely to find
> > relevant lines of code by using "grep st_size *.[ch]".  If you grep
> > for "size", there will be way too many false matches.
> 
> True, but hasn't static analysis come on since then?  I don't use them,
> but tools like http://ffevotte.github.io/clang-tags/ build on clang's
> work to allow queries like finding all mentions of st_size AFAIK.
> They'll even cope with two different struct definitions with a st_size
> kicking about and use the one you give as a seed reference.

First of all, these tools didn't exist in the days of BSD 4.x.

Second of all, those tools aren't integrated into ctags and etags, so
for the needs of working programmers, the need to run some modified
clang and then parse clang output when trying to figure out where all
the places that use some structure field would be unnecessarily
complex and destructive of a working programmer's productivity.

So arguably the tools *still* don't exist in a useful form for
developers to use.

> I'm surprised with things like DWARF in ELF that compilers weren't used
> to generate a super `ctags' longer ago.  We had cscope, that was Bell
> Labs IIRC.  And then there's been GNU GLOBAL, GNU's idutils, ...

DWARF is incredibly bloated for large projects, because unless the
header files which are #included in each .c file is exactly the same
(the exact same header files, included in the exact same order, with
no other local structure or type definitions in the C source file),
there will N different copies of the structure information in the .o
files, and this duplication will also exist in combined executable's
DWARF information.

I complained about this a decade ago, when this defect essentially
made Systemtap completely unusable by real kernel developers.
Compiling with DWARF exploded the compile time, and size of the build
tree, and the size of the insatlled kernel, by a factor of at least
ten.  We now have a way of generated reduced debuginfo files, but it
works by eliding all of the structure definitions, and only keeping
the file/line number information.  So that won't work for your "super
ctags" proposal.

If you want to try to fix this, feel free --- but we don't actually
have a solution that works in the real world today.  It's something
that only really works in the Powerpoint Slideware world inhabited by
IBM executives....

						- Ted

[TUHS] looking for a quote

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2873 bytes --]

On Thu, Dec 7, 2017 at 4:06 PM, Theodore Ts'o <tytso at mit.edu> wrote:

> On Thu, Dec 07, 2017 at 05:45:00PM +0000, Ralph Corderoy wrote:
> > Hi Ted,
> >
> > > The reason why it's useful is that it's much more likely to find
> > > relevant lines of code by using "grep st_size *.[ch]".  If you grep
> > > for "size", there will be way too many false matches.
> >
> > True, but hasn't static analysis come on since then?  I don't use them,
> > but tools like http://ffevotte.github.io/clang-tags/ build on clang's
> > work to allow queries like finding all mentions of st_size AFAIK.
> > They'll even cope with two different struct definitions with a st_size
> > kicking about and use the one you give as a seed reference.
>
> First of all, these tools didn't exist in the days of BSD 4.x.
>
> Second of all, those tools aren't integrated into ctags and etags, so
> for the needs of working programmers, the need to run some modified
> clang and then parse clang output when trying to figure out where all
> the places that use some structure field would be unnecessarily
> complex and destructive of a working programmer's productivity.
>
> So arguably the tools *still* don't exist in a useful form for
> developers to use.
>
> > I'm surprised with things like DWARF in ELF that compilers weren't used
> > to generate a super `ctags' longer ago.  We had cscope, that was Bell
> > Labs IIRC.  And then there's been GNU GLOBAL, GNU's idutils, ...
>
> DWARF is incredibly bloated for large projects, because unless the
> header files which are #included in each .c file is exactly the same
> (the exact same header files, included in the exact same order, with
> no other local structure or type definitions in the C source file),
> there will N different copies of the structure information in the .o
> files, and this duplication will also exist in combined executable's
> DWARF information.
>
> I complained about this a decade ago, when this defect essentially
> made Systemtap completely unusable by real kernel developers.
> Compiling with DWARF exploded the compile time, and size of the build
> tree, and the size of the insatlled kernel, by a factor of at least
> ten.  We now have a way of generated reduced debuginfo files, but it
> works by eliding all of the structure definitions, and only keeping
> the file/line number information.  So that won't work for your "super
> ctags" proposal.
>
> If you want to try to fix this, feel free --- but we don't actually
> have a solution that works in the real world today.  It's something
> that only really works in the Powerpoint Slideware world inhabited by
> IBM executives....
>
>                                                 - Ted
>
​+1​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171207/056b9674/attachment.html>

[TUHS] looking for a quote

[Dave Horsfall]

On Thu, 7 Dec 2017, Ralph Corderoy wrote:

> st.st_size `stutters' and that jars when reading in my head.

Hey, as a stutterer myself I'm used to it :-)  No, no offence taken...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."