7 Dec
2017
7 Dec
'17
12:06 a.m.
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
7 Dec
7 Dec
12:34 a.m.
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
11:50 a.m.
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
3:24 p.m.
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(a)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
3:27 p.m.
+100
On 7 Dec 2017, at 11:50, Ralph Corderoy
<ralph(a)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
3:32 p.m.
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(a)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
4:24 p.m.
On Thu, Dec 07, 2017 at 11:50:24AM +0000, Ralph Corderoy wrote:
Hi Larry,
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
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. 
4:44 p.m.
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 ;)
5:45 p.m.
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
9:06 p.m.
On Thu, Dec 07, 2017 at 05:45:00PM +0000, Ralph Corderoy wrote:
Hi Ted,
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.
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, ...
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
9:41 p.m.
On Thu, Dec 7, 2017 at 4:06 PM, Theodore Ts'o <tytso(a)mit.edu> wrote:
On Thu, Dec 07, 2017 at 05:45:00PM +0000, Ralph
Corderoy wrote:
+1
Hi Ted,
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.
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, ...
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
2334
days inactive
2334
days old
11 comments
8 participants
participants (8)
-
Arthur Krewat -
Clem Cole -
Dave Horsfall -
Larry McVoy -
Ralph Corderoy -
ron minnich -
Steve Simon -
Theodore Ts'o