>From owner-current-users@NetBSD.ORG Wed Feb 28 03:39:43 1996
>To: current-users@NetBSD.ORG
>Xref: endicor.com netbsd.current.users:9777
>Newsgroups: netbsd.current.users
>From: tsarna@endicor.com (Ty Sarna)
>Subject: Re: Tcl7.5 and NetBSD-current
>Organization: Endicor Technologies, Inc., San Antonio, Texas
>References: <199602271217.GAA18522@solutions.solon.com>
>Date: Tue, 27 Feb 1996 23:58:40 GMT
>Sender: owner-current-users@NetBSD.ORG
>Precedence: list
>X-Loop: current-users@NetBSD.ORG
>
>In article <199602271217.GAA18522@solutions.solon.com>,
>Peter Seebach  <seebs@solon.com> wrote:
>> long long is *forbidden* by ANSI.  The list "char short int long" is an

>Please quote the sections(s) of ANSI that say so.

That which is not defined is undefined.  And long long (in particular)
is a syntax error.

It is legit for opaque types to be larger than long, maybe, but it's not
legit for there to be syntax errors in the header.  I'd be fine with
__int64_t.

>> Any implementation on which you need to use an extension to get at basic
>> functionality is nonconforming.

>off_t is not "basic functionality" as far as ANSI C is concerned.

But fpos_t is.  :)

>> The last time this came up, it was pointed out (correctly, I believe) that

>The last time this came up, I believe you wanted int to be 64 bits and
>long 32,

No... I think long should be the longest type, and int the most comfortable
type (but possibly 32 bits on the alpha, just so there's enough types to
go around.)  That should hold us until ANSI fixes it for C9X.

As noted, this can create significant problems for programs that expect
tolerable performance using long, and break naive software that expects
long and int, or long and (void *), to be the same type.  On the bright
side, we wouldn't have had this tcl problem, and we could use more warnings
on gcc.  :)

In defense of performance, the original reference implementation had 16
bit ints and 32 bit longs on a machine where 8 bits was the natural size.

>which if implemented according to the standard (allowed, but
>the 64 bit int would only be allowed to have the same range of
>representable values as the 32 bit int) would be useless.

It certainly would.  I would not want int to be larger than long.

>If you want to make all sorts of drastic changes to the OS (removing
>wildcard expansion from the shell, removing ioctl(), etc), maybe you
>should be looking for a different OS?

:)
I don't actually want to remove wildcards from the shell, or anything
like that.  I'd just like to see some of the features migrated to wherever
they belong.  (Although the old interfaces should obviously be there.)
(For instance, glob appears to be in the library these days.  This Is Good.)

-s