HDTenEightyP/NetNews huggingface dataset:
From: swalter@nyx.cs.du.edu (DreamWeaver)
Subject: Re: Help! what's wrong with this program?
Organization: University of Denver, Dept. of Math & Comp. Sci.
Distribution: usa
Date: Sun, 6 Sep 92 20:36:12 GMT


Correct me if I'm wrong (lord knows that will happen ;) ... but doesn't
the line

   *bp++ = c;

in the pusch() function actually mean (as far as order of precedence):

   (*bp)++ = c;

and not (what you want or think):

   *(bp++) = c;

Call me kooky ...

-Scotty
From: wkaufman@us.oracle.com (William Kaufman)
Newsgroups: comp.lang.c
Subject: Re: I disagree with lint(1)
Keywords: lint, classic C
Date: 10 Sep 92 02:40:47 GMT
Organization: Oracle Corporation, Redwood Shores CA
X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.


    Well, here's my take.  At the very least, I believe this is why lint
is complaining: whether it *should* complain is a different matter.

In article <1992Sep7.083401.2587@sci.kun.nl> hansm@cs.kun.nl (Hans Mulder) writes:
] 
] typedef struct foo *bar;
] 
] fun(b)
] bar b;
] {
]     b=b;
] }

    fun() is a function taking an incomplete pointer type "bar".

] struct foo
] {
]     int i;
] }   the_struct;
] 
] main()
] {
]     fun(&the_struct);

    You're passing a complete type, (struct foo *).  Now, in main, the
compiler should know the two are the same, but in fun() it's incomplete:
the type of bar (because it's indeterminate) may be different from that
in fun().  If you cast the call, lint should shut up.

] In case the answers for Standard C and Classic C are different, I'm
] interested in the answer for Classic C.

    Good question.  I'm not sure: my Classic C has slipped.  What was
the stand (if any) on incomplete types?

                                           -- Bill K.

Bill Kaufman,          | "...all conscious species are plastic and
Corporate Lackey       |  all plastic species are conscious."
wkaufman@us.oracle.com |                     -- Yew-Kwang Ng
Newsgroups: comp.lang.c,comp.lang.c++
From: thor@arrakis.denver.co.us (Robert B. Hood)
Subject: Re: Database libs?
Organization: Bob's Programming Paradise, Lakewood, CO, USA
Date: Mon, 7 Sep 1992 03:50:26 GMT

In article <Bu455L.5F9@acsu.buffalo.edu> beers@acsu.buffalo.edu (Andrew Beers) writes:
>
>Are there any C/C++ libraries for manipulating databases?  I'd like to be able
>to create databases with arbitrary records, and at least be able to search
>through then, possibly in an indexed fashion.
>
>I don't normally read this group, so email replies would be most appreciated.
>If I get a number of "me too" responses, I'll summarize through the net.
>

A short time ago, I wrote a C++ class to access and manipulate dBASE III+-
format databases.  I had everything working except the indexing routines -
I had planned on creating a simple sorted, binary-search-like indexing
scheme, but I was given CodeBase 4.5 at work and put my new class aside.

I'd be pleased to post it (it's kinda' lengthy) if anybody is interested.
If I only get a few `me too's, then I'll just send it via mail.

One caveat:  Although I have actually used this class in production code,
it *is* my very first C++ class (a fact that I'm rather proud of), so, although
I've not run into any that I have not fixed, you may find bugs.

Bob
-- 
Bob Hood    thor@arrakis.denver.co.us     H: 303-980-8392  W: 303-632-2180
---------------------------------------------------------------------------
When people are free to do as they please, they usually imitate each other.
Xref: sparky comp.lang.c:13273 comp.std.c:2577
Newsgroups: comp.lang.c,comp.std.c
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: strcpy implementation question
Date: 6 Sep 92 16:13:21 GMT

pinkas@skywalker.intel.com (Israel Pinkas) writes:
>In my book, if evaluating 1+2 launches missles, it would be OK as long as
>(1) the missles did not destroy the currently executing computer, and (2)
>the lack of a missle in the launch bay did not cause the program to abort:)

I think that this is too restrictive.  An analogous requirement would prevent
the implementation of ^C (perhaps it would have to be a non-SIGINT kind, like
"kill -9").  I think that it's fine for the missles to destroy the computer,
and I think it's fine for the lack of a missile in the launch bay to cause the
program to abort.  Anyone want to quote sections of the standard to the
contrary?  If you can, let's see if they can be used as arguments against
implementing ^C.  If so, we're in trouble.
Newsgroups: comp.lang.c
From: atbowler@thinkage.on.ca (Alan Bowler)
Subject: Re: system call in C
Organization: /etc/organization
Date: Mon, 14 Sep 1992 22:45:05 GMT

In article <1992Sep14.170454.13955@kocrsv01.delcoelect.com> c23rrj@kocrsv01.delcoelect.com (Rajnish Joshi) writes:
>
>Help !  If I make a system call (from a C prog.) such as
>
>             system (command);
>
> where 'command' may be a command to compile some program, then how can I
>obtain the process-id of the process which is doing the compile task. The sytem
>call returns only the success code. I need to know the pid of the requested
>command since I want to use it in the C code that follow the system call.

If you are using system() the quick answer is you don't.  If this is
a Unix system, then by the time system() returns to you, the process(es)
invoked by "command" are terminated and have vanished from the system,
so there is not much point in knowing what the process id's were.

For other operating systems, often there is no process involved because
the command is executed by the current process.  The code for the
program is "pushed down" in some manner until the new command has
terminated.  Everything that "command" does runs as the same process
as the parent program.

If you are running under Unix, you may want to look at fork(), and
exec().  Bear in mind that anything you read there is not portable to
other operating systems.
Newsgroups: comp.lang.c
From: eletanjm@nuscc.nus.sg (TAN JIN MENG)
Subject: Re: Only C gurus allowed?!?!
Organization: National University of Singapore
Date: Thu, 10 Sep 1992 01:43:00 GMT

Please stop mailing!!! Too much already... I don't have the time.

Anyway, First I wasn't wrong. My examples were correct, just that
my explanation was murky (my vocab is excellent but my expression
sometimes leaves much to be desired). I later posted a further
explanation anyway. Second, my main complaint is the uncivility of some
people not really the issue of who is allowed to post. I guess I got
carried away when I wrote the original article.


i do not normally read frivolous groups. However, it seems that in this
group more than others, I have to watch what I say - this is implied
censorship in my view (maybe not in yours).

jin meng
Newsgroups: comp.lang.c
From: frank@Cookie.secapl.com (Frank Adams)
Subject: Re: Tool for measuring size (no. of statements) of C/C++ programs
Date: Fri, 11 Sep 1992 20:04:57 GMT
Organization: Security APL, Inc.
Keywords: metrics, size, complexity, comparing versions

In article <1992Sep1.141255.15547@organpipe.uug.arizona.edu> dave@cs.arizona.edu (Dave Schaumann) writes:
>       /* Presumably, no human would write a program with >65536
>	 * statements, but there's also code out there not (directly)
>	 * written by humans.
>	 */
>	unsigned long Statement_Count = 0 ;
>
>	main() {
>
>	  yyparse() ; printf( "%d statements.\n", Statement_Count ) ;
				^
Make that "%ld".
>
>	}


Newsgroups: comp.lang.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: I disagree with lint(1)
Keywords: lint, classic C
Organization: TauMetric Corporation
Date: Mon, 7 Sep 1992 15:16:23 GMT

jos@and.nl (Jos Horsmeier) writes:
[condensed example]
|In article <1992Sep7.083401.2587@sci.kun.nl> hansm@cs.kun.nl (Hans Mulder) writes:
||typedef struct foo *bar;
||
||fun(b) bar b;
||{ b=b; }
||
||struct foo {
||    int i;
||}   the_struct;
||
||main()
||{
||    fun(&the_struct);
||    return 0;
||}
||
|>Lint(1) says:
||fun, arg. 1 used inconsistently	foo.c(5)  ::  foo.c(16)
||I disagree.  The first argument to fun is a pointer to struct foo on both
||lines.  In my book, that's the same.
||What do you all think?

|I think lint is right. The C compiler only does a `shallow type comparison',
|i.e. 

|struct foo {
|	int i;
|};

|struct bar {
|	int i;
|};

If there were two structs like this, they would not be the same type,
but that is not the situation in the original code.  The original
code uses a typedef.  A typedef is a synonym (or alias) for an
existing type; it does not introduce a new type.  Thus "struct foo*"
and "bar" are the SAME type.

Function "fun" is declared to have a parameter of type "bar", which is
to say, "struct foo*".  It is called with the address of an object
of type "struct foo", meaning a value of type "struct foo*".  There
is no inconsistency, and the version of lint is wrong.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c
From: henders@infonode.ingr.com (Greg Henderson)
Subject: Re: EASY C
Organization: Intergraph Corporation, Huntsville, AL.
Date: Fri, 11 Sep 1992 13:59:18 GMT

bosullvn@unix1.tcd.ie (Bryan O'Sullivan) writes:
>There are no pros, only cons.  I have come into contact with
>"profesionally-written" C which uses cpp to make the language look
>like FORTRAN.  This is incredibly annoying, and a serious abuse of
>the preprocessor as far as I'm concerned.  Fortunately, I don't
>have to maintain the crud (only try and understand it, which is
>hard enough), however.

Well put.  I have had to work with 'PASCALized' C, but it only annoyed
me once.  After spending a day w/ editor macroes changing BEGIN back to {, 
ad nauseum, and running the code through cb, I felt much better about it... 

Greg  ;)
-- 

Greg Henderson   henders@infonode.ingr.com   ...uunet!ingr!infonode!henders
From: wright@epx.cis.umn.edu (Mark Wright)
Newsgroups: comp.lang.c
Subject: Re: Memory
Keywords: Borland C
Date: 13 Sep 92 16:54:52 GMT
Organization: University of Minnesota

In article <BuHH37.3BC@news.cso.uiuc.edu> you write:
>
>  I have a rather simple question, I hope. I have the borland c++ compiler
>  ( version 3.0) along with a gateway2000, which has 8meg. I need to 
>  create a rather large data space +600K and I am unable to do it.
>  The old dos 640k problem I suppose... If this is a faq I am sorry but
>  I am just getting rather upset at this problem.....
>  Any help would be appreciated...
>
>   Thank you in advance,
>
>     _paul
>-- 
>-----------------------------------------------------------------------
>|  Log....  Log....  Log.... It is better than bad its Good.... Log!  |
>|    pAul rAdjA   pradja@adsl.ece.uiuc.edu                            |
>-----------------------------------------------------------------------

  Well, the answer to this is simple - you can't do it!  :-)
  Actually, there are a couple of solutions:
1) do you need the data structure in memory at all times - maybe you could
   write some routines to cache the data structure in and out from disk.
   Of course this may result in a DRASTIC reduction in performance.
2) To get around DOS's 1024k memory limit (which is really a 640k limit, since
   the upper 384K is committed to BIOS and screen information and stuff), you
   can buy a dos extender.  Phar Lap's 286 dos extender is around $500.  Yep,
   pretty steep.
3) You can chuck your Borland compiler and use the public domain DJGPP compiler
   which can be found at garbo.uwasa.fi   It has a built in DOS extender, and
   is really an excellent product.  One problem with it is that the dos extender
   is not DMPI complient and your programs will therefore not run under Windows.
   Also, the fact that it is PD may create some hassles for you if you are
   writing programs you want to sell - you can write to DJ about that, his (?)
   address is included in the README file that comes with djgpp.  Plus, it
   is really not all that easy to use.  It's a port of gnu's unix c compiler,
   and has alot of quirks that don't make much sense is the DOS world (for
   example it insists on using '/' as the directory seperator.  I sure hope
   the reason for this was for ease of porting, and not some bone-headed
   reason like 'unix is better')
4) I'm not a windows programmer, but I think that you can create >640k 
   data structures in your windows programs.  Sort of the opposite problem of
   3 - you will only be able to run your programs under windows, which may
   involve some extensive re-writing of your I/O routines, etc...  But, this
   is supported by your current compiler.

Good Luck
-- 
Mark Wright
wright@epx.cis.umn.edu
From: jjwright@remus.rutgers.edu (   Jay)
Newsgroups: comp.lang.c
Subject: HELP: structs and linked lists
Date: 14 Sep 92 15:11:48 GMT
Organization: Rutgers Univ., New Brunswick, N.J.


greetings,
i have a possible simple problem:

i have a header file declaring some structs that are linked lists

ex.	struct grid { float area; struct grid *next;};
	struct ranges {int lat,lon;};

i have a main program which defines/declares the head of the link list

ex.
	struct grid head_list = {-1,NULL}, *head = &head_list;
	struct ranges range = {4,5};

        and i make this function call to build the linked list:

        err = make_list(&head_list,range);

then in my subroutine (these are three seperate files):

	int make_list(struct grid *root,struct ranges range)
	
	i declare struct grid *trav = NULL;

	and i create a linked list:

	trav = root;
	in a look i do this:
	trav->area = 5.0;
	if ((trav->next = add_node(trav->next))==NULL) return -1;
	trav = trav->next;

	i have these two subroutines within this file:
	struct grid *add_node(struct grid *newone)
	which sets newone = t_alloc();
	and returns newone;

	and
	struct grid t_alloc(void)
	{
	return (struct grid *) malloc(sizeof(struct grid));
	}

-------

unfortunately my program is crashing as soon as it gets to the
make_list call in the main program.  when i try to run the debugger it
doesnt tell me anything, instead i get a crash with the "stack
collision with heap" error.  (i only get that error if the debugger is
on, otherwise the screen just freezes).

am i doing all my structure pointers correctly, im new this?  can i
really be running out of room?  i have very few declarations in the
main program or in the make_list routine.  In main i have about 8
files open, but very few other variables, basically just a few
integers.

is there something that i am completely neglecting to do or
overlooking?

thanx.

jay
From: slack@hpdmd48.boi.hp.com (David Slack)
Date: Fri, 11 Sep 1992 00:21:22 GMT
Subject: INVERSE CHARACTORS?
Organization: Hewlett Packard - Boise, ID
Newsgroups: comp.lang.c

hope this works, neophite notes posting attempt!
I am trying to learn to program in C, can anyone direct me to where I
could find out how to print INVERSE charactors?  I am working on a menu
screen in the HP-UNIX invironment and would like to be able to do it 
without using curses and in ANSI-C.  Any help is appreciated.

Much thanks,
Dave
From: karl@ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Tool for measuring size (no. of statements) of C/C++ programs
Keywords: metrics, size, complexity, comparing versions
Date: 11 Sep 92 23:25:36 GMT
Organization: Interactive Systems, Cambridge, MA 02138-5302

In article <1992Sep11.200457.69784@Cookie.secapl.com> frank@Cookie.secapl.com (Frank Adams) writes:
>>	unsigned long Statement_Count = 0 ;
>>	  yyparse() ; printf( "%d statements.\n", Statement_Count ) ;
>Make that "%ld".

Actually, "%lu" is better.
Newsgroups: comp.lang.c
From: scs@adam.mit.edu (Steve Summit)
Subject: Re: sscanf and portability
Organization: none, at the moment
Date: Tue, 15 Sep 1992 00:59:35 GMT

In article <RUJO.92Sep14160231@ulrik.uio.no>, rujo@ulrik.uio.no (Rune J|rgensen) writes:
> If you use types that explisit defines a byte size, e.g.:
> 
> typedef short INT16;
> typedef long  INT32;
> INT16 i16;
> INT32 i32;
> 
> How do you preserve portability with sscanf? E.g:

Mit Schwierigkeit, as they say in Deutschland.

Defining types with precise numbers of bits is a bit of a
perversion on the intent of C's type system, so it is not too
surprising that occasional difficulties like this arise.  When
precisely-sized types are truly necessary, typedefs like the
above are the right way to implement them, but their necessity
should be rare.  (I don't believe I have ever used such a type.)

The traditional need for precisely-sized types arises of course
when people fall into the trap of using "binary" data files or
otherwise attempting to conform to externally-imposed storage
layouts.  Such situations should themselves be much rarer than
they are, further minimizing the occurrence of the problem which
Rune mentions.  Nevertheless, if a program does use precisely-sized
variables to facilitate "binary" I/O, it should have fewer places
where it needs to perform text I/O (scanf/printf) using those
variables.

Obviously, some of the numbers which are read from or written to
a data file must be respectively presented to or requested from
the user, but scanf is a notoriously poor vehicle for interactive
input and should itself be avoided, and printf uses values rather
than pointers such that conservative format-specifiers and
explicit casts solve the problem rather easily:

	printf("%d %ld", (int)i16, (long)i32);

If I were faced with this problem, I'd ask myself carefully
whether I really needed to be using precisely-sized types at all,
and whether I really needed to use scanf.  If both were in fact
absolutely necessary, the solution (using temporary variables and
extra assignments) which Lars Wirzenius has already outlined
would be about the best that could be done.

					Steve Summit
					scs@adam.mit.edu
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.lang.c
Subject: Re: Print #define
Date: 9 Sep 92 17:28:12 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Organization: University of Arizona

In article <1992Sep9.152715.8286@us-es.sel.de>, lisa@us-es (Lisa Goulet) writes:
>In K&R C, is there a way to print a preprocessor variable?
>e.g.  With the following define 
>
>        #define Architecture hp300
>
>      to be able to print the "hp300" part.

If you mean string-izing tokens ala ANSI C's `#' operator, ther is no
portable way to do it.  You could try this:

#define stringize( x ) "x"

Many K&R preprocessors used this as an "undocumented feature" to stringize
tokens.

-- 
Dave Schaumann			dave@cs.arizona.edu
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: Address of static variables??
Keywords: static variables
Date: 11 Sep 92 13:29:17 GMT
Organization: University of Helsinki

ifkm@hippo.ru.ac.za (Andrew Murdoch) writes:
>Is the static variable some_string always guaranteed to have
>the same address?  

During one execution of the program, yes.

>That is, will a_pointer always be a valid
>pointer?  Of course some_function would have to be called first.

As long as it points into the static variable in question, yes.  It can
naturally become invalid if you change it, but that depends on how you
change it ("a_pointer = (char*)1;" will most probably make it invalid).

--
Lars.Wirzenius@helsinki.fi
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: dropping a n from a f
Date: 14 Sep 92 15:00:48 GMT
Distribution: comp
Organization: University of Helsinki

"alan popow" <alan.popow@canrem.com> answers a query about reading lines
from text lines without reading the line-terminating newline with a
suggestion to use the following code:

>     FILE *fp1, *fp2;
>     char *item = "";
>     int i = 0;
>
>     while(((item[i] = fgetc(fp1)) != '\n') && (i < 20))
>         i++;
>
>     item[i] = '\0';

While I realize that this most probably was only meant as a guideline (I
try to point out when I post code like this, myself), but being in a
particularly nitpicky mood, I want to point out some shortcomings of the
code.  This is not intended as a flame, only as constructive criticism.
(I consider any code posted on the Net to be a valid target for such
criticism, and of course all of my articles, especially nitpicking ones
like this.) 

The above code tries to accomplish the same thing as the following:

	fgets(item, 20, fp1)
	...and then get rid of the newline at the end...

However, it does not quite succeed, for two reasons:

1.  The hopefully familiar problem of storing the result of
    fgetc/getc/getchar into a char, not an int, which leads to problems
    with distinguishing EOF from a valid value for a char.  The range of
    the values that fgetc/getc/getchar return is greater than the range
    of values which a char variable can take, so storing the result into
    a char looses information. 

2.  Not checking for EOF.  The program will store garbage values into
    the string if it tries to read past the end of the file.  Please
    remember to check for error codes whenever you can (there a some
    valid places where it is often not necessary to check for error
    codes, but they are rather rare and can be the result of bad
    interface design, e.g.  the return value of printf).  As soon as one
    starts believing that "it can't happen to me", it will. 

Also, since the initialization of the `item' variable looks suspect, I
think I should warn about storage allocation here: there is no code
shown that will allocate memory to hold the string itself, only the
pointer.  Unless you explicitly allocate some storage and set `item' to
point at that storage, you will overwrite things in memory that you
shouldn't overwrite (namely, in this case, the string literal; in the
more usual case, with no initialization, random places in memory will be
overwritten). 

(The initialization seems suspect since it is unnecessary -- there is no
need to make `item' point to a string literal and later make it point to
some other place to which you can store the strings that you read.)

--
Lars.Wirzenius@helsinki.fi
Newsgroups: comp.lang.c
From: wilson@rhombus.cs.jhu.edu (Dwight Wilson)
Subject: Re: Help!!! Please Read this message!?!?!?!?!...
Organization: The Johns Hopkins University CS Department
Date: Thu, 10 Sep 1992 04:06:00 GMT

In article <1992Sep9.085352.8755@vax.oxford.ac.uk> atmtjkv@vax.oxford.ac.uk writes:
>> 
>> If the printf doesn't understand %f, it will print "%f" verbatim and not
>> even attempt to interpret it.
>> 
>> jin meng
>
>Isn't the point rather that oranges is passed as double (vide K&R I p186):
>	`Any actual arguments of type float are converted to double before the call....'

Things are a bit different if using an ANSI compiler.  The promotion
from float to double will be done if a function prototype is not included,
and for trailing arguments if a prototype ending in an ellipsis is
included.  

>so there's a double on the stack.  When printf is called, the format string tells
>it how to interpret the stack frame.  It takes apples off as an int, correctly,
>because of the %d, but it tries to interpret oranges as a float (%f), when in fact
>it has been passed as a double.  So the results will be unpredictable, and will vary from
>compiler to compiler. It is possible that some compilers may trap printfs, and look at
>the format string at compile time, but it isn't required!
>

Huh?  "%f" specifies a double not a float.  If you think about the
promotion rule you'll realize that specifying a float would be
nonsensical since it is not possible for an argument to printf()
to be passed as a float!  

-Dwight
Newsgroups: comp.lang.c