The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] v7 K&R C
@ 2020-04-25  1:59 Adam Thornton
  2020-04-25  2:37 ` Charles Anthony
  0 siblings, 1 reply; 153+ messages in thread
From: Adam Thornton @ 2020-04-25  1:59 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 698 bytes --]

The C in v7 is, canonically, the language described in K&R, right?

I must be doing something dumb.

I am getting Webb Miller’s “s” editor built there, and I am down to one function.

/* chop_arg - chop a function's argument to a maximum length */
static chop_arg(fcn, arg, maxlen)
int (*fcn)();
int maxlen;
char *arg;
{
    char save;

    save = arg[maxlen];
    arg[maxlen] = '\0';
    fcn(arg);
    arg[maxlen] = save;
}

This doesn’t like the function pointer.

$ cc -c choparg.c
choparg.c:11: Call of non-function

So, uh, what is the obvious thing I am missing?  How am I supposed to be passing function pointers in the C compiler that comes with v7?

Adam

[-- Attachment #2: Type: text/html, Size: 2250 bytes --]

^ permalink raw reply	[flat|nested] 153+ messages in thread
* Re: [TUHS] v7 K&R C
@ 2020-04-25 13:11 Noel Chiappa
  2020-04-25 13:18 ` Rob Pike
  2020-04-25 13:35 ` Hellwig Geisse
  0 siblings, 2 replies; 153+ messages in thread
From: Noel Chiappa @ 2020-04-25 13:11 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Rob Pike

    > Convenient though the shorthand may be, it always bothered me as
    > inconsistent and misleading.

As someone who made very extensive use of procedure pointers (most notably in
upcalls, which never caught on, alas), I couldn't agree more.

Two very different things are happenging, but with the shorthand notation,
they share an identical representation. And for what? To save three characters?

     Noel


^ permalink raw reply	[flat|nested] 153+ messages in thread
* Re: [TUHS] v7 K&R C
@ 2020-04-25 19:41 Noel Chiappa
  2020-04-25 20:27 ` Steffen Nurpmeso
  0 siblings, 1 reply; 153+ messages in thread
From: Noel Chiappa @ 2020-04-25 19:41 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: moanga

    >> To make chaining of calls simpler. Write
    >>   f()->g()->h()->i()

Ah; I was confused by his notation; I didn't realize he meant the C operator
'->'.

	Noel


^ permalink raw reply	[flat|nested] 153+ messages in thread
* Re: [TUHS] v7 K&R C
@ 2020-04-27 17:45 Noel Chiappa
  2020-04-27 17:56 ` Richard Salz
                   ` (2 more replies)
  0 siblings, 3 replies; 153+ messages in thread
From: Noel Chiappa @ 2020-04-27 17:45 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Derek Fawcus

    > I think he means something like:
    >    (*((*((*((*f)()->g))()->h))()->i))()

So I've been confused by this thread, and I'm hoping someone can deconfuse me
- but I think I may have figured it out.

What's confusing me is that in C, the -> operator is followed by "an
identifier [which] designates a member of a structure or union object" (I
checked the spec to make sure my memory hadn't dropped any bits) - but g, h
above are arguments; so I couldn't figure out what was going on.

I think what may have happened is that initially the discussion was about C
("Pretty sure it was not in v7 C"), but then it switched to C++ - with which
I'm not familiar, hence my confusion - without explicitly indicating that
change (although the reference to Bjarne Stroustrup should been a clue). (And
that's why I thought "f()->g()->h()->i()" was ad hoc notation for "calls f(),
then calls g()".)

Am I tracking now?

    Noel



^ permalink raw reply	[flat|nested] 153+ messages in thread
[parent not found: <mailman.1.1589421601.13778.tuhs@minnie.tuhs.org>]
* Re: [TUHS] v7 K&R C
@ 2020-05-14 18:41 Doug McIlroy
  2020-05-14 18:45 ` Richard Salz
                   ` (2 more replies)
  0 siblings, 3 replies; 153+ messages in thread
From: Doug McIlroy @ 2020-05-14 18:41 UTC (permalink / raw)
  To: tuhs

> o operator overloading
>
> I never could figure out why Stroustrup implemented that "feature"; let's
> see, this operator usually means this, except when you use it in that
> situation in which case it means something else.  Now, try debugging that.

Does your antipathy extend to C++ IO and its heavily overloaded << and >>?

The essence of object-oriented programming is operator overloading. If you
think integer.add(integer) and matrix.add(matrix) are good, perspicuous,
consistent style, then you have to think that integer+integer and
matrix+matrix are even better. To put it more forcefully: the OO style
is revoltingly asymmetric. If you like it why don't you do everyday
arithmetic that way?

I strongly encouraged Bjarne to support operator overloading, used it
to write beautiful code, and do not regret a bit of it. I will agree,
though, that the coercion rules that come along with operator (and
method) overloading are dauntingly complicated. However, for natural uses
(e.g. mixed-mode arithmetic) the rules work intuitively and well.

Mathematics has prospered on operator overloading, and that's why I
wanted it. My only regret is that Bjarne chose to set the vocabulary of
infix operators in stone. Because there's no way to inroduce new ones,
users with poor taste are tempted to recycle the old ones for incongruous
purposes.

C++ offers more features than C and thus more ways to write obscure code.
But when it happens, blame the writer, not the tool.

Doug


^ permalink raw reply	[flat|nested] 153+ messages in thread
* Re: [TUHS] v7 K&R C
@ 2020-05-15 20:34 Doug McIlroy
  2020-05-15 20:40 ` Warner Losh
  0 siblings, 1 reply; 153+ messages in thread
From: Doug McIlroy @ 2020-05-15 20:34 UTC (permalink / raw)
  To: tuhs

> I feel the essence of object-oriented computing
> is not operator overloading but the representation of behavior.

Rob is right. Overloading is a universal characteristic
of OO programming, but not the essence.

Doug

^ permalink raw reply	[flat|nested] 153+ messages in thread
* Re: [TUHS] v7 K&R C
@ 2020-05-15 21:31 Richard Tobin
  2020-05-15 21:53 ` Steve Nickolas
  2020-05-17 16:10 ` Derek Fawcus
  0 siblings, 2 replies; 153+ messages in thread
From: Richard Tobin @ 2020-05-15 21:31 UTC (permalink / raw)
  To: Steve Nickolas, ron; +Cc: tuhs

> Isn't it nonstandard (although I am aware of some compilers that do it) to 
> default the type of char to unsigned?

No.

  "The implementation shall define char to have the same range,
  representation, and behavior as either signed char or unsigned char."
  - C99

(Technically it's a separate type from both of them.)

-- Richard

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


^ permalink raw reply	[flat|nested] 153+ messages in thread
* Re: [TUHS] v7 K&R C
@ 2020-05-16  0:15 Nelson H. F. Beebe
  2020-05-16  0:28 ` Steffen Nurpmeso
  2020-05-16  1:52 ` Warner Losh
  0 siblings, 2 replies; 153+ messages in thread
From: Nelson H. F. Beebe @ 2020-05-16  0:15 UTC (permalink / raw)
  To: tuhs

Discussions today on the TUHS list about the signed/unsigned nature of
the C char type led me to reexamine logs of my feature test package at

	http://www.math.utah.edu/pub/features/

I had 170 build logs for it from 2017.11.07, so I moved those aside
and ran another set of builds in our current enlarged test farm.  That
generated another 361 fresh builds.  Those tests are all with the C
compiler named "cc".  I did not explore what other C compilers did,
but I strongly suspect that they all agree on any single platform.

On all but THREE systems, the tests report that "char" is signed, with
CHAR_MAX == +127.

The three outliers have char unsigned with CHAR_MAX == +255, and are

	* ARM armv7l Linux 4.13.1 (2017) and 5.6.7 (2020)
	* SGI O2 R10000-SC (150 MHz) IRIX 6.5 (2017 and 2020)
	* IBM POWER8 CentOS Linux release 7.4.1708 (AltArch) (2017)

So, while the ISO C Standards, and historical practice, leave it
implementation dependent whether char is signed or unsigned, there is
a strong majority for a signed type.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe@math.utah.edu  -
- 155 S 1400 E RM 233                       beebe@acm.org  beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

^ permalink raw reply	[flat|nested] 153+ messages in thread
* Re: [TUHS] v7 K&R C
@ 2020-05-16 18:45 Richard Tobin
  2020-05-16 21:55 ` Ronald Natalie
  0 siblings, 1 reply; 153+ messages in thread
From: Richard Tobin @ 2020-05-16 18:45 UTC (permalink / raw)
  To: Paul Winalski, The Eunuchs Hysterical Society

> The function prototype for getchar() is:    int getchar(void);
> 
> It returns an int, not a char.  In all likelihood this is specifically
> *because* EOF is defined as -1.

It would have probably returned int anyway, because of the automatic
promotion of char to int in expressions.  It was natural to declare
functions returning char as int, if you bothered to declare them at
all.  As K&R1 said:

  Since char promotes to int in expressions, there is no need
  to declare functions that return char.

Similarly functions that might return short or float would normally
return int or double; there aren't separate atof and atod functions
for example.

-- Richard

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


^ permalink raw reply	[flat|nested] 153+ messages in thread
* Re: [TUHS] v7 K&R C
@ 2020-05-18 13:58 Doug McIlroy
  0 siblings, 0 replies; 153+ messages in thread
From: Doug McIlroy @ 2020-05-18 13:58 UTC (permalink / raw)
  To: tuhs

>  [A]lthough these days "byte" is synonymous with "8 bits", historically it
>  meant "the number of bits needed to store a single character".

It depends upon what you mean by "historically". Originally "byte"
was coined to refer to 8 bit addressable units on the IBM 7030 "Stretch"
computer. The term was perpetuated for the 360 family of computers. Only
later did people begin to attribute the meaning to non-addressable
6- or 9-bit units on 36- and 18-bit machines.  

Viewed over history, the latter usage was transient and colloquial.

Doug

^ permalink raw reply	[flat|nested] 153+ messages in thread
* Re: [TUHS] v7 K&R C
@ 2020-05-18 14:33 Doug McIlroy
  0 siblings, 0 replies; 153+ messages in thread
From: Doug McIlroy @ 2020-05-18 14:33 UTC (permalink / raw)
  To: tuhs

They are flagging non-portable usage.


^ permalink raw reply	[flat|nested] 153+ messages in thread
* Re: [TUHS] v7 K&R C
@ 2020-05-19  2:29 Doug McIlroy
  2020-05-19  3:20 ` Steve Nickolas
  0 siblings, 1 reply; 153+ messages in thread
From: Doug McIlroy @ 2020-05-19  2:29 UTC (permalink / raw)
  To: tuhs

I should have checked my 7030 manual before asserting
that the 8-bit byte came from there. The term did,
but it meant an addressable unit of 1 to 8 bits
depending on the instruction being executed.

[The machine was addressable to the bit. It also
had all 16 bitwise logical operators, and
maintained counts of the 1 bits and leading
0 bits in a register. And it was BIG. I saw
one with 17 memory boxes (each essentially
identical with the total memory of a 7090)
stretched across the immaculate hardwood
floor of IBM's Poughkeepsie plant.]

Doug

^ permalink raw reply	[flat|nested] 153+ messages in thread
* Re: [TUHS] v7 K&R C
@ 2020-05-19 12:29 Noel Chiappa
  0 siblings, 0 replies; 153+ messages in thread
From: Noel Chiappa @ 2020-05-19 12:29 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

There was a recent message I now can't find that I wanted to reply to,
something about which type to use to get a certain effect.

I wanted to reply to say that I felt that it was not really the best way to
go, to have one set of type names that tried to denote both i) the semantics
of the data, and ii) the size of the item, using arbitrary names.

This came up for me when we started to try and write portable networking code.
There, you need to be able to specify very precisely how long fields are
(well, in lower-level protocols, which use non-printable formats). How to do
that in a way that was portable, in the compilers of the day, was a real
struggle. (It might be doable now, but I think the fixes that allowed it were
still just patches to something that had gone in the wrong direction, above.)

I created a series of macros for type definitions, ones that separately and
explicitly specified the semantics and size. They looked like 'xxxy', where
'xxx' was the semantics (signed and unsigned integers, bit field, etc),
and 'y' was a length indication (byte, short, long, and others). So you'd
see things like 'unsb' and 'intl'.

The interesting twist was a couple of unusual length specifiers; among them,
'w' stood for 'the machine's natural word length', and 'f' meant 'no
particular length, just whatever's fastest on this architecture/compiler, and
at least 16 bits'. The former was useful in OSy type code; the latter for
locals and things where nobody outside the machine would see them.

Then you'd have to have a file of macro definitions (only one per machine)
which translated them all into the local architecture/compiler - some didn't
go, of course (no 'unsb' on a PDP-11), but it all worked really, really well,
for many years.

E.g. at one point, as a dare/hack, I said I'd move the MOS operating system, a
version written in portable C (with that type name system) to the AMD 29000
over one night. This wasn't totaly crazy; I'd already gotten the debugger (a
DDT written in similar portable C) to run on the machine, so I knew where the
potholes were. I'd have to write a small amount of machine language (which I
could traslate from the M68K version), but most of it should just compile and
go. I didn't quite make it, it wasn't quite running when people started coming
in the next morning; but IIRC it started to work later that day.

   Noel

^ permalink raw reply	[flat|nested] 153+ messages in thread

end of thread, other threads:[~2020-06-15  6:07 UTC | newest]

Thread overview: 153+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-25  1:59 [TUHS] v7 K&R C Adam Thornton
2020-04-25  2:37 ` Charles Anthony
2020-04-25  2:47   ` Adam Thornton
2020-04-25  2:51     ` Rob Pike
2020-04-25  2:54       ` Rob Pike
2020-04-25  3:04         ` Larry McVoy
2020-04-25  3:30           ` Clem Cole
2020-04-25  3:43             ` Larry McVoy
2020-04-25  3:54               ` Jon Steinhart
2020-04-25 11:44                 ` Michael Kjörling
2020-04-25 13:17             ` Dan Cross
2020-05-11  0:28         ` scj
2020-05-11  0:32           ` Rob Pike
2020-05-11  0:57             ` Larry McVoy
2020-05-11 17:32               ` Greg A. Woods
2020-05-11 18:25                 ` Paul Winalski
2020-05-11 18:37                   ` Clem Cole
2020-05-11 19:12                     ` Paul Winalski
2020-05-11 19:57                       ` joe mcguckin
2020-05-11 20:25                         ` Larry McVoy
2020-05-12 17:23                           ` Paul Winalski
2020-05-12 17:35                             ` ron
2020-05-12 17:42                               ` Larry McVoy
2020-05-12 18:36                               ` Paul Winalski
2020-05-13 23:36                             ` Dave Horsfall
2020-05-14  0:42                               ` John P. Linderman
2020-05-14  2:44                                 ` Rich Morin
2020-05-14  3:09                                   ` Charles Anthony
2020-05-14 12:27                                     ` ron
2020-05-14 12:27                                     ` ron
2020-05-14 12:27                                     ` ron
2020-05-14  7:38                                   ` Dave Horsfall
2020-05-14 12:25                                     ` ron
2020-05-14 17:13                                   ` Paul Winalski
2020-05-14 17:21                                 ` Larry McVoy
2020-05-17 16:34                                   ` Derek Fawcus
2020-05-14  4:21                               ` Greg A. Woods
2020-05-14  4:40                                 ` Warner Losh
2020-05-14 17:32                               ` Larry McVoy
2020-05-14 22:32                                 ` Tony Finch
2020-05-16 23:53                                   ` Steffen Nurpmeso
2020-05-16 23:59                                     ` [TUHS] v7 K&R C [really lexers] Jon Steinhart
2020-05-17  0:04                                       ` Brantley Coile
2020-05-17  1:23                                         ` Warner Losh
2020-05-17  1:36                                           ` Brantley Coile
2020-06-13 21:24                                           ` scj
2020-06-14  8:47                                             ` arnold
2020-06-14 12:52                                             ` Richard Salz
2020-06-14 14:03                                               ` Ralph Corderoy
2020-06-14 14:26                                                 ` arnold
2020-06-14 14:48                                                   ` Ralph Corderoy
2020-06-15  1:12                                                     ` Warren Toomey
2020-06-15  1:29                                                       ` Warren Toomey
2020-06-15  6:06                                                         ` arnold
2020-05-17 16:31                                       ` Paul Winalski
2020-05-17  0:35                                     ` [TUHS] v7 K&R C Larry McVoy
2020-05-11 18:37                   ` Larry McVoy
2020-05-11  2:08           ` Lawrence Stewart
2020-05-11 11:36           ` Michael Kjörling
2020-04-25  3:37       ` Dave Horsfall
2020-04-27 13:19       ` Tony Finch
2020-04-25  2:50   ` Adam Thornton
2020-04-25  5:59     ` Lars Brinkhoff
2020-04-25 13:11 Noel Chiappa
2020-04-25 13:18 ` Rob Pike
2020-04-25 14:57   ` Warner Losh
2020-04-25 18:03   ` Noel Chiappa
2020-04-25 20:11     ` Michael Kjörling
2020-04-25 21:27       ` Brian L. Stuart
2020-04-26  0:07     ` emanuel stiebler
2020-04-26  0:54     ` Rob Pike
2020-04-26 19:37     ` Derek Fawcus
2020-04-26 20:10       ` Derek Fawcus
2020-04-26 21:59         ` Rich Morin
2020-04-26 22:38         ` Noel Hunt
2020-04-26 23:57         ` Nemo Nusquam
2020-04-27  3:38           ` Rob Pike
2020-04-25 13:35 ` Hellwig Geisse
2020-04-25 13:59   ` Richard Salz
2020-04-25 19:01   ` Brian L. Stuart
2020-04-25 20:07     ` Michael Kjörling
2020-04-25 21:34       ` Brian L. Stuart
2020-04-26  6:40     ` arnold
2020-04-25 19:41 Noel Chiappa
2020-04-25 20:27 ` Steffen Nurpmeso
2020-04-27 17:45 Noel Chiappa
2020-04-27 17:56 ` Richard Salz
2020-04-27 18:02 ` Brantley Coile
2020-04-27 18:47 ` Derek Fawcus
     [not found] <mailman.1.1589421601.13778.tuhs@minnie.tuhs.org>
2020-05-14  3:02 ` Paul McJones
2020-05-14 17:08   ` Paul Winalski
2020-05-14 17:58     ` Clem Cole
2020-05-14 18:41 Doug McIlroy
2020-05-14 18:45 ` Richard Salz
2020-05-14 20:54 ` Clem Cole
2020-05-15  2:44 ` Rob Pike
2020-05-15  3:57   ` Rich Morin
2020-05-15  7:55   ` Dr Iain Maoileoin
2020-05-15 15:01     ` Larry McVoy
2020-05-15 15:36       ` John P. Linderman
2020-05-15 20:01         ` ron
2020-05-15 20:03           ` Larry McVoy
2020-05-15 20:05           ` Clem Cole
2020-05-15 20:18             ` ron
2020-05-15 20:24               ` Clem Cole
2020-05-16  0:57               ` Brantley Coile
2020-05-16 16:14                 ` Dan Cross
2020-05-15 20:56           ` Steve Nickolas
2020-05-16  0:31             ` Peter Jeremy
2020-05-16  8:30               ` Steve Nickolas
2020-05-16  0:43           ` John P. Linderman
2020-05-16 16:28             ` Paul Winalski
2020-05-16 17:39               ` Warner Losh
2020-05-19 19:45                 ` Peter Pentchev
2020-05-20  3:52                   ` Rich Morin
2020-05-21 15:06                     ` Dave Horsfall
2020-05-15 20:34 Doug McIlroy
2020-05-15 20:40 ` Warner Losh
2020-05-15 21:31 Richard Tobin
2020-05-15 21:53 ` Steve Nickolas
2020-05-15 22:33   ` ron
2020-05-15 23:34     ` Steffen Nurpmeso
2020-05-16  1:26       ` Larry McVoy
2020-05-16 21:59       ` Ronald Natalie
2020-05-16 23:26         ` Steffen Nurpmeso
2020-05-17 16:24           ` Paul Winalski
2020-05-17 16:29             ` ron
2020-05-17 16:38               ` Paul Winalski
2020-05-17 20:08                 ` Clem Cole
2020-05-18  8:46                   ` Peter Jeremy
2020-05-19  7:41                     ` Dave Horsfall
2020-05-18 12:04             ` Tony Finch
2020-05-18 13:10               ` Clem Cole
2020-05-18 15:13             ` Rich Morin
2020-05-18 15:51               ` Brantley Coile
2020-05-18 16:11             ` Dan Cross
2020-05-18 21:18               ` ron
2020-05-17 16:10 ` Derek Fawcus
2020-05-17 16:14   ` ron
2020-05-16  0:15 Nelson H. F. Beebe
2020-05-16  0:28 ` Steffen Nurpmeso
2020-05-16  1:52 ` Warner Losh
2020-05-16 16:31   ` Paul Winalski
2020-05-16 20:35     ` Brad Spencer
2020-05-16 20:37       ` Warner Losh
2020-05-18 12:25     ` Tony Finch
2020-05-16 18:45 Richard Tobin
2020-05-16 21:55 ` Ronald Natalie
2020-05-18 13:58 Doug McIlroy
2020-05-18 14:33 Doug McIlroy
2020-05-19  2:29 Doug McIlroy
2020-05-19  3:20 ` Steve Nickolas
2020-05-19 12:29 Noel Chiappa

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).