HDTenEightyP/NetNews huggingface dataset:
From: elias@proxxi.se (Elias M}rtensson (proxxi))
Subject: Re: Functions Within Functions
Organization: proxxi
Date: Thu, 30 Jul 1992 00:48:28 GMT

amorgan@Xenon.Stanford.EDU (Crunchy Frog) writes:

>In article <Bs5w39.5ox@news.larc.nasa.gov> 
>  wjb@cscsun2.larc.nasa.gov (William J. Bene) writes:

>>Is there any way to declare functions within another function like in pascal?

>Not according to ANSI C.  GCC 2.x allows you to do it so you can use
>that (beware, it is still fairly buggy).  BTW - Why do you want to
>do this?  Occasionally I imagine it might be useful for encapsulating
>code, but if a function is used in only one place I make it static
>and avoid the problem that way (and have portable code). 

Well, there ARE occations one might want to have encapsulated functions.
If You make a library which uses lots of functions, there might be
function name collisions, since You can have several encapsulated
functions with the same name, You won't have these problems.

Example:

main()
{
	foo();
	bar();
}

foo()
{
	int abcd( int a )    { return a + 10; }

	/* Do some things which uses the local function "abcd" */
}

bar()
{
	int abcd( int a )    { return a + 20; }

	/* Do some other things with this new local function "abcd" */
}


>C Frog

###################
# Elias Martenson #
# elias@proxxi.se #
###################
Newsgroups: comp.lang.c
From: mjs@hubcap.clemson.edu (M. J. Saltzman)
Subject: Re: Pointers outside of array boundary
Organization: Clemson University, Clemson SC
Date: Wed, 29 Jul 1992 15:15:18 GMT

In article <mjd.712419017@hal> mjd@hal.gnu.ai.mit.edu (Sievan Janacziewski) writes:
>mjs@hubcap.clemson.edu (M. J. Saltzman) writes:
>>[about 1-based indexing]
>
>I was going to make up some thing about how maybe the array gets
>allocated at the top of memory, but there's a much better reason not to
>do this: C arrays always start at 0, never at 1, and by resorting to
>cute compiler hacks to fudge up the appearance of a 1-based array, one
>will only confuse oneself and other people who have to read,
>understand, maintain, and modify the code.
>
>If 0-based arrays are unclear to your correspondent, then he or she
>should practice more, so that they become more familiar, rather than
>resorting to obfuscation to cover his or her inadequacies as a programmer.
>
>This has nothing to do with legalism. 
>It is the most practical of all possible considerations.

While I agree with this sentiment in general, I also have been faced
with the problem of implementing complicated combinatorial algorithms
from specifications that describe the algorithms using a 1-based
indexing scheme.  From a purely aesthetic point of view, re-expressing
the alogirthms to use 0-based indexing *clearly and correctly* seems
like a worthwhile goal, but practical considerations (like having to
get the work done) often take priority, and kluges to fixup the
results of index calculations often serve to obfuscate the code and
introduce bugs.  In this case, wasting the 0th element of an array
seems like a relatively small price to pay, if that's the only way 
to write 1-based code.

>
>Sievan Janacziewski
>mjd@gnu.ai.mit.edu


-- 
		Matthew Saltzman
		Clemson University Math Sciences
		mjs@clemson.edu
From: jaws@brazos.cray.com
Newsgroups: comp.lang.c
Date: 17 Jul 92 17:58 MDT
Subject: Re: Advanced C CLASS ?
Nf-ID: #R:1992Jul15.134530.14088@walter.cr:-1402620328:1992Jul17.085836.5049@walter.cra:1096458745:001:1127
Nf-From: brazos.cray.com!jaws    Jul 17 17:58:00 1992


In article <1189@uknet.ac.uk>, tlg@uknet.ac.uk (Tim.Goodwin) writes:
|> In article <1992Jul15.134530.14088@walter.cray.com> jaws@cray.com (Jim Wheeler) writes:
|> >   What would you teach in an Advanced C class?  What would you expect of
|> > such a class, if you were a student?
|> >   I have been teaching C for nearly ten years now. Occasionally I am asked
|> > for an Advanced C class. This has always puzzled me.  I believe that the
|> > Introduction to C class should cover the full syntax, from identifier
|> > name sizes and restrictions through structures, unions, bit-fields,
|> > pointers, pointers to ...  etc. 
|> >...
|> 
|> Maybe if
|> 
|> 	Introduction to C == K&R
|> 
|> then
|> 
|> 	Advanced C == C Traps and Pitfalls
|> 
|> ?
|> 
|> Tim.
|> -- 
|> The GNU is in fact the legendary and much-berated | ; who am i
|> feeping creature - Malcolm Wallace.               | uknet.ac.uk!tlg

-- 
 J.A. Wheeler           (jim.wheeler@cray.com) 
          CRAY Research, Inc.
 5 Post Oak Park        (800)-283-8998
 suite 1960             (713)-968-1619  FAX
 Houston, TX. 77027      
 ++++++++++++++++++++++++++++++++
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.c
Subject: Re: Pointers to freed memory
Date: 31 Jul 1992 15:43:34 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <3185@dozo.and.nl> jos@and.nl (Jos Horsmeier) writes:
>I never could have 
>imagined a processor architecture where a validation on an address
>value would be done while just _loading_ that particular value. But
>such (ugly) animals seem to exist; I've never had the `pleasure'
>to meet one ...

I remember this coming up when we were considering porting Multics to a
(then) new Honeywell process (I think it was the DPS/88).  Multics uses
several invalid segments for various purposes; for instance, anything in
segment -1 is a null pointer.  Previous generations of hardware would trap
when dereferencing through such pointers, which is just what we wanted.
The new hardware trapped when loading addresses into pointer registers,
thus making our normal mechanism for loading null pointers invalid.  The
hardware designers probably thought they were doing a Good Thing by
checking pointers earlier on (I suppose it helps you find out where the
invalid pointer came from), but they never realized that some of us were
using invalid pointers for special purposes (I think we also expected to
run into some problems porting Lisp to this machine, since it stored its
tag fields in unused bits in pointer representations, and the new machine
may have checked that those were always 0).

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.lang.c
From: elias@proxxi.se (Elias M}rtensson (proxxi))
Subject: Re: Functions Within Functions
Organization: proxxi
Date: Thu, 30 Jul 1992 00:54:17 GMT

>int foo()
>{
>	int bar( int a ) { return a + 20; }

>	printf( bar( 10 ) );
>}

I am propaly going to get flames for this, but i just had to correct
my embarrasing mistake:

Line 5 should read:
printf( "%d\n", bar( 10 ) );

Sorry for wasting bandwidth. It's not going to happen again.

###################
# Elias Martenson #
# elias@proxxi.se #
###################
From: css1rs@valar.ee.surrey.ac.uk (Russell Smithers)
Newsgroups: comp.lang.c
Subject: undefined type (structure)
Date: 31 Jul 92 12:09:48 GMT
Organization: University of Surrey, Guildford, Surrey, UK. GU2 5XH
X-Newsreader: Tin 1.1 PL4

I have posted this allready in comp.unix.programmers, but no one
has replied or posted, so I thought i'd ask here :

Basicly im using GCC v1.4 and the compiler gives me this error :

<I am boromir> make
gcc -g -DSUN -ansi  -target sun4 -c  manage.c
manage.c: In function add_group:
manage.c:38: invalid use of undefined type `struct group_buff'
manage.c:39: invalid use of undefined type `struct group_buff'
*** Error code 1
make: Fatal error: Command failed for target `manage.o'

The structure in question has previously been defined as global
and has been mad extern in all source files, this is the chunk of
code I get the error on :

    34  add_group()
    35  {
    36          int ok=1;
    37
    38          pretty_string(group_buffer.Group_Name);
    39          ok=group_exists(group_buffer.Group_Name);
    40

Any help on this is greatly apprecited, if ive missed something
basic then I would realy appreciate it fully or partly explained.

Thanks netters.
Newsgroups: comp.lang.c
From: briggs@progress.COM (Scott Briggs)
Subject: Re: Concatenation of two macros?
Organization: Progress Software Corp.
Date: Thu, 23 Jul 1992 15:23:18 GMT

KOSU_MATSB@ROUTH.KOSUFY.LU.SE writes:


>	Concatenation of two macros. Is it possible?

>	If i have the following two definitions:
>		#define A pre
>		#define B post
>	And want to "#define C" to be  "prepost" BUT as an 
>	expression of A and B! How do i do it?
>	#define C (expression of A and B to yield prepost)

Depending on the compiler one of the following should work:

#define C A##B

  or

#define C A/**/B


Scott.
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.lang.c
Subject: Re: Loop structures
Date: 24 Jul 92 22:39:50 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Organization: University of Arizona

In article <1992Jul24.003402.9071@unixg.ubc.ca>, lermer@theory (Noah Lermer) writes:
>Solution iii)
>
>do {
>    ... get input ...
>    if (valid)
>        break;
>    showerror();
>} while(1);
>
>This is the solution I like the most

I agree.  It's worth noting that C just isn't very good at exception handling,
and any time you try to deal with it, you're likely to get some wierd code.


>but has the disadvantage (like i) that
>multiple error conditions are not handled easily.


I think if you have several error conditions, this would be better:

  get_input:
  ... get input ...

  if( one_kind_of_error()
    { complain() ; goto get_input ; }

  if( another_kind_of_error() )
    { complain() ; goto get_input ; }

  /* etc. */

This method is really just first cousin to methods that use setjmp/longjmp
for error recovery.  I think you'll find that except for the simplest of
input validation, this or setjmp/longjmp is the best way to go.

-- 
You unlock this door with the key of imagination.  Beyond it is another
dimension: a dimension if sound, a dimension of sight, a dimension of mind.
You're moving into a land of both shadow and substance, of things and ideas.
You've just crossed over into... the Twilight Zone.
Newsgroups: comp.lang.c
From: gurgle@netcom.com (Pete Gontier)
Subject: Re: Variable length records
Date: Mon, 27 Jul 92 20:15:53 GMT
Organization: cellular

>gurgle@netcom.com (Pete Gontier) writes:
>> typedef struct
>> {
>>    short   count;
>>    float   data[ ];
>> }
>> foo;

wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes:
>	typedef struct {
>		short count;
>		float data[1];
>	} foo;

This works just fine, but then your code has to know that there is
a special case when figuring the size for the record with n data
members; namely, the case where there are no data members but there
is really space for one. Not a big deal, just not as clean conceptually.

>	typedef struct {
>		short count;
>		float *data;
>	} foo;

Well, of course it is the case that this works, but doing one
allocation is always easier to debug. And, in my view, integrating
the array with the struct is easier to understand.

>Actually, I don't think any special compiler cooperation is required. 
>To output the last version above to a file you do...

Ah yes, but when I said "cooperation" I was referring to the first
method above, not the last.
-- 
 Pete Gontier // EC Technology // gurgle@netcom.com
Newsgroups: comp.lang.c
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Curious bug...
Organization: Computer Science, University of Melbourne, Australia
Date: Sat, 25 Jul 1992 16:11:15 GMT

oklein@smallo.bo.open.de (Olaf Klein) writes:
>I don't know the scope of a short in Quick-C, but if it's really
>8-bits, which I could believe under DOS, then you loose the high
>(attribute) byte of menu[][], but get the char after the actual as the
>attribute char.

No, short is guaranteed to be at least 16 bits (or rather is guaranteed
to have the equivalent range - it *could* be represented in bcd :-).

>Bye, Olaf
>
>PS. I don't think, that this program style is very portable, and the
>exit code doesn't match the errno-code, 2 (ENOENT) should be appropriate...

Yes, I agree, the coding style was pretty horrific.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature VIRUS is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe)
Newsgroups: comp.lang.c
Subject: Re: Concatenation of two macros?
Date: 23 Jul 92 20:33:28 GMT
Reply-To: volpe@ausable.crd.ge.com
Organization: GE Corporate Research & Development

In article <1992Jul23.152318.8369@progress.com>, briggs@progress.COM (Scott Briggs) writes:
|> KOSU_MATSB@ROUTH.KOSUFY.LU.SE writes:
|> 
|> 
|> >	Concatenation of two macros. Is it possible?
|> 
|> >	If i have the following two definitions:
|> >		#define A pre
|> >		#define B post
|> >	And want to "#define C" to be  "prepost" BUT as an 
|> >	expression of A and B! How do i do it?
|> >	#define C (expression of A and B to yield prepost)
|> 
|> Depending on the compiler one of the following should work:
|> 
|> #define C A##B

On what broken compiler does the above not yield "AB"???

|> 
|>   or
|> 
|> #define C A/**/B

I believe most pre-ANSI compilers will yield "AB" for that too.

And if you're interested in a solution that actually works on ANSI
conforming compilers, try the following:

#define A pre
#define B post
#define CATX(x,y) x ## y
#define CAT(x,y) CATX(x,y)
#define C CAT(A,B)


-- 
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
Newsgroups: comp.lang.c
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: About the 'F' in RTFM
Organization: Texas Instruments Inc
Date: Thu, 30 Jul 1992 16:23:39 GMT

In <4160@news.duke.edu> bigham@acpub.duke.edu (Scott Bigham) writes:

>From the Holy Book of <1992Jul26.190928.20817@mksol.dseg.ti.com>
>  as spake by mccall@mksol.dseg.ti.com (fred j mccall 575-3539) :

>>In <1992Jul23.155203.11430@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:

>>>The usual interpretation of the F is an accurate description of the quality
>>>of most UNIX manuals.  The correct response to `RTFM' is "I *did* read it,
>>>and it didn't answer the question I wanted answered."

>>At which point, of course, you reach up, pull down the appropriate 
>>manual, open it up, drop it in front of them and point.  They then
>>say, "Oh," and walk away looking sheeplike.

>Yeah, if they're sheep.  My usual response at this point is, "Yes, I
>read that, and it doesn't answer my question.  I also read the next
>three manuals on your shelf and they don't answer my question either.
>If they did, I wouldn't be here asking you, now would I?"

Yes, but people who have questions which actually AREN'T in the
manuals generally don't get RTFM as a response in the first place.
RTFM *ASSUMES* that the answer is in there, Scott.

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Error in MS C 6.0 ?
Date: 26 Jul 1992 01:23:25 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
NNTP-Posting-Host: 128.3.112.15

>Distribution: comp
(comp is not a distribution.  Please check your news software.)

>In article <1992Jul21.175215.13891@vax5.cit.cornell.edu>
>rdw@vax5.cit.cornell.edu writes:
>>When passing single-precision float arguments to a function, I get
>>compilation errors when I try to use the following together:   
>>prototyping in the function allusion but 'old-style' argument
>>declarations when defining the function.

If `allusion' means `declaration', this is entirely correct (see my
previous article on prototypes).

[the example:]
>>int func(int a, float x, int b);			/* DECLARATION */
>>int func(a, x, b) int a; float x; int b; { ... }	/* DEFINITION */

In article <1992Jul22.204254.4707@dg-rtp.dg.com> welshm@snail.rtp.dg.com
(Matt Welsh) writes:
>Of course. If you use a prototype, MSC will expect new-style function def's.
>You get a Parameter 2 mismatch because MSC thinks that "x" is an integer.

No: in fact, the definition claims that `x' is a `double'.  The
declaration claims, contrarily, that `x' is a `float'.  The two are not
compatible.  You can either use prototype syntax for the definition (as
Matt Welsh suggests) or declare x `double' in the prototype.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
Newsgroups: comp.lang.c
From: ankleand@mtl.mit.edu (Andrew Karanicolas)
Subject: Gnu C Compiler for PC (djgpp)
Organization: MIT Microsystems Technology Laboratories
Date: Thu, 23 Jul 1992 01:07:48 GMT

Hello,

I am interested in obtaining the gcc compiler for the PC, djgpp, so
that I can run 32-bit code on my Dell386.

I have found djgpp on wuarchive.wustl.edu located in:
/mirrors3/garbo.uwasa.fi/djgpp.

There doesn't seem to be a djgppxxx.zip file around.  There are many
files in the djgpp directory.  I retrieved the faq file and it seems
that I need a go32 program to run the 32-bit compiled code.  Could
someone tell me which files I need to retrieve in order to get djgpp
up and running?  Do I unzip the appropriate set of files in the same 
directory on the PC?  Am I supposed to retrieve the entire djgpp
directory and untar and then unzip the result?

Please send e-mail if you can contribute to an answer.  I'll post the
replies if there is interest.  Thanks!

-- 
Andrew Karanicolas
MIT Microsystems Technology Laboratory
ankleand@mtl.mit.edu
Newsgroups: comp.lang.c
From: dbushong@wang.com (Dave Bushong)
Subject: Re: Hungarian notation
Organization: Wang Labs, Lowell MA, USA
Date: Thu, 23 Jul 92 02:12:52 GMT

pauls@truevision.com writes:


>Why don't you forget about Hungarian notation (trying to do type checking by
>hand), and just select the identifier in question, hold down the middle mouse
>button and read the pop-up dialog box that tells you what the identifier
>(or other symbol) is all about?
>    What type it is (if it is a variable or a type)
>    Its current value (if it is a variable, and the program is running)
>    Notes you or past programmers may have typed in about that identifier
>    ....
>If you want the dialog box to hang around after you release the mouse
>button, just release the middle mouse button outside of the dialog box.

>Why not quit wasting net bandwidth arguing about whether Hungarian notation
>is useful, and just implement a programming environment that includes features
>like the ones I made up in the previous paragraph?
>I don't imagine too many people will be interested in Hungarian notation once
>they have such a programming environment.
>People who like Hungarian notation won't bother with it any more.
>People who don't like Hungarian notation who't have to see it any more.
>People who don't really care about Hungarian notation can read interesting
>articles in comp.lang.c again.

:)  !!!!!!

Bravo, Paul.
-- 
==========================================================================
Dave Bushong, KZ1O@K1UGM.MA         +    No .sig, no tattoo, 
Wang Laboratories, Inc.             +        no bald spot, no nothin!!
Internet: dbushong@wang.com         +-------------------------------------
Project leader, OCR Products        + (reserved for future expansion)
From: Stefano_De_Luca@mas.sublink.org (Stefano De Luca)
Newsgroups: comp.lang.c
Subject: Re: C Compiler info needed!
Date: 29 Jul 92 03:29:49 GMT
Organization: MangaZone Advanced Services, Rome - ITALY



I am using a not-IBM compiler on OS/400, the ASNA Diploma/C. Of course, it
is
an ANSI compiler. The problem with this compiler are:

        1) slowness: it is a very slow beast (but I don't know the IBM C)
        2) file functions: these are all very much close to RPG (that I
don't
           know... I'm trying to translate a Unix communication
program...),
           all having form as __chain, __reade and so on
        3) there isn't an environment into work. Editing is SEU, no make,
no
           SCCS, only the crude compiler/linker
        4) there isn't any way to have inter-process communication
        5) there isn't any way to link C-functions to COBOL, without a call

Otherwise, it is a neat compiler without other particular biases. I'm going
to
use in September the IBM compiler. Do you know about a Unix-like
environment
on OS/400?

Stefano - stefano_de_luca@mas.sublink.org



 -- AEd V1.36/Eval

-- Via DLG Pro v0.992
Newsgroups: comp.lang.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: Pointers to freed memory
Organization: TauMetric Corporation
Date: Thu, 30 Jul 1992 16:40:35 GMT

jos@and.nl (Jos Horsmeier) writes:

>In article <1992Jul29.205834.11308@hubcap.clemson.edu> mjs@hubcap.clemson.edu (M. J. Saltzman) writes:
>|I know that a pointer to freed memory should never be dereferenced, 
>|but is it standard-conforming to assign or do arithmetic with such
>|pointers?

>As long as you do not dereference such a pointer (as you indicated
>yourself,) everything is fine.  If pointer q contained a valid pointer
>value _before_ the call to free(), it'll contain a valid pointer value
>_after_ the call.

This is not necessarily the case, although it is safe for many common
architectures.

The C Standard states that the value of the pointer after a call to free
is 'indeterminate'.  This means that just reading the value might
produce a runtime fault.

Imagine an architecture that uses a distinguished data type for pointers;
the hardware can tell the difference between a pointer and an integer
for example.  Furthermore, there are valid and invalid values for any
data type, such as pointers, integers, floating-point.  Reading an invalid
value causes a fault.  At program start, for example, all uninitialized
variables are given an illegal value, so that attempts to use such
values are detected as soon as they occur.  Such architectures do exist.

When data is freed, the memory could be removed from the program
address space.  The pointer to the former data would now be invalid,
and checked by the hardware on a reference.  Simply testing the value
of the pointer after the call to free could thus cause a fault.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16