tedj@hpcilzb.HP.COM (Ted Johnson) (03/03/88)
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
djones@megatest.UUCP (Dave Jones) (03/07/88)
in article <650001@hpcilzb.HP.COM>, tedj@hpcilzb.HP.COM (Ted Johnson) says: > > > > > > > > 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 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.
mlight@hpiacla.HP.COM (Mike Light ) (03/09/88)
> Is there a C equivalent for the Pascal declaration: > SinWave: packed array[0..255] of char; > > Is the C equivalent simply: > 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
schwartz@gondor.cs.psu.edu (Scott Schwartz) (03/11/88)
In article <4940001@hpiacla.HP.COM> mlight@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. -- Scott Schwartz | Your array may be without head or schwartz@gondor.cs.psu.edu | tail, yet it will be proof against | defeat. -- Sun Tzu, "The Art of War"
swarbric@tramp.Colorado.EDU (Frank Swarbrick) (03/11/88)
In article <3352@psuvax1.psu.edu> schwartz@gondor.cs.psu.edu (Scott Schwartz) writes: :In article <4940001@hpiacla.HP.COM> mlight@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) swarbric@tramp.UUCP swarbric@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."
schwartz@gondor.cs.psu.edu (Scott Schwartz) (03/11/88)
swarbric@tramp.Colorado.EDU (Frank Swarbrick) writes: >: >: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. >: >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. 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.... -- Scott Schwartz | Your array may be without head or schwartz@gondor.cs.psu.edu | tail, yet it will be proof against | defeat. -- Sun Tzu, "The Art of War"
cs2531ar@charon.unm.edu (Andrea Humenick) (03/11/88)
In article <4766@sigi.Colorado.EDU> swarbric@tramp.Colorado.EDU (Frank Swarbrick) writes: >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.
ok@quintus.UUCP (Richard A. O'Keefe) (03/11/88)
In article <3353@psuvax1.psu.edu>, schwartz@gondor.cs.psu.edu (Scott Schwartz) writes: > 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!)
schwartz@gondor.cs.psu.edu (Scott Schwartz) (03/12/88)
In article <760@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >In article <3353@psuvax1.psu.edu>, schwartz@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! -- Scott Schwartz | Your array may be without head or schwartz@gondor.cs.psu.edu | tail, yet it will be proof against | defeat. -- Sun Tzu, "The Art of War"
nevin1@ihlpf.ATT.COM (00704a-Liber) (03/12/88)
In article <3352@psuvax1.psu.edu> schwartz@gondor.cs.psu.edu (Scott Schwartz) writes: >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. 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
swarbric@tramp.Colorado.EDU (Frank Swarbrick) (03/12/88)
Hey, I've got no problem with having a 'bit' data type! I've been wondering
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)
swarbric@tramp.UUCP swarbric@tramp.Colorado.EDU
...!{hao|nbires}!boulder!tramp!swarbric
"Welcome back my friends to the show that never ends..."llave@phoenix.Princeton.EDU (Rafael Llave) (03/13/88)
# # 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%DREW.BITNET@CUNYVM.CUNY.EDU (03/13/88)
On 12-MAR-1988 09:06 ok@quintus.uucp wrote: >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 | tlimonce@drew.BITNET Disclaimer: These are my views, not my employer or Drew Univesity --------------------------------------------------------------------------
dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/13/88)
In article <12340@brl-adm.ARPA> TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU writes: >Actually, the only version of Pascal that I will use is VaxPascal under >VMS (what's that?) because it has some [excellent] optimizations.... ... >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
edw@IUS1.CS.CMU.EDU (Eddie Wyatt) (03/15/88)
> 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 */ 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: edw@ius1.cs.cmu.edu
henry@utzoo.uucp (Henry Spencer) (03/15/88)
> 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 */ 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
djones@megatest.UUCP (Dave Jones) (03/16/88)
in article <2500@charon.unm.edu>, cs2531ar@charon.unm.edu (Andrea Humenick) says: > > In article <4766@sigi.Colorado.EDU> swarbric@tramp.Colorado.EDU (Frank Swarbrick) writes: >>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. 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!djones@riacs.ARPA
djones@megatest.UUCP (Dave Jones) (03/16/88)
in article <2351@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) says: > > In article <12340@brl-adm.ARPA> TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU writes: >>Actually, the only version of Pascal that I will use is VaxPascal under >>VMS (what's that?) because it has some [excellent] optimizations.... > ... >>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 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); Dave Jones Megatest Corp. 880 Fox Lane San Jose, CA. 95131 (408) 437-9700 Ext 3227 UUCP: ucbvax!sun!megatest!djones ARPA: megatest!djones@riacs.ARPA
mcdonald@uxe.cso.uiuc.edu (03/17/88)
> > 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@utzoo.uucp (Henry Spencer) (03/19/88)
> Fflush has no business adding newlines, ever, and an fflush need not be > 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. -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/19/88)
In article <2351@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
-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.gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/20/88)
In article <225800014@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >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.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/21/88)
In article <7490@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) 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 -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
mcdonald@uxe.cso.uiuc.edu (03/21/88)
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 McDonaldrsalz@bbn.com (Rich Salz) (03/21/88)
In comp.lang.c (<2422@bsu-cs.UUCP>), dhesi@bsu-cs.UUCP (Rahul Dhesi) shows
a VMS program where the line
printf("He"); fflush(stdout); printf("llo"); fflush(stdout);
generated two lines of output:
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 rsalz@uunet.uu.net.gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/23/88)
In article <225800016@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >a flush terminates a record. Show me where any accepted standard for C says that fflush() introduces a record delimiter.
djones@megatest.UUCP (Dave Jones) (03/23/88)
in article <2422@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) says: > > For the edification of all compiler writers, a log of a batch run under > VAX/VMS follows. > > main() > { > printf("He"); fflush(stdout); printf("llo"); fflush(stdout); > printf(" wor"); fflush(stdout); printf("ld"); fflush(stdout); > printf("\n"); > } > > He > 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!djones@riacs.EDU
mcdonald@uxe.cso.uiuc.edu (03/25/88)
>In article <225800016@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >>a flush terminates a record. >Show me where any accepted standard for C says that fflush() >introduces a record delimiter. 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
djones@megatest.UUCP (Dave Jones) (03/25/88)
in article <225800016@uxe.cso.uiuc.edu>, mcdonald@uxe.cso.uiuc.edu says: > 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!djones@riacs.EDU "If it's really broken, go ahead and fix it."
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/26/88)
In article <225800017@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >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).