HDTenEightyP/NetNews huggingface dataset:
From: karl@ima.isc.com (Karl Heuer)
Subject: Re: Function pointer problem
Organization: Formerly of Interactive Systems, Cambridge, MA
Date: Mon, 28 Sep 1992 17:29:20 GMT

In <1a5r9sINN6k1@almaak.usc.edu> ajayshah@almaak.usc.edu (Ajay Shah) writes:
>typedef void *Observation;
>typedef void (obsprinter)(Observation);
>void somefunction(Observation x, obsprinter *f);
>void floatpairprinter(float *x) { printf("%f %f\n", *x, x[1]); }
>[pass floatpairprinter as second arg to somefunction]

>Is there a way to do this right?  I can see his problem: he wants a
>function which consumes a Observation, but I'm giving him a function
>which consumes a float *.  How do I reassure him all is well?

All is *not* well.  The program works on a vaxlike architecture, but there
are other implementations out there where it fails horribly.  You need to
declare your function to have the same signature that somefunction has been
told to expect:
	void floatpairprinter(Observation ob) {
	    float *x = (float *)ob;
	    printf("%f %f\n", *x, x[1]);
	}

(Btw, it might be less confusing if you use a typedef for the function-pointer
type rather than the function-type.)

Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
Newsgroups: comp.lang.c
From: joec@fid.morgan.com (Joe Collins)
Subject: Problem in Turbo C/C++ with DOS.H
Organization: None
Date: Tue, 29 Sep 1992 14:14:58 GMT


Help!

I am beyond novice level with C, but not much more....

Anyway, I have a C program which is like DOS erase but more.
In effect, it allows you to do 'erase *.*', interactively or
without prompting of 'normal' files, i.e. not readonly, hidden, etc

Anyway, in the code I use:
     #include <dos.h>
and compile the code and get compile errors in dos.h (!).
The error messages are:

  VALUE OF TYPE VOID IS NOT ALLOWED

  ) EXPECTED


This appears for 2 lines in dos.h - here is one of the failing lines:

unsigned _Cdecl _dos_write( int __fd,void far *__buf,unsigned __len,
            unsigned __nread);

For those who have the dos.h, its line 277 therein.

WHAT IS WRONG? Should I speak to Borland about this or is there
a compile option I need? 

THANKS in advance....

Joe
joec@morgan.com
             


Xref: sparky comp.lang.c:14401 comp.lang.c++:14411
From: labraham@gradient.cis.upenn.edu (Lisbi Abraham)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: MS C/C++ vs. Borland C/C++ with regard to Windows Development
Date: 1 Oct 92 21:38:37 GMT
Followup-To: comp.lang.c++
Organization: University of Pennsylvania

My company is in the process of switching development platforms to the
Windows environment.  We would be coding for both Windows NT and the
regular Windows 3.* operating systems.  With that in mind, could everybody
give me their views on the pros and cons of using the Microsoft development
kit versus the Borland development kit.  If there is enough interest, 
I will post a summary of the answers to the net.

Thanks,
Lisbi

Newsgroups: comp.lang.c
From: hm@cs.brown.edu (Harry Mamaysky)
Subject: line number in C program
Organization: Somewhere East or Somewhere West
Date: Mon, 5 Oct 1992 19:35:42 GMT


Is there a way for me to find out what line number is currently being
executed in a c program from within that program?

Will this method also work in C++?

Harry.

hm@cs.brown.edu


Newsgroups: comp.lang.c,comp.sources.wanted,comp.msdos.programmer,comp.misc
From: walkerlw@rtsg.mot.com (Lanny W. Walker)
Subject: Re: Wanted: C-isam library for Turbo C or Microsoft C
Organization: Motorola Inc., Cellular Infrastructure Group
Distribution: us
Date: Mon, 5 Oct 1992 16:10:43 GMT

In article <BvMK7v.664@ais.org> draper@ais.org (Patrick Draper) writes:
>In article <1992Oct2.132840.27055@jmp.com> gbm@jmp.com (Gary McKenney) writes:
>>In article <1992Sep30.171329.10078@di.unipi.it> Nico Tranquilli <@> writes:
>>>Does anyone have (or know where to find) C-Isam libraries for
>>>Microsoft C 6.00 or Turbo C 2.0 compiler ?
Stuff deleted.
>Also, try Mix Software's 20 dollar database toolchest. I've heard good
>reviews of that, although I have no personal experience. The price is
>certainly right.
Stuff deleted.

I have used the Mix Software's with Turbo C 2.0.  I liked it.  It is relatively
easy to program and has a very consistent calling syntax.  It does not handle
file sharing and locking though.  If you need a multi-user simultaneous access
database, Mix's C Database Toolchest is of no use to you.  But if you are in
a single user environment, it could work very well for you.


Wayne Walker

The opinions are my own...no one ever agrees with me ...
From: prato@qut.edu.au
Newsgroups: comp.lang.c
Subject: C Routines to print BARCODES on HPLJIII
Date: 2 Oct 92 15:49:07 EST
Organization: Queensland University of Technology


Would anybody know where I may obtain a copy of Borland C 
routines that would print barcodes on a HP Laserjet III?

If anybody has experience/knowledge in this area,
please let me know.

Your assistance would be greatly appreciated.

James Prato,
Computer Systems Officer,
MIS Section,
Queelnsland University of Technology,
Brisbane. Qld
Australia.
email:J.PRATO@qut.edu.au
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: File Accessing in C
Date: 28 Sep 92 05:58:58 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <8.717385977@bonnie.ics.uci.edu>, jlinder@Bonnie.ICS.UCI.EDU (Darrow Linder) writes:
> This I have learned to realize but the problem I am having is getting
> the getenv("HOME") result into a "char  buff[256]" type of variable rather
> than a "char  *buff" variable.

strcpy

By the way, it is dangerous to get into the habit of assuming that
things will fit into 256 bytes.  There is no reason in UNIX why $HOME
_has_ to be that short.

Try this.

#include <stdlib.h>
/*  For size_t and getenv()  */
#include <string.h>
/*  For strlen() and strcpy()  */

char *bgetenv(varname, buffer, buflen)	/* Copy env. var. into buffer */
    const char *varname;		/* Which environment variable */
    char *buffer;			/* Where to put its value     */
    size_t buflen;			/* How big buffer[] is.       */
    {					/* Return NULL on failure.    */
	char *value = getenv(varname);
	if (value == NULL) return NULL;
	if (strlen(value) >= buflen) return NULL;
	return strcpy(buffer, value);
    }

> main()
> {
>     char *ptr,*getenv();
> 
>     ptr = getenv("HOME");
> }

DO NOT DECLARE getenv() THAT WAY.  USE THE STANDARD LIBRARY HEADER.
If you _must_ describe getenv() yourself (using a Classic C compiler,
for example), do

	#if _STDC__ < 1
        extern char *getenv();
	#endif

If you are using an ANSI C compiler, the standard library headers will
contain prototypes for the library functions, and declaring them yourself
may either produce warning messages or else result in less checking.

	/* copy the definition of bgetenv() from the earlier part */
	/* of this message */

	main()
	    {
		char buf[256];		/* why this magic number? */

		if (bgetenv("HOME", buf, sizeof buf) == NULL) {
		    /* Either $HOME doesn't exist or buf[] is too small */
		} else {
		    /* You're away laughing */
		}
		...
		exit(0);
	    }

-- 
RMIT policy requires the use of Gender Inclusive Language in all publications
and in all information conveyed to students, staff, and potential job
applicants.  Lapses into English are the sole responsibility of the author.
The Constitution of Australia does _not_ guarantee Freedom of Speech.
Newsgroups: comp.lang.c
From: "elliott chapin" <elliott.chapin@canrem.com>
Subject: c database
Reply-To: "elliott chapin" <elliott.chapin@canrem.com>
Organization: Canada Remote Systems
Distribution: comp
Date: 3 Oct 92 13:36:44 EST

TO: abutler@ariel.demon.co.uk

UG>place. So the problem is, how do I search this database and add records
UG>to it - with a linked list, the links point to memory locations, which
UG>is no good if the records are on disk. Aslo, I would (presumably) want

I don't know C well enough yet to be able to give you a direct answer,
but most implementations of Forth allow for easy setup of disk space as
virtual memory; maybe you can do something similar in C ...

Elliott Chapin
---
  DeLuxe 1.12 #4315  elliott.chapin@canrem.com
--
Canada Remote Systems  - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044
Newsgroups: comp.lang.c
From: wilson@rhombus.cs.jhu.edu (Dwight Wilson)
Subject: Re: Untyped pointer arithmetic
Organization: The Johns Hopkins University CS Department
Date: Thu, 1 Oct 1992 22:47:34 GMT

In article <018yRB2w165w@quest.UUCP> srhqla!quest!kdq writes:
>wilson@gauss.cs.jhu.edu (Dwight Wilson) writes:
>> In article <14813@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O
>> >So it is syntactically legal to do
>> >	void *p, *q;
>> >	ptrdiff_t d;
>> >	d = (char*)q - (char*)p;
>> 
>> Not quite.  This is only a legal pointer operatin if p and q point
>> to members of the same array, or either is the address of the first 
>> element past the the end of an the array.  
>
>Do you really mean legal, or do you mean meaningful?
>

If p and q are not members of the same array (with the above
exception) then the operation is illegal.  The code is legal,
i.e., it will compile and execute, but the result is undefined.

To quote K&R, 2nd ed (page 103).

"The valid pointer operations are assignment of pointers of the
same type, adding or subtracting a pointer and an integer, subtracting
or comparing two pointers to members of the same array, and assigning
or comparing to zero.  All other pointer arithmetic is illegal."

-Dwight
From: smee@bristol.ac.uk (Paul Smee)
Newsgroups: comp.lang.c
Subject: Re: can != be used in compound if
Date: 30 Sep 92 08:33:23 GMT
Reply-To: P.Smee@bristol.ac.uk (Paul Smee)
Organization: University of Bristol

In article <1992Sep28.194631.25334@julian.uwo.ca> operator@julian.uwo.ca (Operator) writes:
>rnum is a random number generated by random().
>number_set[] is an array of 6 integers.
>
>if (rnum != number_set[1] && rnum != number_set[2] && rnum != number_set[3])
>
>is this if statement correct, if not, what is wrong with it????

Nothing wrong with that statement per se, looking at it in isolation.
As someone else has pointed out, however, if the type of number[] is
not the same as the type of rnum, it's not likely to do what you
expect.  Another possibility, based on the way you've presented this
example, is that you might be being confused by C subscripts.  Are you
aware (I hope) that the first 3 elements of the array number_set[] are
number_set[0], number_set[1], and number_set[2], and not 1 thru 3 as
you have used them?

If your problem is that the prog doesn't compile, remember that the
compiler can't always detect errors instantly, depending on what sort
of errors they are.  If it's your compiler which is complaining about
that statement, it might mean that somewhere earlier in the program you
have one too many (or too few) '}' terminators, so your blocks aren't
where you think they are; or that you have an un-closed comment which
is eating more of the text than you want, or something like that.

-- 
Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK
 P.Smee@bristol.ac.uk - ..!uunet!uknet!bsmail!p.smee - Tel +44 272 303132
Newsgroups: comp.lang.c
From: "chris perkins" <chris.perkins@canrem.com>
Subject: 'make' woes (won't ca
Reply-To: "chris perkins" <chris.perkins@canrem.com>
Organization: Canada Remote Systems
Distribution: comp
Date: 3 Oct 92 10:34:46 EST


In message From: gbnewby@uxh.cso.uiuc.edu (Gregory B. Newby)
Subject: 'make' woes (won't catch secondary dependancy)

GB>I have a header file that #include's another header file.  I
GB>would like for my 'make' to catch whether either of them are
GB>modified.  Here is a very simple example of what goes wrong
GB>(of course, what I'm doing is a bit more complicated....hence,
GB>just putting "test.o: h1.h h2.h" will work in this example,
GB>but will not give me the freedom & capability I need to be
GB>happy):

How does this sound:

1% cat makefile
.c.o:
        cc -c $*.c -I.

test.o: h1.h

h1.h: h2.h
        touch h1.h

2% make


You may also want to try,

.c.o:
        cc -c $*.c -I.

.h.h:
        touch $@

test.o: h1.h

h1.h: h2.h


although I'm not sure it will work.

Regards,

Chris
---
  DeLuxe/386 1.25 #9629  Best wishes,            Chris Perkins
--
Canada Remote Systems  - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044
Newsgroups: comp.lang.c
From: atbowler@thinkage.on.ca (Alan Bowler)
Subject: Re: Union-initialization portability
Organization: /etc/organization
Date: Tue, 6 Oct 1992 21:40:52 GMT

In article <363@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
>You can't use a function call in a constructor.
>
>There seems to be nothing wrong w/ your example ... you seem worried
>that you haven't "cast back" the pointer into it's proper type.  You
>have.  That is what a union does -- provides multiply-typed handles
>to the same data.  In Pascal the ONLY way to cast data from one type
>to another is by stuffing it through a "variant record" structure (the
>Pascal equivilant of a union).
>

That is not a "cast".  A cast is a conversion from one type to
another.  The machine might or might not actually change anthing
when it does this conversion.  What you are trying to do is sometimes
called "punning".  You are trying to say to the machine.  "See this
data at this location.  Believe me it is data of type X".  Neither C
nor Pascal supplies a guarenteed way to do puns.  Because C requires
that all elements of a union share the same memory, you can usually use
a union to do a pun.  This could fail on hardware which stored
additional type information with each memory location.  Such hardware
is rare.
     Although Pascal variant records are usually implemented as
like a union, there is no requirement that this be done, so you cannot
rely on this being done.  Also there is a very real chance that a
compiler that does checking will add additional checks to prevent you
from attempting use a variant record to perform a pun.  It is certainly
within the "spirit of Pascal" that the compiler check that the tag is
correctly set on each access to a particular variant.  Even when there
is no explicit variant tag variable named, a compiler could easily add
a hidden on that was updated at appropriate times.
From: heilig@plains.NoDak.edu (Zachary Heilig)
Newsgroups: comp.lang.c
Subject: Re: Is there is (pascal) WITH equivalent in C?
Date: 6 Oct 92 15:53:46 GMT
Organization: University of North Dakota, Grand Forks

In article <7440@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
>In article <1992Oct2.073814.27698@organpipe.uug.arizona.edu> dave@cs.arizona.edu (Dave Schaumann) writes:
>
>While the comment about the code fragment is correct, the following is not:
> > 
> > Pascal's with statement is nothing more or less than syntactic sugar.
> > 
>It is more than syntactic sugar:
>
>type plist = ^list;
>type list = record next, prev: precord end;
>{ to implement a doubly linked list }
>var a : plist;
>...
>{ remove a.next from the list }
>	with a.next^ do
>	begin
>	    a.next := next;
> 	    next^.prev := prev;
>	end;
>Writing this as:
>	a.next := a.next^.next;
>	a.next^.next^.prev := a.next^.prev;

and people said C was unreadable...

>is wrong!  Because of this there are things that can be formulated more
>simple with with statement than without.

try:

	a.next := a.next^.next;
	a.next^.next^.prev := a;
	      ^^who the hell thought up the ^. awkward operator anyway?

>-- 
>dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
>home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl

Why would you want to remove the next object in the list? I find it Much
easier to remove the current object. like so:

typedef struct precord {
	precord	*next;
	precord *prev;
} plist;

plist	*a;

a->next->prev = a->prev;
a->prev->next = a->next;

/* ( I use c++ more, and this comes out looking much much better ) */
-- 
    - Zach Heilig (heilig@plains.nodak.edu)

Ninety-Ninety Rule of Project Schedules:
	The first ninety percent of the task takes ninety percent of
	the time, and the last ten percent takes the other ninety
	percent.
Newsgroups: comp.lang.c
From: rrwood@canrem.com (limited shell account - Roy Wood)
Subject: "Born to Program in C" code?
Organization: Canada Remote Systems
Distribution: na
Date: Tue, 06 Oct 1992 01:40:25 GMT

I picked us in the bookstore the other day and picked up a copy of an
interesting book called "Born To Code in C".  Rather than just the usual
C manual, this was a book containing a lot of interesting problems
with solutions in C, as well as many interviews with notables from the C
programming community.  I highly recommend the book, though that is not
the point of this posting.

As usual, the author/publisher of the book offered to provide machine-readable
copies of the source code from the book for an exorbitant amount of money
(about 2/3 of the cover price!).  Now, I have no quarrel with the publisher
over selling a disk containing the code, but I don't see why it's so expensive
to do so-- particularly if I've already shelled out $40 for the book.  I suppose
we could start a long flaming thread on the subject of pricing or profit for
accompanying disks, but again, that's not why I'm posting this.

I am interested in a particular project from the book (A C interpreter,
believe it or not) for use in a high school class I teach, and I'd like to
get a machine-readable copy of the source code.  However, I don't want to shell
out the extra money for the disk, and I'd prefer not to have to type the thing
in myself.  So, my question is whether anyone out there has a copy of the
disk and would be willing to send me the code.  (And I don't want to hear
from any wags telling me that the book itself is machine-readable if I have
an optical scanner.)

-Roy Wood
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: how do you use getpass() correctly
Date: 6 Oct 92 05:38:08 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <370@ulogic.UUCP>, hartman@ulogic.UUCP (Richard M. Hartman) writes:
: In article <14839@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
: >By the way, if you are only going to read one password, why copy the
: >answer?  Just do
: >
: >	char *the_only_password;
: >
: >	... the_only_password = getpass("Enter Password: "));
: 
: Because we have no guarantee that the pointer returned by getpass()
: is to memory which will retain the data.

We are not talking about getpass-like functions in general, but
about getpass specifically.  And yes, we do have a guarantee in the manual
page that getpass returns a pointer to a static buffer which retains its
data until the net call to getpass().

-- 
RMIT policy requires the use of Gender Inclusive Language in all publications
and in all information conveyed to students, staff, and potential job
applicants.  Lapses into English are the sole responsibility of the author.
The Constitution of Australia does _not_ guarantee Freedom of Speech.
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: pointer increment vs. subscript increment was: Duff's Device
Date: 28 Sep 92 22:17:35 GMT
Organization: negligable

In article <1992Sep25.172557.452@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
>In article <276@ulogic.UUCP>, hartman@ulogic.UUCP (Richard M. Hartman) writes:
>|> [...]
>|> A big "if" there.  The compiler has no basis upon which to judge
>|> whether you are intending to use the revised position of the pointer
>|> w/o resetting it or not, why should it try to second guess you?
>
>In a loop, the compiler *does* have a basis on which to judge this.
>Either the pointer is an iteration variable of the loop (that is, it
>covaries linearly with the trip count) or it isn't.  Outside a loop
>the compiler may not know what the next use of the pointer is.  It's

Precisely.  And the next use of the pointer may be well after the
end of the loop, and relying upon the posiiton of the pointer at
the end of the loop (don't ask me for a practical application of
this, we're just talking about the compiler making assumptions
about the code and whether optomizations should be allowed to
alter side effects of the code as written).

>*usually* less critical there - things outside a loop are usually
>not executed as often.  If the compiler can't determine the liveness
>of *any* value (not just pointers), that will inhibit its ability
>to optimize the code.  A good liveness analysis is not "second guessing",
>its a vital part of good code generation.

Of course if by this next part you are saying that the compiler 
shouldn't be optomizing code if it cannot determine the next use
of the pointer in quesition, that's all I was saying in the first
place and why did you bother replying?


		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Nobody has ever had a sexual fantasy about being tied
 to a bed and ravished by somebody dressed as a liberal."    -P.J. O'Rourke
From: volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe)
Newsgroups: comp.lang.c
Subject: Re: Common C errors (was Strange memory allocation...)
Date: 30 Sep 92 13:00:57 GMT
Reply-To: volpe@ausable.crd.ge.com
Organization: GE Corporate Research & Development

In article <717558228snx@Wellspring.COM>, elliot@Wellspring.COM (Elliot H. Mednick) writes:
|> A common (maybe not THE most common, but close) error in C (reason #215
|> that I wish the general computing community would allow me to program in
|> Some Other Language and not laugh me out of an interview for knowing PL/1)
|> is:
|> 
|> b == a;            /* an attempted assignment */
|> 
|> This statement does nothing, but cannot be flagged as a warning.

Anything can be flagged as a warning. E.g.:

foo.c: line 217: Warning - this algorithm resembles bubblesort. Try using
	         quicksort instead.

-Chris

-- 
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
From: wilson@rhombus.cs.jhu.edu (Dwight Wilson)
Newsgroups: comp.lang.c
Subject: Re: Problem using fseek
Keywords: file operations
Date: 2 Oct 92 14:54:45 GMT
Organization: The Johns Hopkins University CS Department

In article <1992Oct2.030809.26674@mnemosyne.cs.du.edu> ghuntres@nyx.cs.du.edu (Gary  huntress) writes:
>
>Is there any reason why the following wont work (IBM PC w/ msc 6.0)
>fh=fopen("foo.dat","a");
                    ^^^

Using "a" will open your file for writing only, so this is already
a problem.

>if(fh==NULL) exit(-1);
>fseek(fh,-5L, SEEK_CUR);
>It just sits at EOF!  It does not rewind.
>
>
>  1)  Can I seek backwards through a file opened for append?

No, when opened in mode "a", the file pointer is automatically
positioned to the end of file before each write, regardless
of intervening fseeks.  As I stated above, you can't read from
this file.

>  2)  Is there an incredibly obvious solution to this problem 
>      that I completely overlooked? 
>

You could open it for update at the end of the file "a+", or
more portably "a+b".  Wouldn't it be easier to just open
in for reading and seek to the end of the file, then start
looking backwards?  

fh = fopen("foo.dat", "rb"); 
fseek(fh, 0, SEEK_END);

Even better, seek to MAX_LINE_LENGTH bytes before the end, 
read MAX_LINE_LENGTH bytes into a buffer, and find the last
line using that buffer.

-Dwight
Newsgroups: comp.lang.c