HDTenEightyP/NetNews huggingface dataset:
Subject: Re: Turbo C FOPEN error
Reply-To: sff@mobrad.demon.co.uk.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.30 $
Organization: Mobile Radio Limited
Date: Wed, 27 Jan 1993 17:21:28 +0000

In article <1993Jan27.053643.21953@news.cs.brandeis.edu> gilmour@binah.cc.brandeis.edu writes:
> I can't figure out what's wrong.  This program works fine as long as there's
> less than 16 files (it doesn't actually matter what drive).  I haven't come
> across anything explaining it in the manual.  The error happens at runtime 
> during the 'stream = fopen(name...' line.  Anybody?

[Part of Program deleted]

>         done = _dos_findfirst("a:*.*", _A_NORMAL, &test);
>         while (!done) {
>                 strcpy(name, "a:");
>                 strcat(name, test.name);
>                 if ((stream = fopen(name, "r")) == NULL) {
>                         printf("Error in opening filename.\n");
>                         exit (1);
>                 }
>  
>                 getftime(fileno(stream), &ft);
>                 printf("%-16s%7lu\t%2u/%02u/%u\n", name,
>                         test.size, ft.ft_month,
>                         ft.ft_day, ft.ft_year+1980);
>                 done = _dos_findnext(&test);
>         }
>         fclose(stream);

[Rest Deleted]

Your problem is you're not closing the file after obtaining the information
you require - you're closing *one* file at the end of the program. What this
means in real terms is that you're exceeding the maximum number of files
which can be opened at any one time.

Try moving the 'fclose(stream)' line to just before the 
'done = _dos_findnext(&test)' line, and it should work.
i.e.
                printf("%-16s%7lu\t%2u.%02u/%u\n", name
                        test.size, ft.ft_month,
                        ft.ft_day, ft.ft_year+1980);
                fclose(stream);
                done = _dos_findnext(&test);

Sean.

==============================================================================
| Sean Fitt                          | My views are those with which I was   |
| sff@mobrad.demon.co.uk             | indoctrinated from a very early age.  |
| naffcode@cix.compulink.co.uk       | Please don't blame me if you don't    |
| 100034.2166@compuserve.com         | agree with them.                      |
|----------------------------------------------------------------------------|
| demon is a subscription site, and mobrad are not connected or related in   |
|                any way to any other demon subscribers                      |
==============================================================================
Newsgroups: comp.lang.c
From: alex@tsmnet2.melpar.esys.com (Alex Mason)
Subject: Curses - asynchronous question
Organization: E-Systems, Melpar Division
Date: Thu, 28 Jan 1993 15:14:33 GMT

What is the best way to write an curses application to display asysnchronous
output in one portion of the screen while having another portion of the
screen be reading input, menus, etc.

Is it possible to fork off a child process to asynchronously update with
curses or is curses inherently single-threaded?

I hope this isn't an FAQ

Please reply by mail to amason@melpar.esys.com

Thanks,


-- 
Alex Mason                                   Internet:  amason@melpar.esys.com
Network Engineering                              UUCP:  ..uunet!melpar!amason
E-Systems, Melpar Division
7700 Arlington Blvd, Falls Church, VA 22046          (703) 560-5000 x2451
Newsgroups: comp.lang.c,comp.lang.fortran
From: michael@chpc.utexas.edu (Michael Lemke)
Subject: Re: calling a Fortran subroutine from a C program
Organization: The University of Texas System - CHPC
Date: Fri, 22 Jan 93 23:36:18 GMT

In article <1993Jan22.200839.8352@sol.ctr.columbia.edu> bobp@msi.com (Bob Pitha) writes:
>Michael Lemke (michael@chpc.utexas.edu) wrote:
>: In article <1993Jan22.130743.27130@sol.ctr.columbia.edu> bobp@msi.com (Bob Pitha) writes:
>   (edited a bit for brevity's sake)
>: >
>: >4) Character arrays: For each character array in the argument list, there
>:               ^^^^^^
>
>: You are not talking about character arrays at all in your post.  A 
>: character array is something you declare as
>
>: 	character*(*) string(10)
>
>: which is an array of strings.  You talked just about plain character
>: strings.  Keep the terms clear.  Passing of character arrays is a bit
>: harder than what you described I believe (I might be wrong) but I don't
>: have my Sun manual handy to point out the differences.  Someone else
>: might.  But as you have suggested (which I deleted for brevity) reading
>: the Sun Fortran manual is worth doing.  It deals with all these issues.
>
>  This is really just an issue of semantics, but you're right that I wasn't
                          ^^^^^^^^^^^^^^^^^^

Not quite.  To make it really clear:  The difference is

	CHARACTER*100 STRING

or

	CHARACTER*1 STRING(100)

which are very different data structures.   The latter is an array, the
first is a single variable.  I don't care how C chews its memory, it can
hardly distinguish these two cases.  The last is pretty close in
functionality to C's concept (except for having a length stored
somewhere) as you'd need something like strcpy to copy data.

>very clear.  I was thinking in terms of an "array of type char" in C, so
>I just wrote what I was thinking.  As you point out, to a person who only
>knows Fortran the phrase "character array" may by misleading.  Unfortunately,
>this is an area where the concepts don't map well between the two worlds,
>since c doesn't have an official "string" type; a string is just a null-
>terminated array of characters.
>
>  Passing "arrays of strings" (is that clear enough?) is perhaps a little
>bit harder, but not a whole lot.  I didn't touch on null-termination and
>blank-filling in my previous post because I didn't know whether the
>original questioner cared and it would have taken lots more space.  I
>stuck to the simple case of passing an array of characters to the Fortran
>routine.  If the Fortran routine were going to try to pass a string back
>to C, or if an array of strings were being passed, you have to deal with
>these issues.
>
>-----------------------------------------------------------------------
>Bob Pitha                      Molecular Simulations Inc.
>bobp@msi.com                   16 New England Executive Park
>(617) 229-9800 x242            Burlington, MA 01803-5297


-- 
Michael Lemke
Astronomy, UT Austin, Texas
(michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
Newsgroups: comp.lang.c
From: sdl@engr.uark.edu (Steven Lovelady)
Subject: System Info
Summary: Need help with Machine anme
Organization: University of Arkansas
Date: Wed, 27 Jan 1993 14:15:11 GMT

I'm writing a program to display the System Info much like the one in 
Norton Utilities or Pctools.  I need to find out what type of machine 
I'm on and at what speed it's running. eg.( 386SX 16 Mhz)  Does anyone
know where I can get this information?  I've looked through BIOS and DOS
interrupts, but I can't find one that will give this info.  Any info
will be appreciated.  Thanks in advance.

Steven

Newsgroups: comp.lang.c
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Subject: Re: HALLOC and HUGE ptrs in Microsoft C
Organization: University of Helsinki
Distribution: world,local
Date: Fri, 22 Jan 1993 14:46:53 GMT

jjr@ace.ece.arizona.edu (Jeffrey J. Rodriguez) writes, about using
arrays larger than 64 kB under MS-DOS (notoriously an awkward
problem):

>This sure seems cumbersome.  It also seems that a program written for
>PC-DOS using halloc and huge ptrs would not run on a Sun running
>UNIX.  So much for portable C.

Quite.  The approaches I have followed are (more or less in the order
of preference):

a) forget about DOS machines and write the code under Unix
b) use a compiler under DOS that doesn't require halloc or other
   monstrosities for >64 kB arrays (djgpp is my choice)
c) don't use >64 kB arrays

I avoid halloc and huge pointers and other compiler-specific methods
like the plague they are.  Not only are they non-portable, they would
require me to learn and understand them first (lazy, ain't I?), and to
have to rely on the compiler to get things right while I'm not very
certain that I have understood things correctly.

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
   MS-DOS, you can't live with it, you can live without it.
From: misar@rbg.informatik.th-darmstadt.de (Walter Misar)
Newsgroups: comp.lang.c
Subject: Re: Roman Numerals
Date: 26 Jan 1993 19:35:02 GMT
Organization: TH Darmstadt
Distribution: world
NNTP-Posting-Host: rbhp58.rbg.informatik.th-darmstadt.de

In article <damatt01.728068722@starbase.spd.louisville.edu>, damatt01@starbase.spd.louisville.edu (David A. Mattingly) writes:
> 
> Does anyone know of an integer-to-Roman-numeral converter? I know I saw one in
> a collection of utilities, maybe on simtel20...

Get yourself intercal :)

In C this routine should do:

#include <stdio.h>

int roman(int num)
{ static char *letters="IVXLCDMA";
  static int x=0;
  int j;

  if (num<=0 || num>=4000) return -1;
  x+=2;
  if (num>=10) roman(num/10); 
  x-=2;
  switch(j=num%10)
  { case 4 : putchar(letters[x]);
             putchar(letters[x+1]);
             break;   
    case 9 : putchar(letters[x]);
             putchar(letters[x+2]);
             break;
    default: if (j>=5) j-=5,putchar(letters[x+1]);
             for(;j;j--) putchar(letters[x]);
  }
  return 0;
}

-- 
Walter Misar                                | It is impossible to enjoy
misar@rbg.informatik.th-darmstadt.de        | idling thoroughly unless
                                            | one has plenty of work to do.
Newsgroups: comp.lang.c
From: rs@cmie.ernet.in (Rajappa Iyer)
Subject: Re: Is this a Legal Way to Access a Specific Address?
Keywords: DSP, C, ANSI, Fixed RAM
Organization: Centre for Monitoring Indian Economy, Bombay
Date: Sat, 23 Jan 1993 10:56:03 GMT

scotty@verdix.com (Scott R. Chilcote) writes:


>We're programming a device that has a RAM cache at address 809800H.
>Is it legal to address this memory in C as follows?
>#define ON_CHIP 0x809800
>int main(void)
>{
>   float *oc_ptr = (float *) ON_CHIP;

>Does anyone know if this is acceptable coding, and what kinds of
>problems could crop up from using this method?

It is definitely legal C. Whether or not it is good programming
practice is debatable. I personally find it acceptable since the only
argument against using such techniques is portability --- which does
not really seem to be an issue here. I presume you are writing a
device driver.

>The other way we can achieve the same result is using the linker for this 
>device to declare a section of memory at a specific address, and associate
>a label with the section.  We can then use that label with an external pointer
>declaration in the C program ( extern void *on_chip; ) to reference the 
>specific address we need.  This method requires more CPU cycles than the one
>above to resolve pointers, but at least the address space we're using is 
>declared in the linker's memory map.

Do you really think this would make the program easier to maintain? I
don't think so.

-- 
Rajappa Iyer			rs@cmie.ernet.in (Preferred)
				riyer@shakti.ncst.ernet.in
Newsgroups: comp.lang.c,comp.os.msdos.programmer,alt.sources
From: woodard@figment.tmc.edu (Chris Woodard)
Newsgroups: comp.lang.c
Subject: Re: Moving from Pascal to C, Help please!!!!!!
Date: 18 Jan 93 21:53:57 GMT
Organization: University of South Florida, Department of Computer Science and Engineering



I beg to differ with you on one point.  Segment addresses are *only* ignored
if you're in a memory model that uses 16-bit pointers.  In others, such as
Large and Huge, all 32 bits are important and the segment address *is* used in
the pointer arithmetic.

There  _is_ a good reason for using pointers instead of arrays.  If you had
code such as

[ example 1]

	register char *p1;
        register char *p2;

	while( *p1 ) *p2++ = *p1++;

to copy the contents of one "string" to another, the generated code only has
to access a single variable (which can be given "register" class for faster
access).  If, on the other hand, you have code such as

[ example 2 ]

	char p1[26], p2[26];
	int k = 0;

	while( p1[k] ) p2[k] = p1[k++];

then (a) your source and destination addresses are in const pointers, (b) you
have to access them using an index variable that requires a MOV instruction
for each invocation of the variable, and (c) you have some implicit address
arithmetic in computing the offset into the array in the first place.

Making a fetish out of avoiding address arithmetic is a cop-out for people who
aren't comfortable with pointers ... and they should probably stick to
programming in (ugh) Pascal or (double ugh) COBOL, and let the rest of us
alone.
Newsgroups: comp.lang.c
From: nace@fortress.usafa.af.mil (Capt Bill Nace)
Subject: Re: Obscure C-Programs? Where to find?
Reply-To: nace@fortress.usafa.af.mil
Organization: Sun Microsystems, Inc.
Date: Fri, 22 Jan 1993 16:02:32 GMT

I have a book _Obfuscated C and Other Mysteries_ by Don Libes.  An excellent book,
it covers lots of the dark corners of C thru the use of some of the Obfuscated C
contests.

Published by Wiley, ISBN 0-471-57805-3, $39.95

I am not associated with the publisher, author, etc (except thru reading the book).

Bill Nace
Xref: sparky comp.lang.c:20030 comp.lang.c++:19696
From: mharriso@digi.lonestar.org (Mark Harrison)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: C/C++ Correctness (was: Re: C/C++ Speed)
Date: 21 Jan 93 17:14:17 GMT
Organization: DSC Communications Corp, Plano, TX

In article <1993Jan19.005020.12507@informix.com> cshaver@informix.com (Craig Shaver) writes:

>What C++ standard library?

The "C++ Standard Libraries" from USL.  It's the one with iostreams,
and comes with C++ compilers from many vendors..

>What excellent coroutine library?  

The one written by B. Stroustrop and Jonathan Shopiro.  It's very likely
that you have this at your site.  Look in your compiler documentation for
a section entitled "A Set of C++ Classes for Co-routine Style Programming."

>1.	This sounds like most of the gain came from elimination of the
>	UNIX IPC based approach in favor of a threaded single process.

Exactly.  The C++ library provided a method of multi-threading the
application that was portable across the target platforms.  They didn't
have that in their C environment.

"Remember that much programming can be simply and clearly done using
only primitive types, data structures, plain functions, and a few
classes from a standard library" -- B. Stroustrup, 1985.

>I suspect the same result could be had using straight C.  The real gain
>comes from code reuse to simplify the problem and expedite the solution.

And this is one of the big wins of C++.  It facilitates library building
and code reuse.

Anyways, I though the prosecution/defense had rested. :-)
-- 
Mark Harrison, mharriso@dsccc.com
Xref: sparky comp.lang.c:20094 comp.lang.c++:19788
From: pasturel@BA.TIS.COM (Pierre Pasturel)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: C vs C++ for portability
Date: 22 Jan 93 23:46:14 GMT
Reply-To: pasturel@TIS.COM
Followup-To: comp.lang.c
Organization: Trusted Information Systems


Someone I know is trying to decide between C or C++
to write educational software that will run on both MACs
and PCs. The educational software will
be very graphics intensive, as these will be programs
for 2 to 6 year olds.

Are there any advantages to using C vs C++  or 
C++ vs C to make it easier to port between
the two machines?  For writing graphic intensive programs?

thanks for any input and please reply to pasturel@tis.com
directly, as I don't read this newsgroup regularly.

If there is enough feedback, I will post a summary.

thanks,
Pierre
pasturel@tis.com
From: guy@mais.hydro.qc.ca (Guy Harel)
Newsgroups: comp.lang.c
Subject: Looking for an X based 'rcs'
Date: 28 Jan 93 14:27:22 GMT
Organization: Hydro-Quebec (DSB)


Hello,

We are looking for a good 'Revision and Control System' for our numerous 
C and ORACLE (*.inp) modules, maintained by numerous programmers.

We want a sound Xwindow support, straightforward access to our source,
staightforward and customizable 'make'.

We know about the freeware solutions (rcs, cvs), but would like to 
consider a commercial product (since our needs might increase).

A FAQ file in 'comp.software-eng' failed to mention some commercial products
we`ve heard about. I would appreciate any comments or recommendations
on them

Thanks a lot.


Not in the FAQ file:


	PVCS 5.0			Intersolv

	ClearCase			Atria Software

	CaseVision 			Silicon Graphics (SUN?)
	(ClearCase)

	Config Mgmt			IBM (AIX line, SUN, HP)
	Version Control

	ClearCase			Atria Software	



In the FAQ file:

	DSEE				Apollo (only)

>	Softool				Softool Corp 

>	Aide-de-Camp			Software Maintenance & Dev Sys, Inc

	CaseWare/CM			CaseWare Inc

	SMS				Intasoft
-- 
--
From: mick@dcs.bbk.ac.uk (Mick Farmer)
Newsgroups: comp.lang.c
Subject: Re: Preprocessor question
Keywords: Preprocessor, string
Date: 26 Jan 93 18:26:37 GMT
Organization: Bloomsbury Computing Consortium

Hi,

Karim asks how to get a preprocessor macro recognised inside
a string.  The answer, at least in ANSI C, is to use the
stringising operator and string concatenation:

#define JUNK 50
static char *junk = #JUNK " ways to leave your lover"

The construct #JUNK generates the string "50", which is
concatenated with its neighbour.

Regards,

Mick
Newsgroups: comp.lang.c
From: rioj7@fel.tno.nl (M.L.M.Veraart)
Subject: Re: How do you read binary data piped into stdin?
Organization: TNO Physics and Electronics Laboratory
Date: Tue, 26 Jan 93 08:07:18 GMT
Keywords: stdin, redirection, binary data

chorn@eastwind.mcds.com (Christopher Horn) writes:


>I'm relatively new to C, so still have a lot to learn, so I apologize
>if this is a silly question. I need to read raw binary data from
>stdin (it is being piped in) but it appears stdin operates in text
>mode. The first ascii 26 that comes along triggers end of file, and
>I can't read the rest of the data. Could someone please explain, or
>better yet show me a short peice of code, that could do this? The
>answer is probably obvious, but it eludes me at the moment. Thanks
>a lot!

Christopher, because you don't show a small piece of code you use
I think that you use the function scanf(). If you use the function
fread(stdin, ) I think this will read binary data, because scanf() 
has an ascii interface built in.

Try it and let us know.

Mario
-- 
Mario Veraart                  TNO Physics and Electronics Laboratory
email: rioj7@fel.tno.nl        The Hague       The Netherlands
"If all else fails, show pretty pictures and animated videos, 
 and don't talk about performance",  David Bailey
Newsgroups: comp.lang.c
From: benjie@quack.sac.ca.us (Android)
Subject: Algo. for Integration and Differentiation ?
Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'.
Date: 24 Jan 1993 01:40:55 UTC

Hello.
I need algorithms for integration and differentiation of basic
functions.  Is there a ftp site that has them?
Thanks
Benjie

-- 
     BBB		Benjie Chen
    BCCCB 		benjie@quack.sac.ca.us
    BCCCB		No Axiomatic System Could Produce All Number-
     BBB		Theoretical Truths, Unless It Is Inconsistent.
Newsgroups: comp.lang.c
From: elias@proxxi.uf.se (Elias M}rtensson (proxxi))
Subject: Re: Few simple questions
Organization: proxxi
Date: Fri, 22 Jan 1993 14:37:25 GMT

kugold@kuhub.cc.ukans.edu writes:

>1. In unix, the backspace key does not work properly. I already 
>   found out that this can be changed by typing stty erase ^?, where '^?' 
>   means ctrl-?. I tried to include this in my .login file, but emacs does 
>   not accept ^?. How do I put this line in my .login file?

Backspace? Surely you must mean that the "delete" key does not work
properly. Emacs uses it's own key bindnings, and usually delete is
the rubout character. You can change both the delete and the backspace
characters to whatever you want by putting something like the
following in your .emacs file:

; This will set backspace to be the rubout character
(global-set-key "\C-h" 'backward-delete-char)
; This will do the following to delete
(global-set-key "\C-?" 'backward-delete-char)

>2. In C I need an input function like INKEY$ in BASIC, that is a function that
>   does _not_ wait for input, but just an empty string or so returns if no 
>   character is entered. (I am trying to measure the time between two key-
>   presses). Does this function exist, and if not, is there any way to do
>   what I want?

If the time to be measured is short (like tenths of seconds and you really
need this detail) there is no portable way to do it since UNIX is not a
realtime operating system. But you can try to check the number of
characters is the queue by using an ioctl() call.

>3. In C again, I want to initialize and array of integers, like
>   
>   main()
>   {
>     int ttime[6]={0,0,0,0,0,0}
>     /* rest of program */
>   }

[error messages removed]

>   I really don't see what is wrong, the more because in my c-book,
>   "C by discovery" by L.S. Foster on page 213, almost exactly the
>   same thing is done.

This one is easy, your compiler is not an ANSI-C compiler. Try gcc or
some other ANSI-compiant compiler instead.

>Thanks a lot in advance for any answer and I am sorry if the UNIX question 
>doesn't belong in this newsgroup.

>Regards,

>Wimjan

>kugold@kuhub.cc.ukans.edu 

######################
#   Elias Martenson  #
# elias@proxxi.uf.se #
######################
Newsgroups: comp.lang.c
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Conversion of BASIC code to "C"
Date: 25 Jan 93 12:41:37 GMT
Organization: negligable

In article <1jutuaINNrop@tamsun.tamu.edu> pinky@tamu.edu (The Man Behind The Curtain) writes:
>
>At any rate, I could probably read and understand most variations
>of Basic, though you might choose to call them something else.
>If I didn't know Pascal, on the other hand, I would be unlikely
>to understand what someone else had written.

No.  Actually I think you would just think it another dialect
of (new) Basic.  Many structured languages are fairly easy to read with
a little experience from others.  You might not be able to WRITE in it
w/o getting a few dozen messages from the compiler though.

		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"If we do not succeed, we risk failure."			-D. Quayle
From: rvilla@navier.ae.utexas.edu (reynaldo villarreal)
Newsgroups: comp.lang.c
Subject: Why C over FORTRAN
Date: 28 Jan 93 03:10:09 GMT
Organization: CFD Lab, Dept ASE-EM, University of Texas at Austin
In-reply-to: ray@rann.sbi.com's message of 21 Jan 93 18:16:06 GMT


I am interested in the pros and cons of C vs. FORTRAN.(gcc vs f77 on a
Sun) I have to write code and have to give an informed choice to my
advisor on which to use.
Newsgroups: comp.lang.c