15 Oct
2005
15 Oct
'05
4:26 a.m.
Paul Koning <pkoning at equallogic.com> wrote:
C is the obvious choice. In either case, you have to
be careful that
you don't wreck the portability by using non-portable I/O.
Er, how big is an int? a pointer?
**vp
15 Oct
15 Oct
4:48 a.m.
Vassilis Prevelakis wrote:
Paul Koning <pkoning at equallogic.com> wrote:
well a ant is small , a pointer is some kind of dog. The most real
non-portable
C factor is everybody expects bytes to 8 bits and CR,LF line endings are
a bitch.
I think a character can be 7 or more bits, a int something bigger like
16. ( As
far as I know C never made it to a PDP8 ).
C is the obvious choice. In either case, you have
to be careful that
you don't wreck the portability by using non-portable I/O.
Er, how big is an int? a pointer?
**vp
.
2:03 p.m.
>>C
>Er, how big is an int? a pointer?
although often sizes such as 16 bits or 32 bits, an int is whatever sized
group of bytes is most "comfortable and convenient" for the processor to
handle. However, the defined size for an int must not be smaller than the
defined size for a short int, nor larger than the defined size of a long
int. Negative numbers are often represented in 2s complement notation,
but that is purely implementation dependent, and CAN be done in other
ways.
A pointer is whatever size, and configuration, is needed to refer to a
specific memory location. It can even be used to refer to a 16 bit offset
within a segment, or even as a 32 bit quantity that is actually a
structure of two 16 bit quantities (far * v segment:offset)
It has sometimes been recommended, in order to further current forms of
abuse, that the sizes of various variable types should not be relatively prime.
FORTRAN (The Devils' DP Dictionary.)
FORTRAN n [Acronym for Formula Translation system.]
One of the earliest languages of any real height, level-wise, developed
out of Speedcoding by Backus and Ziller for the IBM/704 in the mid-1950s
in order to boost the sales of 80-column cards to engineers.
In spite of regular improvements (including a recent option called
STRUCTURE), it remains popular among engineers but despised elsewhere.
Many rivals, with the benefit of hindsight, have crossed swords with the
old workhorse! Yet FORTRAN gallops on, warts and all, more transportable
than syphilis, fired by a bottomless pit of working subprograms. Lacking
the compact power of APL, the intellectually satisfying elegance of ALGOL
68, the didactic incision of pascal, and the spurned universality of PL/1,
FORTRAN survives, nay flourishes, thanks to superior investmental inertia.
http://www.sysprog.net/quotcob.html
http://en.wikiquote.org/wiki/Edsger_Dijkstra
17 Oct
17 Oct
2:09 p.m.
New subject: OT: Language for the ages
On 10/15/05, woodelf <bfranchuk at jetnet.ab.ca> wrote:
The most real non-portable C factor is everybody expects bytes to 8 bits
and CR,LF line endings are
a bitch. I think a character can be 7 or more bits, a int something bigger
like 16. ( As far as I know C never made it to a PDP8 ).
I'm not sure what you mean about CR-LF line endings being a problem for C.
For text files the character '\n' returns the appropriate ending, whether it
is CR-LF, CR, or LF. For binary files you shouldn't need to write carriage
returns.
Integral types in C aren't difficult. They are just flexible, and because
they are flexible, you need to know the rules.
A char needs to be able to hold at least 127 unique values which makes it at
least 7 bits with one allowed "non-unique" value (for example +0 and -0
allowed to have different bit patterns but compare equal, or a value can be
reserved for other purposes (signaling, I/O, etc)). That makes it a bit
different from the other integral types which are required to behave in
standard two's compliment fashion. Regardless of the number of bits or
machine words used to store a char, the size of a char is 1
(sizeof(char)==1). If you want to know the number of "bits" in a char,
there's always the CHAR_BIT macro. Whether char is unsigned or signed is
implementation dependent. If you need one or the other use "signed char" or
"unsigned char".
An int needs to hold at least 65536 unique values (-32768..32767) (16 bits).
I believe that it is required to be at least as large as a char. An unsigned
long needs to be able to hold the values between 0 and 65535. Arithmetic
must behave as if the numbers are stored as two's compliment [ (x | -1) ==
-1 , (x & -1) == x ]
A long needs to be at least 32 bits and must the at least as large as an
int.
The size of a pointer needs to be at least as large as an int. Pointers to
one type are not necessarily convertable to pointers to another type,
although all pointers can be cast to void *. Avoid converting pointers into
integral types. Do pointer math on pointers.
4:15 p.m.
New subject: OT: Language for the ages
On Mon, 17 Oct 2005, Eric J Korpela wrote:
I'm not sure what you mean about CR-LF line
endings being a problem for C.
For text files the character '\n' returns the appropriate ending, whether it
is CR-LF, CR, or LF. For binary files you shouldn't need to write carriage
returns.
... and transferring a text file from one OS to another, . . .
does CR mean \n, or is it being used for overstrike?
does LF mean \n, or is it being used for formatted tables?
does CRLF mean \n, or is it double spacing?
Integral types in C aren't difficult. They are
just flexible, and because
they are flexible, you need to know the rules.
"rules"???????
Who's rules? K&R very strenuously avoids defining the sizes.
A char needs to be able to hold at least 127 unique
values which makes it at
ONLY IF YOU'RE USING ASCII
least 7 bits with one allowed "non-unique"
value (for example +0 and -0
allowed to have different bit patterns but compare equal, or a value can be
reserved for other purposes (signaling, I/O, etc)). That makes it a bit
different from the other integral types which are required to behave in
standard two's compliment fashion. Regardless of the number of bits or
machine words used to store a char, the size of a char is 1
(sizeof(char)==1). If you want to know the number of "bits" in a char,
there's always the CHAR_BIT macro. Whether char is unsigned or signed is
^^^^^^
NOT all compilers have that macro.
implementation dependent. If you need one or the other
use "signed char" or
"unsigned char".
An int needs to hold at least 65536 unique values (-32768..32767) (16 bits).
NOT
NECESSARILY.
There HAVE been implementations of 12, 14, 15 bits.
I believe that it is required to be at least as large
as a char. An unsigned
long needs to be able to hold the values between 0 and 65535. Arithmetic
must behave as if the numbers are stored as two's compliment [ (x | -1) ==
-1 , (x & -1) == x ]
2's complEment (we're here to "complete" them, not to praise them)
works
very nicely, but C CAN be implemented with alternate encodings.
A long needs to be at least 32 bits and must the at
least as large as an
int.
NOT NECESSARILY.
24 bits for both int and long might not be a good idea, but it is still
"valid"
The size of a pointer needs to be at least as large as
an int.
IFF we assume that the number of possible ints is as large as an int
Pointers to
one type are not necessarily convertable to pointers to another type,
although all pointers can be cast to void *. Avoid converting pointers into
integral types. Do pointer math on pointers.
... and miss out on the fun??
5:03 p.m.
New subject: OT: Language for the ages
On 10/17/05, Fred Cisin <cisin at xenosoft.com> wrote:
This has nothing to do with ASCII or anything else. One of the first things
you learn in C is that 'char' isn't really short for character. 'char'
is
short for byte (aka the minimum readily addressable memory element). In C, a
char needs to be able to hold at least 127 unique values. A char might be 64
bits. A 12 bit char might hold three characters of a string on 12 bit
machine.
All ISO compliant ones do.
Of course it can on a turing complete machine. But if there is and alternate
encoding it MUST be hidden from the programmer (again under the standard).
assert((x|-1) == -1) is not allowed to fail if x is an integral type.
On Mon, 17 Oct 2005, Eric J Korpela wrote:
I guess I forgot that one. In that case you do use binary mode and use '\n'
for LF and '\r' for CR. But then again if you know what system you are
transporting to you can just do something like
char LF=10, CR=13;
char CRLF[]={10,13};
I'm not sure what you mean about CR-LF line
endings being a problem for
C.
For text files the character '\n' returns
the appropriate ending,
whether it
is CR-LF, CR, or LF. For binary files you
shouldn't need to write
carriage
returns.
... and transferring a text file from one OS to another, . . .
does CR mean \n, or is it being used for overstrike?
does LF mean \n, or is it being used for formatted tables?
does CRLF mean \n, or is it double spacing? Integral types in C aren't difficult. They are
just flexible, and because
The ISO's rules, of course. The ISO standard is 16 years old now.
they are flexible, you need to know the rules.
"rules"???????
Who's rules? K&R very strenuously avoids defining the sizes. A char needs
to be able to hold at least 127 unique values which makes
it at
ONLY IF YOU'RE USING ASCII least 7 bits
with one allowed "non-unique" value (for example +0 and -0
allowed to have different bit patterns but compare equal, or a value can
be
reserved for other purposes (signaling, I/O,
etc)). That makes it a bit
different from the other integral types which are required to behave in
standard two's compliment fashion. Regardless of the number of bits or
machine words used to store a char, the size of a char is 1
(sizeof(char)==1). If you want to know the number of "bits" in a char,
there's always the CHAR_BIT macro. Whether char is unsigned or signed is
^^^^^^
NOT all compilers have that macro. An int needs to hold at least 65536 unique values
(-32768..32767) (16
bits).
NOT NECESSARILY.
There HAVE been implementations of 12, 14, 15 bits.
Also not ISO compliant. If you've got a 15 bit machine, an ISO C
implementation will probably have 30 bit integers and 45 bit longs.
I believe that
it is required to be at least as large as a char. An
unsigned
long needs to be able to hold the values between
0 and 65535. Arithmetic
must behave as if the numbers are stored as two's compliment [ (x | -1)
==
-1 , (x & -1) == x ]
2's complEment (we're here to "complete" them, not to praise them)
works
very nicely, but C CAN be implemented with alternate encodings. A long needs to be at least 32 bits and must the at
least as large as an
Again, this is not compliant with the standard for the C language and
therefore not "valid."
int.
NOT NECESSARILY.
24 bits for both int and long might not be a good idea, but it is still
"valid" The size of a pointer needs to be at least as large as
an int.
IFF we assume that the number of possible ints is as large as an int
I assume you meant addresses where you said "ints"? Actually you may be
correct on this one so long as pointer math works according to the standard.
Eric
8:34 p.m.
New subject: OT: Language for the ages
On Mon, 17 Oct 2005, Eric J Korpela wrote:
Oh. OK. The "NEW" version of C (v K&R)
Actually, I AGREE with those size recommendations.
I LIKE having 8 bit chars, 16 bit ints, 32 bit longs;
but there are some bizarre vintage implementations out there,
and on the old stuff, you can not count on a specific size.
--
Grumpy Ol' Fred cisin at xenosoft.com
"rules"???????
Who's rules? K&R very strenuously avoids defining the sizes.
The ISO's
rules, of course. The ISO standard is 16 years old now. 
18 Oct
18 Oct
6:07 a.m.
New subject: OT: Language for the ages
Fred Cisin wrote:
On Mon, 17 Oct 2005, Eric J Korpela wrote:
Oh. OK. The "NEW" version of C (v K&R)
Actually, I AGREE with those size recommendations.
I LIKE having 8 bit chars, 16 bit ints, 32 bit longs;
but there are some bizarre vintage implementations out there,
and on the old stuff, you can not count on a specific size.
But only because the hardware you're used to using C on suits these sizes.
Gordon.
"rules"???????
Who's rules? K&R very strenuously avoids defining the sizes.
The ISO's rules, of course. The ISO standard is 16 years old now.
6:44 p.m.
New subject: OT: Language for the ages
Actually, I
AGREE with those size recommendations.
I LIKE having 8 bit chars, 16 bit ints, 32 bit longs;
but there are some bizarre vintage implementations out there,
and on the old stuff, you can not count on a specific size.
But only because the hardware you're used to using
C on suits these sizes.
You're absolutely right.
I like those sizes, because they're a good fit with my hardware.
19 Oct
19 Oct
12:27 p.m.
New subject: OT: Language for the ages
Fred Cisin wrote:
On Tue, 18 Oct
2005, Gordon JC Pearce wrote:
... therefore using an 18-bit int would be silly. If you were using a
machine with a 9-bit byte length (not parity, actually 9 bits) then it
wouldn't seem such a bad idea.
Gordon.
Actually, I AGREE with those size recommendations.
I LIKE having 8 bit chars, 16 bit ints, 32 bit longs;
but there are some bizarre vintage implementations out there,
and on the old stuff, you can not count on a specific size.
But only because the hardware you're used to
using C on suits these sizes.
You're absolutely right.
I like those sizes, because they're a good fit with my hardware.
12:48 p.m.
New subject: OT: Language for the ages
Gordon JC Pearce wrote:
Strange -- my hardware is just like that ( When I get it finshed ) .
The PDP-10 has done that already.
Oddly this homebrew I am working can't do real C, since now C is almost
allways 32 bit code and
I've got only a whoopping 64kb of ram. :( I think a 20 bit int is
also a nice size too and 10 bit bytes.
You're absolutely right.
I like those sizes, because they're a good fit with my hardware.
... therefore using an 18-bit int would be silly. If you were using a
machine with a 9-bit byte length (not parity, actually 9 bits) then it
wouldn't seem such a bad idea.
Gordon.
1:51 p.m.
New subject: OT: Language for the ages
On 10/19/2005 at 10:48 AM woodelf wrote:
Strange -- my hardware is just like that ( When I get
it finshed ) .
The PDP-10 has done that already.
Oddly this homebrew I am working can't do real C, since now C is almost
allways 32 bit code and
I've got only a whoopping 64kb of ram. :( I think a 20 bit int is
also a nice size too and 10 bit bytes.
Shades of the CDC 6000! The native character set was 6 bit "display code",
but when the time came to implement goodies like lower-case, the agony
started. What to do? There were several proposals running around for the
60-bit word. 12-bit bytes; 10 bit-bit bytes; even 8-bit bytes (packed 7.5
to a word with references to something called a "snaque"). IIRC,
eventually, an escape-sequence scheme was worked out--0000 (octal) was
defined as an end-of-line; 00-anything else was defined as an extended
character. I don't recall that anyone ever seriously suggested 7-bit
characters, but it would have made sense--8 to a word.
Cheers,
Chuck
15 Oct
15 Oct
10 a.m.
Ah, C. Then you have to re-argue the whole question of indentation,
depending on what your religion believes regarding what amount of
whitespace is holy and where it should be placed.
"Indentation- The Eightfold Path"
--Anonymous
01234567 <--The world famous Indent-o-Meter.
--Lloyd Zusman ljz at well.sf.ca.us
And my absolute favorite of all time:
"In My Egotistical Opinion, most people's C programs should be indented six
feet downward and covered with dirt."
--Blair P. Houghton
At 04:26 AM 10/15/2005 -0400, you wrote:
Paul Koning <pkoning at equallogic.com> wrote:
[Genius] Genius is one percent inspiration and ninety-nine percent
perspiration. --Thomas A. Edison
--... ...-- -.. . -. ----. --.- --.- -...
tpeters at nospam.mixcom.com (remove "nospam") N9QQB (amateur radio)
"HEY YOU" (loud shouting) WEB ADDRESS http//www.mixweb.com/tpeters
43? 7' 17.2" N by 88? 6' 28.9" W, Elevation 815', Grid Square
EN53wc
WAN/LAN/Telcom Analyst, Tech Writer, MCP, CCNA, Registered Linux User 385531
C is the obvious choice. In either case, you
have to be careful that
you don't wreck the portability by using non-portable I/O.
Er, how big is an int? a pointer?
**vp
1:31 p.m.
APL
It appears to be a subset of Egyption hieroglyphics,
and is obscure enough that there will be few attempts
to program in it by people ungamiliar with the language.
3:12 p.m.
On 10/15/2005 at 10:31 AM Fred Cisin wrote:
APL
It appears to be a subset of Egyption hieroglyphics,
and is obscure enough that there will be few attempts
to program in it by people ungamiliar with the language.
Is there any other language that suffers as much from the "one liner"
syndrome--that is, the perverse pride of being able to do something obscure
with a single unreadable line of code?
LISP maybe?
--Chuck
3:31 p.m.
New subject: OT: Language for the ages
Hi,
Chuck Guzis said:
On 10/15/2005 at 10:31 AM Fred Cisin wrote:
It used to be a popular pastime with FORTHers.
--
Cheers,
Stan Barr stanb at dial.pipex.com
The future was never like this!
APL
It appears to be a subset of Egyption hieroglyphics,
and is obscure enough that there will be few attempts
to program in it by people ungamiliar with the language.
Is there any other language that suffers as much from the "one liner"
syndrome--that is, the perverse pride of being able to do something obscure
with a single unreadable line of code?
LISP maybe?
4:24 p.m.
>APL
>It appears to be a subset of Egyption hieroglyphics,
>and is obscure enough that there will be few attempts
>to program in it by people ungamiliar with the language.
On Sat, 15 Oct 2005, Chuck Guzis wrote:
Is there any other language that suffers as much from
the "one liner"
syndrome--that is, the perverse pride of being able to do something obscure
with a single unreadable line of code?
LISP maybe?
C maybe.
while(*t++=*s++);
But APL is terse.
4:33 p.m.
On 10/15/2005 at 1:24 PM Fred Cisin wrote:
Yeah, but what can compare with this APL sample:
http://catb.org/~esr/jargon/html/O/one-liner-wars.html
The Perl example seems verbose by comparison.
As a solution to the original topic, has anyone yet suggested INTERCAL?
http://www.catb.org/~esr/intercal/
Cheers,
Chuck
>APL
>It appears to be a subset of Egyption hieroglyphics,
>and is obscure enough that there will be few attempts
>to program in it by people ungamiliar with the language.
On Sat, 15 Oct 2005, I wrote:
Is there any other language that suffers as much
from the "one liner"
syndrome--that is, the perverse pride of being able to do something
obscure
with a single unreadable line of code?
LISP maybe?
C maybe.
while(*t++=*s++); 
16 Oct
16 Oct
2:32 a.m.
Chuck Guzis wrote:
As a solution to the original topic, has anyone yet
suggested INTERCAL?
http://www.catb.org/~esr/intercal/
No, but I suggested Funge:
http://en.wikipedia.org/wiki/Befunge
Peace... Sridhar
15 Oct
15 Oct
6:10 p.m.
On Sat, 15 Oct 2005 12:12:23 -0700, Chuck Guzis wrote:
On 10/15/2005 at 10:31 AM Fred Cisin wrote:
>APL
>
>It appears to be a subset of Egyption hieroglyphics,
>and is obscure enough that there will be few attempts
>to program in it by people ungamiliar with the language.
Is there any other language that suffers as much from
the "one liner"
syndrome--that is, the perverse pride of being able to do something obscure
with a single unreadable line of code?
LISP maybe?
I'l take that bate :) nested (mapcar (lambda's in a tight recursion ...
Oh what I would give for a goto some times :)
Perl is much worse....
--Chuck
16 Oct
16 Oct
6:58 p.m.
New subject: OT: Language for the ages
"Chuck Guzis" wrote:
Is there any other language that suffers as much from
the "one liner"
syndrome--that is, the perverse pride of being able to do something obscure
with a single unreadable line of code?
LISP maybe?
nah. I would caution the reader not to confuse simplicity or minimalism
with excessive syntactic sugar.
-brad
15 Oct
15 Oct
9:19 p.m.
It was thus said that the Great Vassilis Prevelakis once stated:
Paul Koning <pkoning at equallogic.com> wrote:
In ANSI C, a char is a least 8 bits, a short at least 16 bits and a long
at least 32 bits, with an int not shorter than a short, nor longer than a
long. A pointer is big enough to hold an address to any type.
Yes, there is some fluidity to how big certain quantities are, but that
has never been a problem for me (and I've written code that has successfully
been compiled under 16-bit DOS to 64-bit DEC Alpha running Linux); I've
never understood why so many programmers have such difficulty with the
concept.
-spc (Or to answer your question: big enough)
C is the obvious choice. In either case, you
have to be careful that
you don't wreck the portability by using non-portable I/O.
Er, how big is an int? a pointer? 
17 Oct
17 Oct
1:36 a.m.
Er, how big is
an int? a pointer?
In ANSI C, [...]. A pointer is big enough to hold an address
to any
type.
1:31 a.m.
C is the
obvious choice. In either case, you have to be careful
that you don't wreck the portability by using non-portable I/O.
Er, how big is
an int? a pointer?
6857
days inactive
6861
days old
23 comments
13 participants
participants (13)
-
bfranchuk＠jetnet.ab.ca -
Bob＠BRADLEE.ORG -
brad＠heeltoe.com -
cclist＠sydex.com -
cisin＠xenosoft.com -
gordonjcp＠gjcp.net -
korpela＠ssl.berkeley.edu -
mouse＠Rodents.Montreal.QC.CA -
ploopster＠gmail.com -
spc＠conman.org -
stanb＠dial.pipex.com -
tpeters＠mixcom.com -
vp＠cs.drexel.edu