Pascal --> C question
Ted Johnson
I am contemplating translating a Pascal program to C,
but am not sure if it can be done very easily....
Is there a C equivalent for the Pascal declaration:
SinWave: packed array[0..255] of char;
???
Is the C equivalent simply:
char SinWave[256];
???
Any help/pointers are appreciated!
-Ted
Dave Jones
What do you mean by 'C equivalent'? If you intend to link your translated
program with object modules compiled for Pascal linkage, then you have to know
how the implementers of your C and your Pascal made some arbitrary
choices, among them how to represent arrays of characters. (C implementations,
almost always, conventionally terminate strings with null characters.
Pascal strings have a compile-time-defined fixed length. Sometimes the
implementations prefix the Pascal string with the integer value of the length
of the string.) I would not recommend that such a project be undertaken
by a non-guru. There might also be some problem with reading files of
records generated by a program written in another language, but probably not.
If you only want to translate a stand-alone Pascal program into C, switching
from the Pascal runtime library to the C runtime library (if they are
different on your machine), then you are free to define your own mapping, and
it should be pretty smooth sailing. In that case, the mapping of the
Pascal packed array into the C char-array is perfectly reasonable.
The only tricky problem you may come across is in translating Pascal
procedures which have "nested scope". If you have none of these, congratulate
yourself for having avoided a dubious feature. If you have used such
nestings, I would recommend that you remove them. If you don't want to
do that, you will need to implement a 'display', and resolve references
to vars in the parent's scopes occordingly. Any good book on languages
or compiler construction will have a section on displays.
By the way, do you know about C++? If you are going to undertake a translation
from Pascal, I would suggest that your target be C++ rather than C.
Good luck,
Dave J.
Mike Light
> SinWave: packed array[0..255] of char;
>
> char SinWave[256];
You guessed it!
Almost any pascal-ism has an equivalent in C (but not necessarily
the other way around). Many translators abound, and if you are
looking specifically for one which handles HP Standard Pascal,
the folks at CLL (Compiler Language Lab) can help you out.
-- Mike Light hpda!hpiacla!mlight
Scott Schwartz
>> SinWave: packed array[0..255] of char;
>Almost any pascal-ism has an equivalent in C (but not necessarily
>the other way around).
Except that the useful ones are never that easy. One of my favorites:
bitstring: packed array[0..1023] of boolean;
In C you have to do bit-fiddling by hand to get the same effect.
-- Scott Schwartz | Your array may be without head or
schw...@gondor.cs.psu.edu | tail, yet it will be proof against
| defeat. -- Sun Tzu, "The Art of War"
Frank Swarbrick
:In article <494...@hpiacla.HP.COM> mli...@hpiacla.HP.COM (Mike Light ) writes:
:>> SinWave: packed array[0..255] of char;
:>> char SinWave[256];
:
:>Almost any pascal-ism has an equivalent in C (but not necessarily
:>the other way around).
:
:Except that the useful ones are never that easy. One of my favorites:
: bitstring: packed array[0..1023] of boolean;
:In C you have to do bit-fiddling by hand to get the same effect.
How about:
typedef char bool;
bool bitstring[1024];
Or does the "packed" thing in Pascal have some special meaning? I never could
figure out what the difference between a packed array and a regular array was.
Frank Swarbrick (and his cat)
swar...@tramp.UUCP swar...@tramp.Colorado.EDU
...!{hao|nbires}!boulder!tramp!swarbric
"Can't help about the shape I'm in.
I can't sing, I ain't pretty, and my legs are thin."
Scott Schwartz
>:
>:Except that the useful ones are never that easy. One of my favorites:
>: bitstring: packed array[0..1023] of boolean;
>:In C you have to do bit-fiddling by hand to get the same effect.
>:
>bool bitstring[1024];
>
>Or does the "packed" thing in Pascal have some special meaning? I never could
>figure out what the difference between a packed array and a regular array was.
The "packed" thing has a special meaning. I can't quote you from the
ANSI or ISO standards offhand, but the idea is that the compiler is
supposed to arrange that the packed structure takes up a minimal amount
of space (probably subject to some alignment restrictions). So in the
example I gave each boolean would take up one bit, and there would be
1024 of them, the whole array taking up 128 bytes. Unpacked, each
boolean would take up one, two, or maybe four (depending on how unlucky
you are) bytes.
In (I can't believe I'm about to type this, but...) the hypothetical
"D" language it would be nice to be able to say
typedef bool bit;
bool bitstring[1024];
but, alas....
Andrea Humenick
>Or does the "packed" thing in Pascal have some special meaning? I never could
>figure out what the difference between a packed array and a regular array was.
I'm a new poster, so I'm sorry if this is improper.
In my current pascal class my teacher explained packed and not packed as
this
packed: an array that can read in ' '
not packed: an array that can only be read in character by character
thank you.
Richard A. O'Keefe
> The "packed" thing has a special meaning. I can't quote you from the
> ANSI or ISO standards offhand, but the idea is that the compiler is
> supposed to arrange that the packed structure takes up a minimal amount
> of space (probably subject to some alignment restrictions). So in the
> example I gave each boolean would take up one bit, and there would be
> 1024 of them, the whole array taking up 128 bytes.
The trouble is that a Pascal compiler is absolutely free to ignore
'packed' entirely. When you say
var a: array [0.1023] of boolean;
you have no guarantee at all that the compiler won't use 1024 "words".
To quote the Berkeley Pascal manual page:
"The keyword 'packed' is recognized but has no effect."
You would be lucky to find a Pascal compiler which will pack array
elements down to the bit level. Byte level, yes.
The situation is better in C for two reasons.
(1) At least you can say
char a[1024];
and get nothing worse than byte packing.
(2) You can write the bit-extraction operations as macros, and use them
over and over again on different arrays.
And of course there are those C compilers which have the "inline"
processor, so that you can have
get_bit(array, index)
and put_bit(array, index, value)
turned into your machine's instructions for bit access. (Yay, Sun!)
Scott Schwartz
>In article <33...@psuvax1.psu.edu>, schw...@gondor.cs.psu.edu (Scott Schwartz) writes:
>> So in the
>> example I gave each boolean would take up one bit, and there would be
>> 1024 of them, the whole array taking up 128 bytes.
>The trouble is that a Pascal compiler is absolutely free to ignore
>'packed' entirely. When you say
> var a: array [0.1023] of boolean;
>you have no guarantee at all that the compiler won't use 1024 "words".
Right. Lots of (bad) compilers ignore "packed", just like some C
compilers ignore "register". For the purpose of argument I was
assuming a decent pascal compiler. The University of Sheffield, for
example, sells a pascal compiler for Prime 50 series machines that
implements "packed" down to the bit level. There's nothing like
automatically taking advantage of your instruction set.
Anyway, enough pascal talk. On to the next comp.lang.c topic!
00704a-Liber
> bitstring: packed array[0..1023] of boolean;
>In C you have to do bit-fiddling by hand to get the same effect.
Yes, but in C you are guaranteed that bits are actually used. Not many
implementations of Pascal bother to implement packed arrays any differently
than non-packed arrays, so what you get is an array of 1024 words (where the
sizeof(word) is implementation-dependent).
--
_ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194
' ) ) "The secret compartment of my ring I fill
/ / _ , __o ____ with an Underdog super-energy pill."
/ (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
Frank Swarbrick
why it doesn't exist already. It seems rather silly for boolean values
to take up a whole byte.
But I'm sure there is a good reason for this. (There is, isn't there? :-)
Frank Swarbrick (and his cat)
swar...@tramp.UUCP swar...@tramp.Colorado.EDU
...!{hao|nbires}!boulder!tramp!swarbric
"Welcome back my friends to the show that never ends..."
Rafael Llave
# Except that the useful ones are never that easy. One of my favorites:
# bitstring: packed array[0..1023] of boolean;
# In C you have to do bit-fiddling by hand to get the same effect.
#
Many Pascal compilers ignore packed
TLIMONCE%D...@cunyvm.cuny.edu
>You would be lucky to find a Pascal compiler which will pack array
>elements down to the bit level. Byte level, yes.
Actually, the only version of Pascal that I will use is VaxPascal under
VMS (what's that?) because it has some execelent optimizations. First of
all, it does wonders with PACKED arrays and variables. Unpacked BOOLEANs
take up the same as a INTEGER (4 bytes/1 word) so that you have maximum
speed but PACKED ARRAY [xx..yy] OF BOOLEAN is packed to the bit-level.
VaxPascal will also do optimizations like not recalculating x+1 each time
it's used. (This next one addresses anyother info-c debate) It will even
attempt to make functions and procedures inline if it can determine that
it is not recursive (or any other problems) and if it will save
memory/time.
Best of all, all of the optimizations and run-time checking can be turned
on or off easily. I do super-fast compiles that generate slow, bulky code
until I know it all works. Then I do PASCAL/OPTIMIZE=ALL/CHECK=NONE and
let it take all the time it wants to make my final product.
Why can't popular C compilers do that? (Whoa! Maybe I should ask, "Which
ones do that NOW?" ?)
Actually, from what I read, we are on the brink of seeing more and more
optimizers on the market very soon. All that grad-school work on writing
faster compilers is finally feasible now that we all have our wiz-bang
machines based on 386s and '030s (yeah right! Lemme win the lottery first!)
Tom Limoncelli | Drew U/Box 1060/Madison NJ 07940 | tlim...@drew.BITNET
Disclaimer: These are my views, not my employer or Drew Univesity
--------------------------------------------------------------------------
Rahul Dhesi
>Actually, the only version of Pascal that I will use is VaxPascal under
...
>Why can't popular C compilers do that?
Another interesting optimization done by a VMS compiler, that competing
vendors never thought of doing, is this. If your C program contains
fflush(stdout);
the VMS C compiler will optimize this into:
if (F$MODE == INTERACTIVE) /* if interactive run */
fflush(stdout);
else
printf("\n"); /* if batch run */
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
Eddie Wyatt
> vendors never thought of doing, is this. If your C program contains
>
> fflush(stdout);
>
> the VMS C compiler will optimize this into:
>
> if (F$MODE == INTERACTIVE) /* if interactive run */
> fflush(stdout);
> else
> printf("\n"); /* if batch run */
I hope that the VMS C compiler doesn't do this. fflush doesn't
force a newline. It writes the output buffer.
Also I don't think that the compiler really does this anyway. The
most logically place to optimize the fflush is to either use a macro
definition
#define fflush(hi) ((F$MODE == INTERACTIVE) ? fflush(hi) : 0)
or add the test to fflush.
Thirdly, this optimization is somewhat unsafe. If the program was to
crash immediately after the fflush call, the output that is suppose to
be written will not be. That is unless they have made provision to
fflush output on fatal errors.
--
Eddie Wyatt e-mail: e...@ius1.cs.cmu.edu
Henry Spencer
> vendors never thought of doing, is this. If your C program contains
>
> fflush(stdout);
>
> the VMS C compiler will optimize this into:
>
> if (F$MODE == INTERACTIVE) /* if interactive run */
> fflush(stdout);
> else
> printf("\n"); /* if batch run */
Probably competing vendors never thought of doing it because it's **WRONG**.
Fflush has no business adding newlines, ever, and an fflush need not be
interactive to be legitimate. VMS C is broken.
--
Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology
condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
Dave Jones
I think you may have misunderstood your instructor. "Packed" does indeed
have special significance with regard to arrays of characters. Specificly,
a packed array of characters indexed beginning with 1 is called a "string",
and may be *written* all at one go, rather than a character at a time.
See "Standard Pascal User Reference Manual -- Doug Cooper", W. W.
Norton and Company, Inc. page 52.
You must have missed a whole bunch of recent postings about *reading* strings.
Standard Pascal does not support reading strings all at one go, perhaps
because the founding father couldn't make up his mind about how to handle
end-of-line conditions and short lines. Many Pascal implementations
do support reading strings, but don't count on it being portable.
Dave Jones
Megatest Corp.
880 Fox Lane
San Jose, CA.
95131
(408) 437-9700 Ext 3227
UUCP: ucbvax!sun!megatest!djones
ARPA: megatest!djo...@riacs.ARPA
Dave Jones
I hope the compiler doesn't do this "optimization". It is not correct.
Flushing the stdio buffer should not insert a newline '\n' into the output
stream.
I don't know much about VMS. Is it possible to connect two processes
by means of a pipe fed on the inflow side by stdout? Consider two
processes, so connected, which send messages through the pipe, encoded
as text. In this case, the fflush() is required to assure that a message
is dispatched through the pipe. Is this application's F$MODE == INTERACTIVE?
Here's a bit of code from a production program. By the way,
"pt" stands for Pascal-translator.
/* Send command "a" to the compile-daemon: Compile the
* file named [code_file]
*/
fprintf(pt_input, "a\n%s\n", code_file);
/* dispatch the command */
fflush(pt_input);
/* wait for return code from compilation */
fscanf(pt_output, "%d", &retcode);
mcdo...@uxe.cso.uiuc.edu
>
> Another interesting optimization done by a VMS compiler, that competing
> vendors never thought of doing, is this. If your C program contains
>
> fflush(stdout);
>
> the VMS C compiler will optimize this into:
>
> if (F$MODE == INTERACTIVE) /* if interactive run */
> fflush(stdout);
> else
> printf("\n"); /* if batch run */
> --
> Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
>I hope the compiler doesn't do this "optimization". It is not correct.
>Flushing the stdio buffer should not insert a newline '\n' into the output
>stream.
>I don't know much about VMS. Is it possible to connect two processes
>by means of a pipe fed on the inflow side by stdout? Consider two
>processes, so connected, which send messages through the pipe, encoded
>as text. In this case, the fflush() is required to assure that a message
>is dispatched through the pipe. Is this application's F$MODE == INTERACTIVE?
Perhaps you should understand VMS before making such comments. You see,
VMS is not a flavor of UNIX. It is an entirely different operating system.
Its file system is entirely unlike Unix's. There are many different TYPES
of files. For certain kinds of files, outputting a \n in C will flush the
buffers, AND is REQUIRED at the end of a file. Ordinary text files absolutely
must end in a way that is indicated in C by /n. No particular character
is actually placed in a file to represent this; it is indicated by the
record structure. However, what is funny is that, by default, stdout
is NOT a standard text file in the version of VMS C that we use. I seriously
doubt that such behaviour is a bug though, as I've found that VMS C works
quite well (except that stdout is not an ordinary text file.)
Any genuine VMS gurus want to give the full explanation?
Doug McDonald
Henry Spencer
> interactive to be legitimate. VMS C is broken.
Some folks who are more intimate with VMS C than I am have supplied an
update to this: Rahul is simply wrong, VMS C does not do this. Apparently
there are some oddities in file handling that might deceive the unwary into
thinking that something like this was happening, but it's not.
Doug Gwyn
-Another interesting optimization done by a VMS compiler, that competing
-vendors never thought of doing, is this. If your C program contains
- fflush(stdout);
-the VMS C compiler will optimize this into:
- if (F$MODE == INTERACTIVE) /* if interactive run */
- fflush(stdout);
- else
- printf("\n"); /* if batch run */
Is this true? It's no wonder competing vendors didn't think of
doing it, because it's wrong.
Doug Gwyn
>Perhaps you should understand VMS before making such comments. ...
Assuming VMS C really does what the fellow said (which I doubt),
it's a bug regardless of VMS's ideas about record-oriented files.
fputs( "This is a ", stdout );
fflush( stdout );
fputs( "test of the VMS file system.\n", stdout );
fflush( stdout );
should produce precisely one text record, not two or three.
Rahul Dhesi
writes:
>Assuming VMS C really does what the fellow said (which I doubt),
>it's a bug regardless of VMS's ideas about record-oriented files.
For the edification of all compiler writers, a log of a batch run under
VAX/VMS follows.
$! Batch run of "feature.c"
$ set default [.scr]
$ type feature.c
/* A "Hello world" program in three movements */
#include <stdio.h>
main()
{
printf("He"); fflush(stdout); printf("llo"); fflush(stdout);
printf(" wor"); fflush(stdout); printf("ld"); fflush(stdout);
printf("\n");
}
$ cc feature.c
$ link feature
$ run feature
He
llo
wor
ld
$ exit
00R0DHESI job terminated at 20-MAR-1988 11:07:48.01
Accounting information:
Buffered I/O count: 123 Peak working set size: 1732
Direct I/O count: 214 Peak page file size: 2163
Page faults: 3506 Mounted volumes: 0
Charged CPU time: 0 00:00:21.68 Elapsed time: 0 00:01:12.68
mcdo...@uxe.cso.uiuc.edu
Rahul Desi wrote the following C program:
/* A "Hello world" program in three movements */
#include <stdio.h>
main()
{
printf("He"); fflush(stdout); printf("llo"); fflush(stdout);
printf(" wor"); fflush(stdout); printf("ld"); fflush(stdout);
printf("\n");
}
and ran it in batch mode on VMS.
He got as output:
He
llo
wor
ld
I ran it interactively, and it output "Hello world" [sic] (He forgot
the canonical ! ;-) (hey! that's a great typo! a wink!) )
I ran it after doing a $define sys$output hello.out .
and when I type the hello.out file I get
He
llo
wor
ld
The file "hello.out" is a standard VMS text file. I think that the four-
line file the program creates is correct. Remember that Dhesi didn't
put a
printf("Hello world\n");
statement in his file. He wrote it so that it was split into four
records by the flushes. He got the four records. Because standard
VMS text files always have records which logically end in
carriage-return line-feed pairs, it prints the way it does. This seems
to be correct behaviour: a flush terminates a record. If he wanted
to output to a file where a flush did not terminate a record, but
rather a line-feed alone did, he should open the file as "byte-stream
terminated by line-feed". This is how VMS C by default opens text files.
But he didn't open the file himself, he used stdout, which VMS opens
in a predefined way, which appears to differ if it is going to the screen
or a disk file. All this goes to prove is that VMS is not Unix.
The VMS C compiler isn't broken.
Doug McDonald
Rich Salz
a VMS program where the line
printf("He"); fflush(stdout); printf("llo"); fflush(stdout);
He
llo
There is no need for alarm; Rahul is apparently using a machine with
an outdated C library. Version 2.3 does the right thing.
/r$
--
Please send comp.sources.unix-related mail to rs...@uunet.uu.net.
Doug Gwyn
Show me where any accepted standard for C says that fflush()
introduces a record delimiter.
Dave Jones
>
> For the edification of all compiler writers, a log of a batch run under
> VAX/VMS follows.
>
> {
> printf("He"); fflush(stdout); printf("llo"); fflush(stdout);
> printf(" wor"); fflush(stdout); printf("ld"); fflush(stdout);
> printf("\n");
> }
>
> llo
> wor
> ld
>
Th
is
is
pre
tty
rid
icu
lous.
Dave Jones
880 Fox Lane
San Jose, CA.
95131
(408) 437-9700 Ext 3227
UUCP: ucbvax!sun!megatest!djones
ARPA: megatest!djo...@riacs.EDU
mcdo...@uxe.cso.uiuc.edu
Nowhere. As far as I can recall, I have never seen the concept of a record
discussed in any C reference. The IO system of C seems oblivious to records.
Thus, as a corollary, if by some chance a C standard io stream gets
connected to a file that isn't stream, the results would be "system dependent",
which implies that the implementer CAN'T BE WRONG! If VMS C connects to
stream-LF files, then, and only then, would a flush be broken.
Doug Gwyn: Are you here? Is that correct? What does ANSI C say about
record-oriented files?
Doug McDonald
Dave Jones
> Nf-ID: #R:goofy.megatest.UUCP:302:uxe.cso.uiuc.edu:225800016:000:1556
> Nf-From: uxe.cso.uiuc.edu!mcdonald Mar 21 07:58:00 1988
>
[ Stuff about "flush" meaning different things in Unix and VMS:
In VMS "flush" means "end-of-record", and "end-of-record" means '\n'. ]
>
> The VMS C compiler isn't broken.
>
Oops! You better tell them quickly, because a previous posting says that
it has been fixed in the next release!
I still don't know anything about VMS, but I can hardly take your advice
about not talking about it until I do. Hell, if everybody had that
attitude, hardly anything would get said, ever! It is true that "a
little knowledge is a dangerous thing," as is evidenced by the
majority of the postings to this group. But I think that ignorance,
when freely admitted, is quiet benign.
So I offer these comments to be considered in view of may complete lack
of competence in VMSisms: There is some little problem with mapping the
semantics of stdio byte-streams (as defined by the Unix implementation)
to the VMS record oriented files. But making flush() synonymous with
end-of-record, and inserting gratuitous newlines ain't part of the answer.
IBM -- or was it Whitesmith's -- had exactly the same problem porting
the stdio library to VM/CMS, MVS, and MVS/XA. They did a pretty good
job of it. See "C Language Manual", IBM publication SC09-1128-0, Chapter 9.
They defined an (almost) reversible mapping from the record oriented files onto
the (virtual) byte-streams of stdio. It's not perfect. For example,
it is sometimes necessary to pad lines with blanks as they go into
record oriented files, and then remove trailing blanks as the record
oriented files are read as text-streams. So trailing blanks which really
were in the stdio stream get discarded. Oh well...
The description of fflush() on page 11-83 says, "fflush drains any unwritten
data in the output buffer for the stream controlled by the FILE..."
Dave Jones
Megatest Corp.
880 Fox Lane
San Jose, CA.
95131
(408) 437-9700 Ext 3227
UUCP: ucbvax!sun!megatest!djones
ARPA: megatest!djo...@riacs.EDU
"If it's really broken, go ahead and fix it."
Doug Gwyn
>Thus, as a corollary, if by some chance a C standard io stream gets
>connected to a file that isn't stream, the results would be "system dependent",
>which implies that the implementer CAN'T BE WRONG! If VMS C connects to
>stream-LF files, then, and only then, would a flush be broken.
My understanding of the requirements in the draft proposed ANSI C
standard is that a conforming implementation is obliged to provide
(correctly!) at least one file format each for text streams and
for binary streams. Although it may support more formats, it need
not do so. However, vendors are well advised to attempt to do the
best job they can with each file format their system supports,
because it is not nice to tell the customer that C programs can
manipulate some kinds of files but not others.
Thus, technically, so long as VMS C had the right behavior on one
text stream format (stream-LF for example), the fact that it did
not handle other formats sanely would not make it nonconforming
in the strictest sense, merely broken. I'm not sure if the fact
that it attempted to manipulate another format without reporting
an error couldn't be considered nonconforming, though -- I think
a case could be made that if a format is unsupported it shouldn't
pretend to work at all (i.e. fopen(), printf(), etc. should fail
on such a stream).
John Gilmore
between binary and text files and had a few realizations:
* Stdin, stdout, and stderr are assumed to be *text* files.
A program that does binary I/O on them is not portable. So, how does
one fix this?
* There seems to be *no way* to "reopen" these streams as
binary. E.g. how do I write a binary file to the current standard
output? Freopen will redirect stdout to a different named file, but I
just want binary treatment for the existing output file (e.g. the one
specified by the user when they ran "a.out >foo").
PS: In the process I found that, since stdout is a *text* file,
fflush() should not write record boundaries on it. Standard I/O is
allowed to screw around with text files (too much, in my opinion - see
section 4.9.2), but it's not allowed to insert newlines at random
places. Though it is not at all clear what is allowed to happen if you
exceed the system's line length limit, which there seems to be no way
to determine, except that it can't be less than 254.
--
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu g...@toad.com
"Watch me change my world..." -- Liquid Theatre
Chris Torek
> * There seems to be *no way* to "reopen" [stdin and stdout] as
>binary.
I believe this is the case. I thought at one point that
freopen((char *)NULL, "rb", stdin);
was supposed to do that sort of thing, but apparently that was just
a proposal; it never made it into any draft. (This seems to me a
not unreasonable way to do it. Systems that do not have modes need
only say
if (name == NULL && stream_is_open(stream))
return (stream);
while those that do can do whatever is required at system startup
and file open time to figure out what modes are permissible and to
retain whatever state is needed to set them.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: ch...@mimsy.umd.edu Path: uunet!mimsy!chris
Doug Gwyn
That's right; on POSIX-conforming systems it makes no difference
but on oddball OSes it could. However, on such OSes it seems
unlikely that processes would be nicely piped together anyway,
or that it would make sense for the application to tell the
system what type of file it was dealing with when the system had
actually set it up for the process.
There was a proposal for freopen((char*)0,mode,stream) to effect
a change of mode on an open stream, but several implementors
thought that switching modes in midstream could be difficult to
support on some systems.
Arthur David Olson
>
> a change of mode on an open stream, but several implementors
> thought that switching modes in midstream could be difficult to
> support on some systems.
Couldn't freopen simply return ((FILE *) 0) in such cases, much as
localtime is allowed to return -1 if local time can't be determined?
--
ol...@ncifcrf.gov "...that lucky ol' Sun ain't got nothin' to do..."
Dave Jones
>
> I was just reading over the standard trying to figure out the differences
> between binary and text files and had a few realizations:
>
> * Stdin, stdout, and stderr are assumed to be *text* files.
> A program that does binary I/O on them is not portable. So, how does
> one fix this?
>
> ...
On a Unix system, one writes a buffering package for raw bytes,
something akin to stdio, using write(). Since you don't need
printf and scanf, it's no big deal. Unfortunately, I have seen
one implementation of C (IBM System 370) which
does not have write(). Or if they do, they don't document it.
Doug Gwyn
>Couldn't freopen simply return ((FILE *) 0) in such cases, much as
>localtime is allowed to return -1 if local time can't be determined?
Sure; but then what good does it to to specify the facility if
portable code couldn't rely on it working?
Arthur David Olson
> > localtime is allowed to return -1 if local time can't be determined?
>
> Sure; but then what good does it to to specify the facility if
> portable code couldn't rely on it working?
Same as with localtime: it provides a standardized way for accessing the
capability *when it is available.*
Karl Heuer
>> There was a proposal for freopen((char*)0,mode,stream) to effect
>> a change of mode on an open stream, but several implementors
>> thought that switching modes in midstream could be difficult to
>> support on some systems.
>
>Couldn't freopen simply return ((FILE *) 0) in such cases, much as
>localtime is allowed to return -1 if local time can't be determined?
That's time(), not localtime().
Let's consider three classes of machines. Those on which text and binary
streams are identical (POSIX); those on which such a mode-change is impossible
(probably because the mode is set in concrete when the file is first opened);
and those on which it is neither trivial nor impossible.
The proposed functionality is only useful on the third class. Are there any
such implementations? (Where do MSDOS and VMS fall?)
Karl W. Z. Heuer (ima!haddock!karl or ka...@haddock.isc.com), The Walking Lint
Rahul Dhesi
[re mode change]
>(Where do MSDOS and VMS fall?)
Since MS-DOS was designed by obtaining a weighted harmonic mean of CP/M
and UNIX, it behaves as follows.
In UNIX tradition, the operating system itself does not distinguish
between text and binary files. In the tradition of CP/M, however, each
line in a text file is terminated by a CR LF sequence, but this
convention is enforced by programs that use text files (including
utilities supplied with MS-DOS) and not by the file system.
When a C program reads a text file, the runtime library routines strip
out any CR characters, thus reading the same sequence of characters
that would be read on a UNIX system. When writing a text file, a CR
character is added before each LF is written. (Note: The correct way
to perform the newline conversion would be to use a state machine.
Then isolated CR characters, which occur in files that include
overprinting controls for line printers, would not be stripped out. It
is not clear if any runtime library actually goes to this trouble;
seeks would disturb any state information maintained anyway.)
Thus the mode of a file (whether text or binary) exists only as a mode
bit in the runtime library of a C program. The file mode is therefore
relevant only to a C program and not, for example, to an assembly
language program or a BASIC program. Common C libraries supply
a macro or a function that will change between text and binary
modes for open files.
Oh, by the way, many programs that were originally written for CP/M and
ported for MS-DOS use a control Z character in text files to mark
end-of-file. MS-DOS utilities will recognize the control Z and do
weird things with it, but they do not themselves write a control Z to
mark end of file, since MS-DOS, like UNIX, takes the simple (yet
unusual) point of view that a file ends wherever it ends. The MS-DOS
console driver, if operating in cooked mode, freaks out when a control
Z is written to the console, and refuses to write any more until the
EOF condition is cleared. (Can you imagine, a console driver with an
EOF condition occurring during *output* to a video terminal?) This is
a bug, though it was probably originally meant to be a feature that
would prevent trailing garbage from appearing on the screen when an old
format text file was typed.
VMS C does not normally need any mode change for open files.
The default type of a file opened from a C program is stream-LF, which
uses records terminated by linefeeds, and does not distinguish between
text and binary formats at all, acting like UNIX and POSIX files.
Unfortunately, when a C program is executed, stdout is by default not a
stream-LF file, and it's not clear that this can be changed by the
user. Since I/O redirection under VMS is rather painful, it will
seldom be the case that a program will want to do a seek on its
standard output anyway. Even when the standard output of a C program
is redirected to a file, that file is opened for output in some weird
mode which is not stream-LF. (I consider this a bug.) The type of
this file cannot be changed while it is open. This is why problems
occur, and presumably why running my "Hello world" program under batch
caused strange behavior.
John Gilmore
> In article <80...@elsie.UUCP> a...@elsie.UUCP (Arthur David Olson) writes:
> >> > There seems to be *no way* to "reopen" these streams as binary.
> >> There was a proposal for freopen((char*)0,mode,stream) to effect
> >> a change of mode on an open stream, but several implementors
> >> thought that switching modes in midstream could be difficult to
> >> support on some systems.
> streams are identical (POSIX); those on which such a mode-change is impossible
> (probably because the mode is set in concrete when the file is first opened);
> and those on which it is neither trivial nor impossible.
> The proposed functionality is only useful on the third class. Are there any
> such implementations? (Where do MSDOS and VMS fall?)
Let me give you a specific example to chew on. I have written a bunch
of programs for manipulation of image files in the Sun rasterfile format.
The particular format is not important to know except that it is binary.
Now, these programs are set up to accept a rasterfile on stdin,
manipulate it, and produce a new one on stdout, so you can do things
like:
<image scale .5 .5 | clip 0 40 300 300 | bwdither | lpr -v
This really works on Unix, and it would be pretty easy to make these
work on any system that could support binary files as stdin/stdout,
(and had a shell that would make pipes, like MSDOS or Unix), but not if
the standard doesn't tell me and those implementers a good way for me
to say "please sir, don't translate CR to LF on stdin for me, just let
me at the bytes"...
[As mentioned, MSDOS has this capability; as on Unix, "text" versus
"binary" is all in the application's head (the problems arise because
the default text format is not the one assumed by C programs from Unix).
Atari's TOS is the same way. I'm not sure about AmigaDOS or the MacOS.
VMS has already been explained to be *unable* do handle this, but I
don't care if my stuff runs on VMS anyway.]
So I'm not asking for a *requirement* that all systems be able to handle
binary I/O on stdin/out/err, just a method for requesting it where possible,
to encourage portability to systems that are capable of it.
--
{pyramid,pacbell,amdahl,sun,ihnp4}!hoptoad!gnu g...@toad.com
"Don't fuck with the name space!" -- Hugh Daniel
Dave Sill
Around here they generally fall in the trash.
Karl Heuer
>[In VMS] the default type of a file opened from a C program is stream-LF,
>which uses records terminated by linefeeds, and does not distinguish between
>text and binary formats at all, acting like UNIX and POSIX files.
The fact that it's called "stream-LF" (as distinct from "stream-CR" or just
"stream") suggests that the newlines which terminate the records have some
significance to the OS. Is it legal, for example, to write 70000 characters
without a newline? If not, this doesn't seem like an acceptable format for
binary mode.
Richard A. O'Keefe
> ka...@haddock.ISC.COM (Karl Heuer) wrote:
> > In article <80...@elsie.UUCP> a...@elsie.UUCP (Arthur David Olson) writes:
> > >> > There seems to be *no way* to "reopen" these streams as binary.
> This really works on Unix, and it would be pretty easy to make these
> work on any system that could support binary files as stdin/stdout,
> (and had a shell that would make pipes, like MSDOS or Unix), but not if
> the standard doesn't tell me and those implementers a good way for me
> to say "please sir, don't translate CR to LF on stdin for me, just let
> me at the bytes"...
If UNIX needed this facility, and if it used "b" to indicate binary mode,
FILE *binin = fdopen(fileno(stdin), "rb");
FILE *binout= fdopen(fileno(stdout),"wb");
/* use bin_in, bin_out instead of stdin, stdout */
would do the job. Would this work in MSDOS?
Instead of having a way of switching the mode, why not ask for two more
"standard" streams: binin and binout, where systems which don't need a
distinction between text and binary would identify them with stdin and
stdout, systems where switching is possible would switch as necessary,
and systems where only one method of connexion was allowed would have
all I/O on the "wrong" connexions return EOF, and systems where either
method was allowed but not both would pick it up from the first use.
Rahul Dhesi
>The fact that it's called "stream-LF" (as distinct from "stream-CR" or just
>"stream") suggests that the newlines which terminate the records have some
>significance to the OS. Is it legal, for example, to write 70000 characters
>without a newline? If not, this doesn't seem like an acceptable format for
>binary mode.
Yes, a VMS C program can write any number of characters before writing
a newline, and it works, and it can all be read back. VMS does handle
records of arbitrary length in stream-LF files, SO LONG AS ALL ACCESS
IS THROUGH THE VMS C LIBRARY. Things break down, however, when such a
file is manipulated in any other manner, as is shown by the following
program.
-----cut here-----
#include <stdio.h>
/* testing VMS stream-LF format */
#define HOWMUCH 2000 /* how much to write as a single record */
#define FNAME "junk.dat" /* what to call the file */
main()
{
FILE *f; int i; int c;
f = fopen (FNAME, "w");
if (f == NULL)
perror("write");
for (i = 0; i < HOWMUCH; i++)
fputc ('x', f);
fputc ('\n', f); /* terminates stream-LF record *whew* */
fclose (f);
/* now read file and dump to screen */
f = fopen (FNAME, "r");
if (f == NULL)
perror ("read");
for (i = 0; i < HOWMUCH + 1; i++) {
c = fgetc (f);
fputc (c, stdout);
}
}
-----cut here-----
This program writes a 2000-character record to junk.dat, then reads
junk.dat and sends it to the screen. I ran it both interactively and
under batch.
(a) Interactively: What is printed on the screen by the program is
what I expected: 2000 'x' characters. But when I gave the VMS command
"type junk.dat" I got a QIO error, presumably because the VMS "type"
command can't handle 2000-character records.
(b) Under batch: The output from the program as shown in the batch log
was not 2000 'x' characters followed by a newline. Instead, I saw
lines of 512 'x' characters. Clearly, a newline was being forced after
512 characters at most. When the batch file did "type junk.dat", a QIO
error occurred again.
Larry Jones
> In article <25...@bsu-cs.UUCP> dh...@bsu-cs.UUCP (Rahul Dhesi) writes:
> >[In VMS] the default type of a file opened from a C program is stream-LF,
> >which uses records terminated by linefeeds, and does not distinguish between
> >text and binary formats at all, acting like UNIX and POSIX files.
>
> The fact that it's called "stream-LF" (as distinct from "stream-CR" or just
> "stream") suggests that the newlines which terminate the records have some
> significance to the OS. Is it legal, for example, to write 70000 characters
> without a newline? If not, this doesn't seem like an acceptable format for
> binary mode.
Yes, you can write as many characters as you want without a newline - you
don't even need one at the end of the file. The only significance of the
"stream-LF" designation is to allow the file system to simulate a record
structured file meaningfully. Since most VMS programs are only capable of
handling record structure files (stream file being relatively new), this
is of immeasurable value.
----
Larry Jones UUCP: uunet!sdrc!scjones
SDRC MAIL: 2000 Eastman Dr., Milford, OH 45150
AT&T: (513) 576-2070
"When all else fails, read the directions."
M. Warner Losh
+>[In VMS] the default type of a file opened from a C program is stream-LF,
+>which uses records terminated by linefeeds, and does not distinguish between
+>text and binary formats at all, acting like UNIX and POSIX files.
+The fact that it's called "stream-LF" (as distinct from "stream-CR" or just
+"stream") suggests that the newlines which terminate the records have some
+significance to the OS. Is it legal, for example, to write 70000 characters
+without a newline? If not, this doesn't seem like an acceptable format for
+binary mode.
In VMS it is legal (VMS 4.4 C 2.2). There are a few system utilities that will
gronk and die when you try to use this format. I think that this is a small
problem with i/o quotas not being set up correctly, but never did look into
it more deeply. I got around the problem by not having to use that particular
system utility :-)
+Karl W. Z. Heuer (ima!haddock!karl or ka...@haddock.isc.com), The Walking Lint
--
bitnet: lo...@nmt.csnet M. Warner Losh
war...@hydrovax.nmt.csnet ! Don't know if this works, let me know.
csnet: war...@hydrovax.nmt.edu
uucp: ...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!warner%hydrovax
Barnacle Wes
| >[In VMS] the default type of a file opened from a C program is stream-LF,
| >which uses records terminated by linefeeds, and does not distinguish between
| >text and binary formats at all, acting like UNIX and POSIX files.
|
| The fact that it's called "stream-LF" (as distinct from "stream-CR" or just
| "stream") suggests that the newlines which terminate the records have some
| significance to the OS. Is it legal, for example, to write 70000 characters
| without a newline? If not, this doesn't seem like an acceptable format for
| binary mode.
VMS "stream" files have a block size of 1 char, so you can write out
whatever you want (as long as you don't overflow the device).
--
/\ - "Against Stupidity, - {backbones}!
/\/\ . /\ - The Gods Themselves - utah-cs!utah-gr!
/ \/ \/\/ \ - Contend in Vain." - uplherc!sp7040!
/ U i n T e c h \ - Schiller - obie!wes
Brian Campbell
! between binary and text files and had a few realizations:
!
! * Stdin, stdout, and stderr are assumed to be *text* files.
! A program that does binary I/O on them is not portable. So, how does
! one fix this?
Is this a portable concept?
! * There seems to be *no way* to "reopen" these streams as
! binary. E.g. how do I write a binary file to the current standard
! output? Freopen will redirect stdout to a different named file, but I
! just want binary treatment for the existing output file (e.g. the one
! specified by the user when they ran "a.out >foo").
As Doug Gwyn pointed out, this makes no difference on POSIX-conforming
systems. Under DOS, however, both the Borland and Microsoft C libraries
include a setmode(int fd, unsigned mode) function. The mode parameter is
pretty much the same as that of creat() with the addition of two other
masks: O_BINARY and O_TEXT.
--
Brian Campbell uucp: decvax!utzoo!dciem!nrcaer!cognos!brianc
Cognos Incorporated mail: POB 9707, 3755 Riverside Drive, Ottawa, K1G 3Z4
(613) 738-1440 fido: (613) 731-2945 300/1200, sysop@1:163/8
Arthur David Olson
> FILE *binin = fdopen(fileno(stdin), "rb");
> FILE *binout= fdopen(fileno(stdout),"wb");
> /* use bin_in, bin_out instead of stdin, stdout */
> would do the job. Would this work in MSDOS?
Whether or not it works in MSDOS, it wouldn't work in draft proposed ANSI C
(which lacks an "fdopen" function).
--
a...@ncifcrf.gov ADO is a trademark of Ampex.
Daniel R. Levy
# > If UNIX needed this facility, and if it used "b" to indicate binary mode,
# > FILE *binin = fdopen(fileno(stdin), "rb");
# > FILE *binout= fdopen(fileno(stdout),"wb");
# > /* use bin_in, bin_out instead of stdin, stdout */
# > would do the job. Would this work in MSDOS?
#
# Whether or not it works in MSDOS, it wouldn't work in draft proposed ANSI C
# (which lacks an "fdopen" function).
Oh, GROAN. Why not? Sometims that's the most efficient way of getting a
stdio stream open onto a file which needs options on open() or creat() other
than the default, e.g. with permissions other than 0666&umask, or with a
special open parameter like System V's O_SYNC.
--
|------------Dan Levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
| an Engihacker @ | <most AT&T machines>}!ttrdc!ttrda!levy
| AT&T Data Systems Group | Disclaimer? Huh? What disclaimer???
|--------Skokie, Illinois--------|
Doug Gwyn
>Oh, GROAN. Why not? Sometims that's the most efficient way of getting a
>stdio stream open onto a file which needs options on open() or creat() other
There is no fdopen() in ANSI C because there are no UNIX file
descriptors in ANSI C.
UNIX (POSIX) systems can provide fdopen() as an extension to an ANSI-
conforming C implementation. Nobody is insisting that it go away,
except it must not appear in <stdio.h> in a pure ANSI C environment
(special implementation-dependent things may be done to enable its
appearance; this issue is still being discussed by the standards
committees).
Richard A. O'Keefe
> > If UNIX needed this facility, and if it used "b" to indicate binary mode,
> > FILE *binin = fdopen(fileno(stdin), "rb");
> > FILE *binout= fdopen(fileno(stdout),"wb");
> > /* use bin_in, bin_out instead of stdin, stdout */
> > would do the job. Would this work in MSDOS?
>
> Whether or not it works in MSDOS, it wouldn't work in draft proposed ANSI C
> (which lacks an "fdopen" function).
That's hardly news: the point of the discussion was precisely that the
ability to do binary I/O on stdin/stdout was something that some people
needed and didn't appear to be available in dpANS. The point of my message
was to suggest that instead of switching a stdio stream between several modes
it might suffice to be able to attach new streams to existing ports.
Rahul Dhesi
writes:
>...the point of the discussion was precisely that the
>ability to do binary I/O on stdin/stdout was something that some people
>needed and didn't appear to be available in dpANS.
ANSI can't change this for you. ANSI is obliged to humor existing broken
software environments.
But you aren't! Let your buying dollar make a statement.
Doug Gwyn
>ANSI can't change this for you. ANSI is obliged to humor existing broken
>software environments.
X3J11 decides what to do about variations among operating systems on
a case-by-case basis. We could require some way to obtain binary
streams for stdin/stdout if we thought it sufficiently useful AND if
we could figure out a viable method for doing so.
P.S. My personal opinion, not an X3J11 official statement.
Bob Amen
> In article <26...@bsu-cs.UUCP> dh...@bsu-cs.UUCP (Rahul Dhesi) writes:
>>ANSI can't change this for you. ANSI is obliged to humor existing broken
>>software environments.
>
> streams for stdin/stdout if we thought it sufficiently useful AND if
> we could figure out a viable method for doing so.
>
> P.S. My personal opinion, not an X3J11 official statement.
Perhaps I'm a bit confused here but it's always been my impression
that UNIX was designed to make no distinction between binary and ASCII
(say) data. For those of us using UNIX systems to do science, the ability
to read binary data (transparently) is a necessity. Without that we lose
most of what I find UNIX great for...like being able to write small useful
programs that operate on data and fit them together with pipes and tees.
(There are other useful things as well.) Why is this a problem now? I've
been following this discussion but have not yet heard a compelling reason
to break one of the greatest advantages of UNIX.
--
Bob Amen (am...@quequeg.UUCP) (+1 301 338-6329)
Chesapeake Bay Institute/The Johns Hopkins University
Henry Spencer
> that UNIX was designed to make no distinction between binary and ASCII
The key point here is that X3J11 is standardizing C, not Unix. X3J11 must
define a standard that is implementable on non-Unix systems, some of which
insist that text and binary i/o are very different animals.
--
"Noalias must go. This is | Henry Spencer @ U of Toronto Zoology
non-negotiable." --DMR | {ihnp4,decvax,uunet!mnetor}!utzoo!henry
Doug Gwyn
> Perhaps I'm a bit confused here but it's always been my impression
>that UNIX was designed to make no distinction between binary and ASCII
>Why is this a problem now? I've
>been following this discussion but have not yet heard a compelling reason
>to break one of the greatest advantages of UNIX.
You misunderstand. UNIX need not (and undoubtedly will not) change in
this respect. The discussion was about what should be specified in the
forthcoming ANSI C standard, which applies across ALL operating systems,
including some that would have great difficulty supporting a UNIX-like
notion of file. Such systems often need to treat text files and binary
files in different ways. The "b" specifier appended to an fopen() mode
requests that the stream be handled as binary; stdin/stdout/stderr are
required to be initially open as text streams. On UNIX it makes no
difference, but on some systems this can pose a problem.
We were careful to permit text and binary streams to be indistinguishable
on systems where that was appropriate; the forthcoming IEEE Std 1003.1
(POSIX) requires this behavior, which is compatible with proposed ANSI C.