HDTenEightyP/NetNews huggingface dataset:
From: Tony-Preston@cup.portal.com (ANTHONY FRANCIS PRESTON)
Newsgroups: comp.lang.c
Subject: Is there a PD/GNU Lint available?
Date: Fri,  9 Oct 92 08:59:57 PDT
Organization: The Portal System (TM)

The subject askes it all... I am looking for a PD or shareware Lint
program for the Amiga.  Is there a GNU Lint?
Newsgroups: comp.lang.c,comp.os.msdos.programmer,comp.programming
From: prangba@halcyon.com (Bruce Prang)
Subject: FAQ: Book for learning C.
Organization: Northwest Nexus Inc. (206) 455-3505
Date: Thu, 8 Oct 1992 21:28:58 GMT

I have a friend that is in the proceses of learning C. He is using an
MS-DOS box to learn but he will be doing some of the programming on a
Unix (AT&T SysV) box. He asked me for a recomandation but I didn't use a
book in learning so I couldn't help him. How bout any of you fine folks?

The book would ideally teach ANSI C with notes of perhaps how some of
the MS-DOS compilers (MS, Borland, Zortech) differ. He's not looking for
reference book, he has one of those. More of a real life kinda thing.
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.lang.c
Subject: Re: Typedefs or structs [was Re: Incomplete structure declarations: only within structs?]
Date: 12 Oct 92 14:53:36 GMT
Organization: AND Software BV Rotterdam

In article <FARRELL.92Oct9130541@fjord.reo.dec.com> farrell@fjord.reo.dec.com (John M. Farrell) writes:
|>>>>> On 8 Oct 92 17:44:25 GMT, scs@adam.mit.edu (Steve Summit) said:
|Steve> I'm not sure why people are so eager to define typedefs for structs.
|Steve> It is, I suppose, a pattern followed by many textbook authors, and it
|Steve> is also done automatically for you in C++.  However, if you insist on
|Steve> defining typedefs for structures, you can run into several problems.
|
|This supports the view that I am beginning to hold, that typedefs are not 
|sufficiently well integrated with the rest of C to make them as usable as
|plain old structs.
|
|Do poeple agree that this is so, or is there some way to get around the
|problem of incompleteley defined typedefs?

My personal opinion is that typedefs _can_ increase the readability of
a program, but I have to agree with Steve Summit, that they don't buy
you much when applied to structures. It only saves you the word `struct'.

On the other hand, have a look at the `signal' function prototype:

void (*signal(int, void (*)(int)))(int);

I hate such prototypes, they look more like LISP to me, than proper C.
See what a simple typedef could do to it:

typedef void (*sfunc_t)(int);

sfunc_t signal(int, sfunc_t);

I like this one much more, thanks to that single typedef. BTW, this
is just an example, I don't want to introduce a new sort of signal
prototype, it's just that it looks so ugly the way it looks now, that's
why I took this one ...

BTW, there are two things I didn't understand when I read the posting
above. Concerning Steve Summits' remark: how can one run into trouble 
when one uses typedefs for structures? I can't see anything wrong with 
them. Like I said, it doesn't buy you much, but what's the danger of
doing so? The other question concerns the remark made by John M. Farrell:
what's wrong with the level of `integration' of typedefs in the C 
language? How can they be more integrated than they are now? 

kind regards,

Jos aka jos@and.nl

Newsgroups: comp.lang.c
From: wilson@rhombus.cs.jhu.edu (Dwight Wilson)
Subject: Re: Question about fread() and fwrite()!
Organization: The Johns Hopkins University CS Department
Date: Fri, 16 Oct 1992 16:12:58 GMT

In article <chupchup.719226774@piggy> chupchup@ferkel.ucsb.edu (Robert Earl) writes:
>
>| Another question is: Is the size of a structure the summation of all
>| the size of its elements? If not, any formula for it beside using
>| sizeof()?
>
>Yes, it is the sum of all the elements' sizes.

This is implementation dependent.  Some architectures may require 
specific alignment of different data types, and on others alignment
may affect performance.  The compiler may insert gaps between struct
fields to enforce alignment.  Consider the structure:

struct test {
   char a;
   int  b;
};

If sizeof(int) = 4, there are at least three reasonable possibilities
for sizeof(struct test): 5 (no alignment restrictions), 6 (ints
must be located at even addresses), and 8 (ints must be word aligned).

-Dwight

Newsgroups: comp.lang.c,comp.software-eng,comp.sys.mac.programmer
From: may@hpcesma.ce.hp.com (Elaine May)
Subject: Re: Productivity of a C programmer ?
Reply-To: may@hpcesma.ce.hp.com
Organization: HP Corporate Engineering - Palo Alto, CA
X-Newsreader: TIN [version 1.1.4 PL6]
Date: Sat, 17 Oct 1992 01:19:31 GMT

I think the other good estimation practice is to keep track of your actual
progress vs. your estimation.  You must be able to do this accurately -- i.e.
have tangible deliverables that can be inspected or examined to make sure
you're not fooling yourself.  Measure your actual rate of progress against
your expected rate and adjust the estimates accordingly.  

--
Elaine May                               Hewlett-Packard Corporate Engineering
may@hpcesma.ce.hp.com		         Palo Alto, California
Xref: sparky comp.lang.c:15035 comp.lang.c++:15030
From: kestes@nswc-wo.nswc.navy.mil (Kent Estes)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: format/source needed for Microsoft C databases...
Keywords: Microsoft C
Date: 15 Oct 92 17:48:31 GMT
Organization: Naval Surface Warfare Center


Can anyone help me find the format of the language database
that the newer Microsoft C compilers create ?  Perferably an
ftp site would be nice, but I'll take 'bout anything.

tnx kl (kestes@nswc-wo.navy.mil)
From: gordo@phsbbs.princeton.nj.us (Gordon Davidescu)
Newsgroups: comp.lang.c
Subject: .Gif files
Date: 12 Oct 92 11:59:35 GMT
Organization: Princeton High School, Princeton, New Jersey

In Borland  C++, I am trying to include a picture file of any sort at the 
beginning.  Does anybody know how one could accomplish this?
(The code would help)

-----
Gordon Davidescu, Princeton High School BBS
DNS: gordo@phsbbs.princeton.nj.us      UUCP: ...!princeton!phsbbs!gordo
Disclaimer: Author bears full responsibility for this message.
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.lang.c
Subject: Re: Strings and integer sizes
Date: 15 Oct 92 20:48:41 GMT

In article <442@ulogic.UUCP>, hartman@ulogic.UUCP (Richard M. Hartman) writes:
> The char array initializations discussed in K&R1 all seem to
> be of the '[]' type (size unspecified), so it is possible that
> compilers that accepted this initializer did not violate K&R
> _except_ for the fact that the size of a string constant is
> clearly established on p84 (excerpted above).
> 
> I can understand the convenience argument (although I disagree
> on the grounds that it is misleading as to the intended use of
> the variable so initialized).  But I am not convinced that compliers
> that accepted it (prior to the ANSI spec) were _not_ in violation
> of K&R.
> 
> Am I missing something?

Yes, that K&R is not a language specification; rather, it's a mixture
of a tutorial, a language specification, and documentation of a
particular set of implementations, with no indication of what parts are
what.  In particular, most of the book is tutorial and hence contains
incomplete and at times even misleading statements in order to keep the
tutorial simple.  Only the appendix which contains the C Language
Reference Manual is appropriately considered a language specification
and even that contains implementation documentation as well (not to
mention an error or two -- despite some people's ideas to the contrary,
K&R are only human).

As near as I can tell, K&R never says clearly one way or the other. 
Since the library does contain functions which work on non-null
terminated strings (e.g. strncpy and strncmp), some implementors decided
that it should be possible to initialize them with a string literal just
like normal strings.  Whether Ritchie's compiler was one that allowed
this or not, I don't know; but one place that uses them is the Unix file
system, so I wouldn't be surprised if it did.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
Domain: lawrence.jones@sdrc.com               IBMMAIL: USSDR7DR at IBMMAIL
See if we can sell Mom and Dad into slavery for a star cruiser. -- Calvin
Newsgroups: comp.lang.c
From: byron@cc.gatech.edu (Byron A Jeff)
Subject: Re: Returning an array from a function -> How to?
Reply-To: byron@cc.gatech.edu (Byron A Jeff)
Organization: Georgia Institute of Technology
Date: Thu, 15 Oct 1992 15:32:45 GMT

In article <5987@ucsbcsl.ucsb.edu> 6500msd@ucsbuxa.ucsb.edu (Michael D'Errico) writes:
>In article <runeh.65.718760603@dhhalden.no> runeh@dhhalden.no (RUNE HALFDAN HOLST HUSEBY) writes:
>
>  ]In article <BvxErG.MCA@news.cso.uiuc.edu> msr52148@uxa.cso.uiuc.edu (Shepard) writes:
>  ] ]
>  ] ]I am fairly new to C, and I want to write a function that returns an array. 
>  ] ]I would like to avoid passing in pointer to an empty array and modifying it
>  ] ]that way.  I need one function that generates a table of integers dependent
>  ] ]on an string/array of characters which is passed in as an argument.  I've 
>
>  ]Try this:
>
>  ]int maketable(char *string)
>
>This should be
>int *maketable(char *string)
>
>  ]{
>  ]  int *table;
>  ]
>  ]  /* you need the create space on the global heap */
>  ]  table = (int *) malloc(size_of_array * sizeof(int));
>  ]  if(table == NULL)
>  ]  {
>  ]  /* an error has occured */
>  ]    return ERROR
>  ]  }
>  ]  .
>  ]  .
>  ]  .
>  ]  return table;
>  ]}

No one has yet suggested using a static array in maketable:

int *maketable(char *string)
{
   static int table[xxx];
  
   /* Code to fill table */
   return table;
}

main()
{
   int *mytable;

   mytable = maketable("A string");
}

Because of the static declaration the space for table in function maketable
is permanently allocated. It is almost like a global varaible except it's
scope (visibility) is limited to function maketable. No memory to allocate
or free. This seems to be closer to what the original poster intended.

However there is a caveat. Unlike the malloc example if you call maketable
more than one you will not get multiple tables. Each call will overwrite
the previous values of variable table with the new computed values.

Hope this helps,

BAJ
---
Another random extraction from the mental bit stream of...
Byron A. Jeff - PhD student operating in parallel!
Georgia Tech, Atlanta GA 30332   Internet: byron@cc.gatech.edu
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Strings and integer sizes
Date: 12 Oct 92 21:33:24 GMT
Organization: negligable

In article <3578@dozo.and.nl: jos@and.nl (Jos Horsmeier) writes:
:Let me be a bit more precise: it is _not_ an erroneous initializer for
:a character array. It is _not_ a valid initializer if you want to store
:a string in this array, because the terminating '\0' byte is not stored.
:Character arrays can be used for other things than just strings. 
:
:I agree when you say that zoe[3]= "abc"; is an erroneous initializer
:when you want to store a _string_ in the array, but otherwise this
:is all perfectly legal. The ANSI-C standard even states this explicitely
:in paragraph 3.5.7 Initialization.


Unfortunately this is correct.  Stupid and misleading, but correct.

Another thing we can thank the standards committee for....

		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Who knows what evil lurks in the hearts of men?"
From: pdomain@emory.edu (Mike Mitten)
Newsgroups: comp.lang.c
Subject: Lookup table location
Date: 13 Oct 92 13:51:57 GMT
Organization: Emory University, Atlanta, GA
X-Newsreader: TIN [version 1.1 PL6]

Say we have the following function, in its own file:

char *dayname(int day)
{
static char *days[] =
     {
       "Monday",
       "Tuesday",
       "Wednesday",
       "Thursday",
       "Friday",
       "Saturday",
       "Sunday"
     }

  if (day < 1 || day > 7)
	return "";

  return days[day - 1];

}

Is there going to be any difference between putting the array
'days' insided or outside the function?  Obviously we don't want
the array name polluting the user's name space, nor do we want the
user to be writing through the pointer they are returned (though I
don't know that there's anything to be done about this in C).

It seems to me that the location of the definition of 'days' won't
make any difference, but I'd like to be sure.

  Thanks,

        -Mike

Mike Mitten - pdomain@emory.edu - Irony is the spice of life. - DoD#522
I do not speak for Emory University, nor for Public Domain, Inc.
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: How does free() work ?
Date: 12 Oct 92 23:55:33 GMT
Organization: negligable

please excuse the ts=4 tab setting in the previous reply.
and I know that "female_friend()" should have been just 
"female_friends".
Newsgroups: comp.lang.c
From: mjn@pseudo.uucp (Murray Nesbitt)
Subject: Re: No typedef
Organization: Private system in Toronto, ON
Date: Thu, 15 Oct 1992 08:20:47 GMT
	<1992Oct12.170330.18233@blaze.cs.jhu.edu>


wilson@rhombus.cs.jhu.edu (Dwight Wilson) writes:

>In article <1992Oct11.192657.7275@waggen.twuug.com> alpha@waggen.twuug.com (Joe Wright) writes:
>>My C compiler does not support typedef.  I emulate typedef like this:
>>
>>#define nutyp struct nutyp
>>	nutyp {
>>		int ID;
>>		char Name[32];
>>	};
>>
>>	nutyp Person, *PersPtr;
>>
>>Is this 'as good as' a real typedef?  It seems to work here.
>
>Dave Schaumann has already mentioned the problem with typedef'ing
>arrays.  There is also a subtle difference between typedef and
>#define that arises with 'const'.  Consider:

Consider the following:

    typedef char nutyp;
    struct nutyp { int nutyp; };

This is kosher.  But when we

    #define nutyp char
    struct nutyp { int nutyp; };

things could get ugly.

-- 
Murray
Newsgroups: comp.lang.c
From: williford@lub001.lamar.edu
Subject: NEEDED: CRC-32 or 16 source.....
Organization: Lamar University - Beaumont
Date: Sat, 10 Oct 1992 17:46:21 GMT
X-Posted-From: lub001.lamar.edu
NNTP-Posting-Host: sol.ctr.columbia.edu

I am looking for a simple program using CRC-32 and a program using CRC-16.
Please respond by e-mail.  I posted this for a friend so I don't know any other
details about what is needed.

T.I.A.  (Thanks In Advance)

*****************************************************************************
Rhett Williford
Systems Operator
ACM President-Lamar University, Beaumont, TX  USA
Internet: williford@lub001.lamar.edu
*****************************************************************************

Newsgroups: comp.lang.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: question about duplicate declarations
Organization: TauMetric Corporation
Date: Fri, 16 Oct 1992 16:50:30 GMT

amorgan@csd-d-3.Stanford.EDU (Crunchy Frog) writes:

!In article <1992Oct13.211753.15516@phri.nyu.edu> 
!  roy@mchip00.med.nyu.edu (Roy Smith) writes:
!>
!>foo (int x)
!>{
!>	int x;
!>
!>	...
!>}
!>
!>What should you expect a compiler to do?  

>Exactly what it did.  Compile without error.

No.  The parameters in a prototype-style function header are in the
same scope as the outermost block of the function.  This code is
not legal, and a compiler should complain.

Since this code can't be compiled with an old-style compiler,
we don't have to get into variations in old-style C rules.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c
From: jimh@pacdata.com (Jim Harkins)
Subject: Talking to hardware
Organization: Pacific Data Products
Date: Wed, 14 Oct 1992 00:27:43 GMT

So, how do y'all talk to registers in chips?  I've written several drivers and
have yet to come up with one 'good' way to do things.  Most of what I do
tends to be compiler dependant (need I point out it's also hardware dependant,
but that thats the point?).  There seems to be a real tradeoff between
convienance, readability, and portability.

Some of the things I've done include building a bitfield to define the
registers, building a struct, and using macros.  My favorite is to typedef
a struct, then set a pointer to the struct to be the base of the chip.
For example (off the top of my head, haven't actually compiled this)

typedef struct {
	uchar	command,
		intrups,
		intrup_mask,
		dma_0,
		dma_1,
		dma_2,
		dma_3,
		count_0,
		count_1
} chip_t;

#define CHIP_ADDRESS	0x1234

chip_t *chip;

void
chip_init()
{
	chip = (chip_t *) CHIP_ADDRESS;

	chip->command = STOP | PAGE_0 | OFF_LINE;

	etc etc
}

The obvious problem with this is my compiler may or may not pack the chars
in the struct next to each other and in the right order.  If it does then a
future release may not do so.  However, this is the method I've pretty much
gravitated to.  I can always set compiler flags or fart around with the chip_t
typedef to pack the chars together *for that particular compiler*.

So, any comments?

jim

	
-- 
One of the great ironies of our time is that voters with brains are
greatly outnumbered by voters without brains, yet somehow the
intelligent fail to perceive that not everybody thinks the way they do,
thus they fail to argue persuasively for their points and then are
surprised when the majority makes dumb choices.

--------------------------------------------------------------
Jim Harkins                         [ucsd|uunet]!pacdata!jim
Pacific Data Products               jim@pacdata.com
--------------------------------------------------------------

Newsgroups: comp.lang.c
From: sphillip01@cc.curtin.edu.au
Subject: Turbo Pascal to C converter needed
Organization: Curtin University of Technology
Date: Tue, 13 Oct 1992 11:21:22 GMT

Does anyone have or know of a working Turbo Pascal to Turbo C converter ? I 
started writing a program in Pascal ages ago, & am now a C programmer, & want 
to finish/modify it ... The converter would need to understand non-basic 
techniques such as graphics, overlays and interrupts as well ... Any help would 
be most appreciated. Thanx in advance ...

Trevor Phillips

+-------------------------------------------------------+----------------------+
| Internet: SPHILLIPS10@cc.curtin.edu.au                | Curtin University of |
|           SPHILLIP01@cc.curtin.edu.au                 |      Technology      |
| Bitnet: SPHILLIPS10%cc.curtin.edu.au@cunyvm.bitnet    |                      |
| UUCP  : uunet!munnari.oz!cc.curtin.edu.au!SPHILLIPS10 |    Trevor Phillips   |
+-------------------------------------------------------+----------------------+
| "... and thank you for bringing up such a painful subject. While you're at   |
| it, why don't you give me a paper cut and pour lemon juice on it ..."        |
|                             - Miracle Max, from The Princess Bride           |
+------------------------------------------------------------------------------+

Newsgroups: comp.lang.c
From: scs@adam.mit.edu (Steve Summit)
Subject: Re: Algorithm for Day-Of-Week NEEDED
Organization: none, at the moment
Date: Wed, 7 Oct 1992 06:02:12 GMT

Sorry to dredge this old thread up again, but there was one point
I wanted to make.

In article <1992Sep25.221833.10476@ima.isc.com>, Karl Heuer (karl@ima.isc.com) writes:
> A side effect is that the Julian
> calendar rule (test only year%4) agrees with the Gregorian for the entire
> interval [1901,2099], and hence is good enough for applications that already
> depend on the common implementation of time_t.

This simplification was worthwhile when the number of C and Unix
installations was smaller, and the "common implementation of
time_t" was universal, and the address space tended to be 64k.
As time goes on, however, it's more and more likely that some
systems' time_t's will accommodate dates past 2099, so it's
probably worth coding the correct algorithm.

					Steve Summit
					scs@adam.mit.edu
Newsgroups: comp.lang.c
From: berlin@is.morgan.com (Alexander Berlin)
Subject: Re: Strings and integer sizes
Organization: Morgan Stanley - IS
Date: Fri, 9 Oct 1992 18:17:54 GMT

In article <1992Oct9.075710.13377@klaava.Helsinki.FI>, wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes:
|> hartman@ulogic.UUCP (Richard M. Hartman) writes:
|> >I have this in a central include file as:
|> >	strncpyz(d,s,n) { strcpy(d,s,n); d[n] = '\0'; }
|> 
|> Is n the size of the destination or the maximum length of the target
|> string, i.e. destination size - 1 ?  If the former, then the last
|> assignment should be d[n-1]='\0', of course.
|> 
|> I think that usual C convention would be to specify the destination size
|> (since then you can use sizeof if that is convenient for you), not
|> maximum string length.  Examples include strncpy, mem*, and fgets.
|> 
|> >I think there's a memcpyz() to go w/ memcpy(), but I'm not sure....
|> 
|> Seems curious, since the mem* functions shouldn't care about null
|> characters.
|> 
I have one more question to Mr.Hartman:

    What is the purpose of having the third argument when calling strcpy
    in your "central include file"?

As far as my poor knowledge goes, strcpy won't make use of it.
Oh... maybe it's just another exersize for the readers of this group.
I agree with Lars - you are not the only caretaker here. You are free to
skip a few discussion threads and do some C-studies.

-- 
Alex Berlin                     
berlin@is.morgan.com
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Strings and integer sizes
Date: 12 Oct 92 21:41:13 GMT
Organization: negligable

You're right.  According to the standard (which I misread) this
initializer *is* valid.

It is misleading, but valid.

If you truly intend an array of char instead of a string
you should (as a matter of good programming practice) provide
the appropriate initializer "= { 'a', 'b', 'c'};" to make the
intended usage clear.

However, the ANSI committee in their wisdom has allowed this
misleading syntax of initializing a char array w/ a string
constant.

I guess we'll have to learn to live with it.


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lovely to see you again my friend,		|
walk along with me to the next bend.		|	-Richard Hartman	
Tell us what you've seen			|	hartman@uLogic.COM
in far away forgotten lands,			|
Where embers have turned back to sand.		|
Newsgroups: comp.lang.c
From: pal@regent.e-technik.tu-muenchen.dbp.de (Peter Loibl)
Subject: Re: How does free() work ?
Organization: Technical University of Munich, Germany
Date: Thu, 15 Oct 1992 15:52:06 GMT

kdq@quest.UUCP (Kevin D. Quitt) writes:

>    Actually, trying to free NULL usually doesn't hurt.  Most of the
>libraries I looked into check for NULL before they try to free the
>memory: no harm, no foul.  I'm not sure I'd count on it if portability
>were one of my goals, since I'm pretty sure this isn't actually
>mandated behaviour,

I am working on a Hypercube iPSC/860 and you will end up with a
crash, if you try to free a NULL-pointer. An unset pointer does not need
be a NULL pointer. It is pretty likely (on the iPSC/860) that it points
whereever it likes to (e.g. to the address 4).

Peter Loibl
pal@regent.e-technik.tu-muenchen.de
Newsgroups: comp.lang.c
From: pjh@mccc.edu (Pete Holsberg)
Subject: Re: Strings and integer sizes
Organization: The College On The Other Side Of Route One
Date: Sat, 10 Oct 1992 18:08:15 GMT

In article <qkXDsB1w165w@quest.UUCP> srhqla!quest!kdq writes:
=    The subtlety here is the difference between a array of characters
=and a string.  One is null terminated, the other need not be, and can
=contain nulls as part of its content.  A string in C is stored in an
=array of characters, but is logically a different entity.

And that, if you recall it, was the raison d'etre for the original
question. A string is not the same thing as an array of chars, no matter
how many C gurus call "char foo[20]" a string in everyday conversation.

Newsgroups: comp.lang.c