Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > tools for manipulating (or pre-processing) data structures tosimplify source

Reply
Thread Tools

tools for manipulating (or pre-processing) data structures tosimplify source

 
 
Jorgen Grahn
Guest
Posts: n/a
 
      10-25-2013
On Wed, 2013-10-23, BartC wrote:
> "BartC" <(E-Mail Removed)> wrote in message
> news:cbT9u.42071$(E-Mail Removed)4...
>
>> "Richard" <(E-Mail Removed)> wrote in message

>
>>> Try looking into linux drivers and marvel at the long struct and field
>>> names then tell Torwalds and co they're writing "terrible code".

>
>> (I've tried to have a look, but as usual with linux-related matters have
>> run into a dead-end, because nothing is ever straightforward!


Any particular problems? A lot of things about Linux are very
straightforward.

> I do happen to have some Python C sources lying around. Most of the struct
> member names seem short, readable and completely reasonable. Either formed
> of one or two words, or with a prefix, such as *name, HEAD, length, offset,
> gc_prev, gc_next etc. There are some longer identifiers outside structs, but
> these are still readable rather than look like gobbledygook, partly because
> they are not so fantastically long that the words need to be abbreviated.
>
> Maybe it's just a Linux thing to make things incomprehensible (and then try
> and make out it's good coding practice!).


I should have responded here instead of upthread: the Linux [kernel]
sources I've seen are nothing like this, and quite readable.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
 
 
 
Kenny McCormack
Guest
Posts: n/a
 
      10-25-2013
In article <(E-Mail Removed)>,
Jorgen Grahn <(E-Mail Removed)> wrote:
....
>> Maybe it's just a Linux thing to make things incomprehensible (and then
>> try and make out it's good coding practice!).

>
>I should have responded here instead of upthread: the Linux [kernel]
>sources I've seen are nothing like this, and quite readable.


Caveat: I've not looked at any of his code (either the kernel or git), but I
have watched a talk he gave once in which he discussed (among other things)
his coding style.

The take-away from that talk was that he does have an, er, shall we say,
"unique" coding style, and the implied statement was that you either love
it or hate it. I get the impression that the world kinda splits about
50/50 into the love/hate camps.

So, arguing about whether or not the Linux kernel is "readable" is going to
be like arguing about any other "love/hate" kind of thing; you're not going
to convince anyone to change their stance.

--
A Catholic woman tells her husband to buy Viagra.

A Jewish woman tells her husband to buy Pfizer.
 
Reply With Quote
 
 
 
 
BartC
Guest
Posts: n/a
 
      10-25-2013

"Jorgen Grahn" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed). ..
> On Wed, 2013-10-23, BartC wrote:


>> Maybe it's just a Linux thing to make things incomprehensible (and then
>> try
>> and make out it's good coding practice!).

>
> I should have responded here instead of upthread: the Linux [kernel]
> sources I've seen are nothing like this, and quite readable.


I've since managed to download the Linux sources. The one or two files I've
glanced at seem nothing like as bad as what the OP posted either. (But there
are about 45,000 files I haven't yet looked at.)

--
Bartc

 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      10-26-2013
ralph <(E-Mail Removed)> wrote:

(snip)

> It was even worse back in the X3J Committee days.
> We had compilers which accepted 16, 32, ... 128 character length
> identifiers, BUT only the first 5, 8, 13, ... characters were
> 'unique/significant'.


> Kernighan wanted only 5 significant characters written into the
> standard. Real C programmers didn't need more. Imagine if that had
> happened? <g>


The early PL/I compilers used the first four and last three for
external symbols. (The linker only knew about 8.) Internal names
could be longer, such as 31. Using some from each end allows for
long_name1, long_name2, etc.

The Fortran H compiler uses six trees for its symbol table, one for
each possible length. One manual suggests for faster compilation
distribute your names equally between 1 and 6 characters.
(No mention of readability of the program.)

-- glen
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      10-26-2013
ralph <(E-Mail Removed)> writes:
On long names...

> It was even worse back in the X3J Committee days.
> We had compilers which accepted 16, 32, ... 128 character length
> identifiers, BUT only the first 5, 8, 13, ... characters were
> 'unique/significant'.
>
> Kernighan wanted only 5 significant characters written into the
> standard. Real C programmers didn't need more. Imagine if that had
> happened? <g>


Do you have a citation? It sounds like a peculiar thing for him to
have said.

--
Ben.
 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      10-26-2013
On Friday, October 25, 2013 10:07:49 PM UTC+1, ralph wrote:
> On 25 Oct 2013 19:15:45 GMT, Jorgen Grahn <(E-Mail Removed)>
>
> It was even worse back in the X3J Committee days.
> We had compilers which accepted 16, 32, ... 128 character length
> identifiers, BUT only the first 5, 8, 13, ... characters were
> 'unique/significant'.
>
> Kernighan wanted only 5 significant characters written into the
> standard. Real C programmers didn't need more. Imagine if that had
> happened? <g>
>

Fortran would accept up to six, and C compilers would prefix an underscore
to the linker. So you could only call a C routine or use a C identifier
from Fortran if it was unique in the first five.

Mathematicians don't use long names. They virtually always use single letters,
resorting to Greek or even other alphabets when they run out of Latin.
But really in programming we've several types of variables. Minor variables
should be x, y, z for co-ordinates or real values, theta for an angle,
N for a count, i, for an index. I use ii, iii, iv, v etc for nested counters
and j, k for secondary counters. (Eg if you're removing runs of duplicates,
I'd iterate over the array with i, and keep j as the counter to the top
of the unique list). But a lot of people use j, k for nested counters.
z is a complex number, ptr a pointer, str a string, ch a character, fp a
file pointer.
There's quite a lot you can do with only five characters.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      10-26-2013
ralph <(E-Mail Removed)> writes:

> On Sat, 26 Oct 2013 03:06:32 +0100, Ben Bacarisse
> <(E-Mail Removed)> wrote:
>
>>ralph <(E-Mail Removed)> writes:
>>On long names...
>>
>>> It was even worse back in the X3J Committee days.
>>> We had compilers which accepted 16, 32, ... 128 character length
>>> identifiers, BUT only the first 5, 8, 13, ... characters were
>>> 'unique/significant'.
>>>
>>> Kernighan wanted only 5 significant characters written into the
>>> standard. Real C programmers didn't need more. Imagine if that had
>>> happened? <g>

>>
>>Do you have a citation? It sounds like a peculiar thing for him to
>>have said.

>
> Surprised me as well.
>
> It was rather well known at the time so there must be some mention in
> some of the earlier publications CPJ, Byte, Dr. Dobbs, ??? It is
> definitely in the X3J meeting notes. All my paper is gone - too many
> moves.


Maybe we are talking at cross purposes. You quote suggests that
Kernighan did not want more because real programmers don't need more.
That seems entirely at odds with almost everything I've read by him.
For example, in 1974 -- four years before K&R 1 and more than a decade
before the ANSI standard he was advising, as a matter of style, to make
external identifiers unique in the first 6 characters. That was, as you
probably know, common at the time. Note, as a matter of style, not "you
don't need more" just that you may hit a linker limit if you assume that
more will be unique.

I can see him advocating for the standard to require no more than five
from an implementation if he had become aware in those ten or twelve
years of a system that could not guarantee even six, but that's not at
all the same as saying the real programmers don't need more.

> As Mr. McLean points out - the idea while sounding strange today had
> its points.
>
> Something often over-looked by most language lawyers today is that the
> process of "standardizing" C in the beginning was less an academic
> exercise that it was a process of "codifying" a common ground out of
> what compilers were already doing. It doesn't take much to appreciate
> that migrating programs between compilers with different views of how
> many characters are significant led to problems. Since all compilers
> accepted at least 5, "5" certainly made sense.


Yes, but that's not how you presented the quote. If there were key
systems that could not guarantee five I can see him, and others, arguing
for four, but that would be out of desperation with broken linkers, not
because real programmer don't need more.

--
Ben.
 
Reply With Quote
 
Lew Pitcher
Guest
Posts: n/a
 
      10-26-2013
On Saturday 26 October 2013 14:00, in comp.lang.c, "Ben Bacarisse"
<(E-Mail Removed)> wrote:

> ralph <(E-Mail Removed)> writes:
>
>> On Sat, 26 Oct 2013 03:06:32 +0100, Ben Bacarisse
>> <(E-Mail Removed)> wrote:
>>
>>>ralph <(E-Mail Removed)> writes:
>>>On long names...
>>>
>>>> It was even worse back in the X3J Committee days.
>>>> We had compilers which accepted 16, 32, ... 128 character length
>>>> identifiers, BUT only the first 5, 8, 13, ... characters were
>>>> 'unique/significant'.
>>>>
>>>> Kernighan wanted only 5 significant characters written into the
>>>> standard. Real C programmers didn't need more. Imagine if that had
>>>> happened? <g>
>>>
>>>Do you have a citation? It sounds like a peculiar thing for him to
>>>have said.

>>
>> Surprised me as well.
>>
>> It was rather well known at the time so there must be some mention in
>> some of the earlier publications CPJ, Byte, Dr. Dobbs, ??? It is
>> definitely in the X3J meeting notes. All my paper is gone - too many
>> moves.

>
> Maybe we are talking at cross purposes. You quote suggests that
> Kernighan did not want more because real programmers don't need more.
> That seems entirely at odds with almost everything I've read by him.
> For example, in 1974 -- four years before K&R 1 and more than a decade
> before the ANSI standard he was advising, as a matter of style, to make
> external identifiers unique in the first 6 characters. That was, as you
> probably know, common at the time. Note, as a matter of style, not "you
> don't need more" just that you may hit a linker limit if you assume that
> more will be unique.


IIRC, the MVS LKED linkage editor of the time had a 6-character limit on the
size of external names. The VSE linkage editor had a similar limit.

It wasn't too long later (a few years) that IBM came up with the LE370 tools
that extended both the assembler and linkage editor to handle larger
external names, and added a native C compiler to the language support.

[snip]


--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

 
Reply With Quote
 
Lew Pitcher
Guest
Posts: n/a
 
      10-26-2013
On Saturday 26 October 2013 14:31, in comp.lang.c, "Lew Pitcher"
<(E-Mail Removed)> wrote:

> On Saturday 26 October 2013 14:00, in comp.lang.c, "Ben Bacarisse"
> <(E-Mail Removed)> wrote:
>
>> ralph <(E-Mail Removed)> writes:
>>
>>> On Sat, 26 Oct 2013 03:06:32 +0100, Ben Bacarisse
>>> <(E-Mail Removed)> wrote:
>>>
>>>>ralph <(E-Mail Removed)> writes:
>>>>On long names...
>>>>
>>>>> It was even worse back in the X3J Committee days.
>>>>> We had compilers which accepted 16, 32, ... 128 character length
>>>>> identifiers, BUT only the first 5, 8, 13, ... characters were
>>>>> 'unique/significant'.
>>>>>
>>>>> Kernighan wanted only 5 significant characters written into the
>>>>> standard. Real C programmers didn't need more. Imagine if that had
>>>>> happened? <g>
>>>>
>>>>Do you have a citation? It sounds like a peculiar thing for him to
>>>>have said.
>>>
>>> Surprised me as well.
>>>
>>> It was rather well known at the time so there must be some mention in
>>> some of the earlier publications CPJ, Byte, Dr. Dobbs, ??? It is
>>> definitely in the X3J meeting notes. All my paper is gone - too many
>>> moves.

>>
>> Maybe we are talking at cross purposes. You quote suggests that
>> Kernighan did not want more because real programmers don't need more.
>> That seems entirely at odds with almost everything I've read by him.
>> For example, in 1974 -- four years before K&R 1 and more than a decade
>> before the ANSI standard he was advising, as a matter of style, to make
>> external identifiers unique in the first 6 characters. That was, as you
>> probably know, common at the time. Note, as a matter of style, not "you
>> don't need more" just that you may hit a linker limit if you assume that
>> more will be unique.

>
> IIRC, the MVS LKED


Correction, now that I've checked my archived JCL: the MVS Linkage Editor
was programname IEWL, later replaced by HEWL when LE370 came along.

> linkage editor of the time had a 6-character limit on
> the size of external names. The VSE linkage editor had a similar limit.




--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      10-26-2013
Lew Pitcher <(E-Mail Removed)> wrote:

(snip, someone wrote)
>> Maybe we are talking at cross purposes. You quote suggests that
>> Kernighan did not want more because real programmers don't need more.
>> That seems entirely at odds with almost everything I've read by him.
>> For example, in 1974 -- four years before K&R 1 and more than a decade
>> before the ANSI standard he was advising, as a matter of style, to make
>> external identifiers unique in the first 6 characters. That was, as you
>> probably know, common at the time. Note, as a matter of style, not "you
>> don't need more" just that you may hit a linker limit if you assume that
>> more will be unique.


> IIRC, the MVS LKED linkage editor of the time had a 6-character
> limit on the size of external names. The VSE linkage editor had
> a similar limit.


I don't know the DOS/360 or VSE well at all, but from OS/360 through
to MVS the limit is eight. Eight is a favorite number. Jobnames are
eight, DDnames are eight, PDS member names are eight, and DSNames
in the catalog have at most eight between periods.

VM/370 and descendants have eight character filenames and filetypes
(what many call extensions).

The six character limits came from BCD on the 36 bit machines,
and later SIXBIT on the DEC 36 bit machines.

> It wasn't too long later (a few years) that IBM came up with
> the LE370 tools that extended both the assembler and linkage
> editor to handle larger external names, and added a native C
> compiler to the language support.


Well, PL/I allowed longer names, too, but IBM restricted
external names by using, I believe, the first four and last
three characters. (Allows for more than one CSECT per PROC.)
LE is convenient for both PL/I and C. Is there a Fortran 90
compiler?

-- glen
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Parallel processing on shared data structures psaffrey@googlemail.com Python 2 03-20-2009 08:05 AM
gc penalty of 30-40% when manipulating large data structures? Aaron Watters Python 2 11-16-2007 04:43 PM
structures, structures and more structures (questions about nestedstructures) Alfonso Morra C Programming 11 09-24-2005 07:42 PM
Type Casting IPv4 and IPv6 structures to Generic Structures tweak C Programming 14 06-11-2004 02:43 PM
RegEx for changing linefeeds to <BR> except between <PRE></PRE> tags? Rocky Moore ASP .Net 7 01-14-2004 09:43 PM



Advertisments