DMR remarked:
> So far as I can tell from ISO/IEC 9899:1999,
> the panoply of Complex macros and functions
> are supposed to be enabled only after
>
> #include <complex.h>
>
> gcc looks to be overenthusiastic.
>
> Dennis
I would agree. I plan to file a bug report about it. I built and
checked the latest gcc, and even this file generates the
complaint:
#include <stdio.h>
int conj(a)
int a;
{
return a;
}
main()
{
printf("%d\n", conj(1));
}
Sigh.
Arnold
A thing that has puzzled me almost for ever is why the newline
character in C is 012 and not 015. Does anybody have any insight?
Greg
--
Finger grog(a)lemis.com for PGP public key
See complete headers for address and phone numbers
Lehey wondered,
> A thing that has puzzled me almost for ever is why the newline
> character in C is 012 and not 015. Does anybody have any insight?
And Haerr speculated
> Well, my take on this is that C was developed with UNIX,
> of course, and UNIX early on decided to use a single
> character rather than a two-char (CRLF) sequence for
> end-of-lines...
This came via Unix from Multics. My Multics
Programmers' Manual (1969) says, in reference
to its use of the ASCII character set: "Reference:
USA Standard X3.4-1967," and describes the LF
character, with code octal 012, "New Line.
Move carriage to the left edge of the next
line.... ASCII LF is used for this function."
I believe that either this or some other version
of ASCII standard blessed (or condoned) one
of the interpretations of the 012 character
for the new-line function. However, I haven't
turned up hard evidence of this, despite several
conversations with Eric Fischer, who has
kept track of various versions of the standards.
In the event, various of the terminals used early
on did implement the NL function. E.g. the
IBM 1050 and 2741 terminals (decidedly
non-ASCII) had a new-line function, like
a typewriter, no CR, but sometimes an
"Index" character that moved the paper
but not the printing element. The TTY 37
had an optional interpretation of 012 as
NL. Of course, other terminals required
separate CR and LF characters.
The choice of a single character to separate
lines still seems wise if you're using a byte-stream
model.
Dennis
Norman observed (about conj):
> Since the problem is a new library function that appeared in
> the official header files in C99, it makes sense that newer
> versions of gcc object. That means that as time goes by, newer
> C compilers everywhere will probably pick up the change. Any
> documentation stored next to festoon.c should definitely point
> out the problem and its full generality.
> We'll leave aside for now the question of whether complex
> conjugation really ought to be public.
So far as I can tell from ISO/IEC 9899:1999,
the panoply of Complex macros and functions
are supposed to be enabled only after
#include <complex.h>
gcc looks to be overenthusiastic.
Dennis
Since the problem is a new library function that appeared in
the official header files in C99, it makes sense that newer
versions of gcc object. That means that as time goes by, newer
C compilers everywhere will probably pick up the change. Any
documentation stored next to festoon.c should definitely point
out the problem and its full generality.
We'll leave aside for now the question of whether complex
conjugation really ought to be public.
Norman Wilson
Toronto ON
--- tuhs-request(a)minnie.tuhs.org wrote:
> Send TUHS mailing list submissions to
> tuhs(a)minnie.tuhs.org
>
> To subscribe or unsubscribe via the World Wide Web,
> visit
> http://minnie.tuhs.org/mailman/listinfo/tuhs
> or, via email, send a message with subject or body
> 'help' to
> tuhs-request(a)minnie.tuhs.org
>
> You can reach the person managing the list at
> tuhs-admin(a)minnie.tuhs.org
>
> When replying, please edit your Subject line so it
> is more specific
> than "Re: Contents of TUHS digest..."
>
>
> Today's Topics:
>
> 1. Re: compiling festoon (Warren Toomey)
>
> --__--__--
>
> Message: 1
> From: Warren Toomey <wkt(a)minnie.tuhs.org>
> Subject: Re: [TUHS] compiling festoon
> To: Aharon Robbins <arnold(a)skeeve.com>
> Date: Fri, 28 Feb 2003 09:22:49 +1000 (EST)
> CC: tuhs(a)minnie.tuhs.org
> Reply-To: wkt(a)tuhs.org
>
> In article by Aharon Robbins:
> > Hi All.
> >
> > The following diff is necessary to use GCC on a
> linux system.
> > (Anyone know what gcc's builtin `conj' function
> is? Beats me.)
> >
> > Warren, you might want to fix that last line in
> the archive version
> > of the file.
>
> Um, it compiles fine for me on FreeBSD using gcc
> version 2.95.3,
> so I'd say that it's a Linux library. I'll put your
> suggestion
> into the README.
>
> Warren
>
>
It also compiles fine with me. Using RH 7.2 with gcc
2.95.
Regards,
John Chung
> --__--__--
>
> _______________________________________________
> TUHS mailing list
> TUHS(a)minnie.tuhs.org
> http://minnie.tuhs.org/mailman/listinfo/tuhs
>
>
> End of TUHS Digest
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
Hello from Gregg C Levine
In the documentation for E-11, John Wilson, describes the "blinky
lights", essentially eight LEDs attached to the printer port of an
IBM-PC that's running his emulator.
Has anyone ever built one of those things, using either a PC board
blank from John Wilson, or decided to build one on his own? For that
matter, has anyone actually used it, to assist in the debugging of a
program, running on his emulator?
I'll probably e-mail John Wilson about this one directly, but, has
anyone written a custom plug-in, that would have the printer port,
pose as an I/O port for the emulator?
-------------------
Gregg C Levine hansolofalcon(a)worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke." Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )
> From: "Ian King" <iking(a)killthewabbit.org>
> To: "Gregg C Levine" <hansolofalcon(a)worldnet.att.net>, <pups(a)minnie.tuhs.org>
> Subject: Re: [pups] CDROM drives and PDP-11s
> Date: Thu, 27 Feb 2003 08:52:54 -0800
>
> John Wilson's PUTR program might be jut the tool - http://www.dbit.com. I'm
> guessing it might be ODS-2; worst case, I have an InfoServer that can read
> that, and a TK-50 I could dump it to... :-) -- Ian
> ----- Original Message -----
> From: "Gregg C Levine" <hansolofalcon(a)worldnet.att.net>
> To: <pups(a)minnie.tuhs.org>
> Sent: Wednesday, February 26, 2003 11:46 PM
> Subject: [pups] CDROM drives and PDP-11s
>
> Hello from Gregg C Levine
> Here's the problem. I have several CDs containing programs, and such
> like from Tim Shoppa. Two of them say they contain portions which are
> readable only by a CDROM Drive attached to a PDP-11. One of them is
> split in half. Half is readable on either of the two computers here,
> the other half, is in a format that's native to the PDP-11. The other
> is all in that proprietary format. So, has anyone managed to get them
> read to their machines? Or failing that to the appropriate simulators,
> or even emulators? Any suggestions?
When I look at "readme.txt" on my RT11 disk from Tim Shoppa I find the
following paragraph:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The second part of the disk is seven RT-11 partitions. Each is a 65536
block RT-11 device that is accessible on a PDP-11 machine with a SCSI
host adapter and a SCSI CD-ROM drive. They appear as RT-11
DU partitions 13 through 19.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The implication to me is that any of these partitions could be copied
to a 32MB file on a hard drive, and then attached to the PDP11 simulator
of your choice and read as an RT-11 drive.
The tool I would use for copying the partition is dd(1).
dd if=/mnt/cdrom bs=32M skip=13 count=1 of=dskimg
This requires that you have 32MB available RAM for the dd "copy in"
and 32MB available disk space for the dd "copy out". You could
trade off a smaller "bs" for a more complicated calculation of the "skip".
I suppose I am making the assumption that this work is being done on
a Unix-like system, which seems reasonable in the PUPS context.
carl
--
carl lowenstein marine physical lab u.c. san diego
clowenst(a)ucsd.edu
