HDTenEightyP/NetNews huggingface dataset:
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Probably a simple realloc() question
Date: 1 Oct 92 18:15:53 GMT
Organization: negligable

In article <1412@pacsoft.com> mike@pacsoft.com (Mike Stefanik) writes:
>In an article, steve@taumet.com (Steve Clamage) writes:
>>[...] If realloc cannot shrink the size, it should do nothing; it should
>>not attempt to make a smaller copy, for exactly the reason that it might
>>fail.  It is not reasonable to fail on being asked to do less than has
>>already been done. [...]
>
>I have an issue with this last sentence. Consider a single-tasking operating
>system with no VM. By forcing realloc() to always return successfully, the
>program does not know if the memory that it was using has *actually* been
>released. I could imagine that this would be an issue for "terminate and stay
>resident" programs and their ilk.

We aren't suggesting it should be forced to return successfully, we
are suggesting that it be forced to do it's job.  There is no reason
for downsizing a dynamically-allocated block of memory to fail.

Assume a simplistic memory management scheme where the size of
the chunk of allocated memory is recorded in the word immediately
prior to the actual data pointer, e.g.:

struct mem_block { uint size; void *data; }

where malloc() would return the address of the struct.data field
for us to actually use.   When downsizing you should just be able
to alter the value of the size field and then create a free_mem
struct on the remaining bytes to return that memory to the
free list (assuming the downsize is enough bytes to create a
whatever free_mem struct you are using.... I would assume:
	struct free_mem_node { struct free_mem_node *next; struct mem_block b; }

would not be unreasonable....)

Any *reasonable* memory management system should be able to handle
this.  w/ a downsizeing realloc() it is brain-damaged (to borrow
Bill Gate's favorite description) to require a separate allocation
first then release the existing memory, especially since in a 
realloc data is supposed to be preserved, i.e. you would have
to allocate new mem, copy data, then free old mem & return the
pointer to the new mem.

This is clearly unnecessary except in the cases when you are
INCREASING the size of the memory block.

To repeat: 
 "It is not reasonable to fail on being asked to do less than has
		already been done." 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Between the silence of the mountains	|
and the crashing of the sea 		|	-Richard Hartman	
there lies a land I once lived in	|	hartman@uLogic.COM
and she's waiting there for me.		|
From: pickens@bsu-cs.bsu.edu (David B. Pickens)
Newsgroups: comp.lang.c
Subject: enum type and case statements
Date: 2 Oct 92 23:49:07 GMT
Organization: Dept. of CS Ball State University Muncie IN

I am working with a program that used if...then....else
statements instead of case statements.  The Microsoft 
compiler I have does not support anything other than
constant types for the case statement.

Here's the problem, I can't for the life of me remember how
to do enum types.  I have 20 to 25 strings of two or three letters
each that need to be used in the case statement.  Originally I
tried this:

                switch(arg[3])
		{
			case 'AG':
				command_ag();
				break;
			case 'AV':
				command_av();
				break;
                        ...........
			default:
				command_err();
				break;
		}

This did not work needless to say.  So I switched my train of thought
to using enum and setting up something like this:

enum command {AG=1,AV,.......,ZZ} arg;

main ()
{

...........

		switch(arg)
		{
			case 1:
				command_ag();
				break;
			case 2:
				command_av();
				break;
			...........
			default:
				command_err();
				break;
		}

My question is this, if I go this route, how in the world of c do I
convert my two/three character string and get the right enum?

Any ideas out there?

Thanks.

David
				

-- 
David B. Pickens | pickens@bsu-cs.bsu.edu 
Grad. Student & Grad. Assistant | Center for Information and
                                  Communication Sciences
"Ouch!" - Newton's first words after discovering gravity
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c
Subject: Re: Probably a simple realloc() question
Date: 3 Oct 92 02:58:27 GMT
Article-I.D.: alice.23789
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <1992Oct2.160420.3937@taumet.com> steve@taumet.com (Steve Clamage) writes:

> But there is no promise that realloc() will return unused memory to
> the system.

Agreed, but that's not the point.

The point is that there exist systems on which a plausible implementation
of realloc might always try to allocate new memory and then free the old.
On such a system, it might well be that an attempt to shrink an allocated
area with realloc might fail due to memory exhaustion.

That does not gainsay your point that other implementations could plausibly
do it differently.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c,gnu.gcc.help,comp.sys.sun.misc
From: ruck@zeta.ee.ufl.edu (John R Ruckstuhl Jr)
Subject: gen complete set of prototypes
Organization: EE Dept at UF
Date: Wed, 30 Sep 92 20:18:25 GMT

I want to code in ANSI C, and compile with "gcc" with lots of strict
checking.

If I understand this right, the installation of gcc derives ANSI
function prototypes from the native include files and generates the ANSI
compatible include files.
But for my system (SunOS 4.1.1) the original include files don't declare
all functions -- many, especially those returning int, aren't there.
So the derived header files are likewise incomplete.

Which means the user has to write some of his own prototypes.

If one writes the prototype for a library function wrong, and uses the
function consistantly wrong, no compiler checking is going to catch it.

So, we can hope that the compiler vendors will bundle include files that 
completely prototype the libraries.

But in the meantime:
Does anyone have such a complete set of include files that they've
somehow acquired that describe the libraries bundled with SunOS 4.1.1, 

and, more generally,
wouldn't they be easy to generate from source with some utility
(cproto?) ?  There are some persons on my campus licensed to play with
the Sun sourcecode.

How do you handle this issue?
I'm really quite out of my league here, so pedantry is welcomed.

Thank you.
Best regards,
ruck
-- 
John R. Ruckstuhl, Jr.                  ruck@alpha.ee.ufl.edu
Dept of Electrical Engineering          ruck@cis.ufl.edu, uflorida!ruck
University of Florida                   ruck%sphere@cis.ufl.edu, sphere!ruck
Newsgroups: comp.lang.c
From: kpv@ulysses.att.com (Phong Vo)
Subject: Re: Curses to write to stderr, possible?
Date: Tue, 6 Oct 1992 14:28:20 GMT
Organization: AT&T Bell Labs

In article <375@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
>Yeah, my suggestion has a portability problem -- anywhere that stdin
>and stdout are macros instead of FILE * variables you've got problems.
>
>On the other hand freopen() only solves half the problem, redirecting
>stdout to where you want.  The other half, RESTORING it afterwards, has
>no portable solution that I am aware of.  Or even a common one.  At least
>my suggestion works where the stdin & stdout are variables.  Does anyone
>know how to "reconnect" stdin/stdout to their original sources after
>haveing been freopened()?
>
If you were on UNIX system, you could play around with dup() and the file
descriptors of stdout&stderr to get what you want. This is sneaky at best.

If (very big if) the sfio library was used instead of stdio, temporarily replacing
stdout by stderr can be done with a single call: sfstack(sfstdout,sfstderr).
This stacks sfstderr on top of sfstdout so that any future output to sfstdout
will be redirected to sfstderr. When you want to restore sfstdout to its
previous state, you simply pop the stack with: sfstack(sfstdout,(Sfile_t*)0).
  
Phong Vo, kpv@ulysses.att.com
AT&T Bell Labs, 600 Mountain Ave, Murray Hill, NJ07974
From: tswingle@oucsace.cs.ohiou.edu (Tom Swingle)
Newsgroups: comp.lang.c
Subject: Re: Curses to write to stderr, possible?
Date: 6 Oct 92 03:46:38 GMT
Organization: Ohio University CS Dept,. Athens

In article <375@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
>Yeah, my suggestion has a portability problem -- anywhere that stdin
>and stdout are macros instead of FILE * variables you've got problems.
>
>On the other hand freopen() only solves half the problem, redirecting
>stdout to where you want.  The other half, RESTORING it afterwards, has
>no portable solution that I am aware of.  Or even a common one.  At least
>my suggestion works where the stdin & stdout are variables.  Does anyone
>know how to "reconnect" stdin/stdout to their original sources after
>haveing been freopened()?

Would there be any problem with using memcpy instead of assignments?  I got
the following program to work, and our system does #define stdin, stdout, and
stderr rather than declare them as variables:

#include <stdio.h>
#include <memory.h>
#include <malloc.h>

main() {

  FILE *temp;

  temp=(FILE *) malloc(sizeof(FILE));
  memcpy((char *) temp,(char *) stdout,sizeof(FILE));
  memcpy((char *) stdout,(char *) stderr,sizeof(FILE));
  fputs("Hello there, this is stdout changed to be stderr\n",stdout);
  memcpy((char *) stdout,(char *) temp,sizeof(FILE));
  fputs("Hello there, this is stdout back to its old self again\n",stdout);
  return 0;

}

As expected, invoking "a.out" causes both lines to be printed, while 
"a.out > /dev/null" causes only the first one to be printed.  These files
were probably only meant to be opened, closed, read, and written; although
I can't think of any problems that might arise by directly manipulating 
them, it doesn't mean there aren't any.  Can anyone think of such problems?  
-- 
"The problem you are experiencing is  |  "To be sure of hitting the target, 
not with the network nor with the     |  shoot first and, whatever you hit, 
station.  Please adjust your set."    |  call it the target." 
More ramblings from: tswingle@oucsace.cs.ohiou.edu/tswingle@bigbird.cs.ohiou.edu
Newsgroups: comp.lang.c
From: amwalker@nyx.cs.du.edu (Art Walker)
Subject: Re: What is RPG ???
Organization: University of Denver, Dept. of Math & Comp. Sci.
Date: Sat, 3 Oct 92 05:21:08 GMT

silvia@rcf.rsmas.miami.edu writes:

>In article <1992Oct2.015817.183@wsuhub.uc.twsu.edu>, ckcheng@wsuhub.uc.twsu.edu writes:
>>     Hey, does anybody heard of RPG (language or system?, NOT role playing game
>>) ?  Can anyone talk about it in this category or open a new category ?
>RPG stands for Report Program Generator. It is usually found on minis and
>mainframes. It is a language that requires inline coding. A real headache.

>          Manolo

To be more specific, RPG is almost exclusive to IBM minicomputers (what they
like to call "midrange" systems) such as the System/36, System/38, and AS/400.

(Oddly enough, since the AS/400 supports C, I have been told that RPG to C
translation tools are starting to become quite popular...)

- Art

--
- Art Walker (amwalker@nyx.cs.du.edu)
	"It started to hit me like a umm, ah, two-ton heavy thing."
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: Multiple assignments
Date: 28 Sep 92 16:14:54 GMT
Organization: University of Helsinki

abutler@ariel.demon.co.uk (Tony Butler) writes:
>      char *p,*s;
>      s=p=malloc(sizeof(char));
>
>  Does this allocate the memory to p and then make s point to the same
>  location, or do p and s both get seperate areas of memory allocated to
>  them?

Neither.  It reserves some memory (in some unknown way in some unknown
part of the known universe).  It then assigns both p and s the same
pointer value so that they both point to the reserved memory.  Neither
pointer gets any special priviledge.

Note that I used the word `reserve' instead of `allocate' in the hope
that the explanation would be more clear this way.  (I get the feeling
that many people think that `allocate' has a meaning similar to
`associate', and that this might be the reason why they want to use the
exact same variable when they free a dynamically allocated variable.)

I'll draw some pictures.  I will depict allocated memory with boxes, and
named variables as boxes with a name beside them.  (That is what
variables are: allocated parts of the memory with a name attached to
them, although the name usually disappears during compilation since it
is used only by humans.)  Anything inside the box is what that piece of
memory contains.

In the beginning, we only have the variable p and s:

             :
             :
    +--+     |
  p | -+--\  |
    +--+   |_|

    +--+
  s | -+--\
    +--+   |
           :
           :

Note that the values of both variables look a bit funny.  That is
because they contain random garbage: variables do not contain any
specific value when they are created (with some exceptions which I am
not going to get into here).  In this case, where p and s are pointers,
they happen to point into random places in memory.

The next thing that happens is that malloc is called.  This allocates
some memory:

             :
             :
    +--+     |
  p | -+--\  |
    +--+   |_|			+----+
				|?xd4|
    +--+			|3ax3|
  s | -+--\			+----+
    +--+   |
           :
           :

(By the way: don't draw any conclusions about the relative sizes of the
boxes.)  p and s do not change, and the contents of the newly allocated
block is also garbage.  The next thing that happens is that p and s are
made to point to the newly allocated, but unnamed block.  The
assignments can happen in any order (read about sequence points in the
FAQ if you want to know more), so I will only depict the end result.

    +--+
  p | -+-----------\
    +--+	   |		+----+
		   \----------->|?xd4|
		   /----------->|3ax3|
    +--+	   |            +----+
  s | -+-----------/		
    +--+


Hopefully this clarifies a little bit.

--
Lars.Wirzenius@helsinki.fi
From: karl@ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Lint Puzzler
Date: 27 Sep 92 17:42:30 GMT
Organization: Formerly of Interactive Systems, Cambridge, MA

In article <1992Sep27.025238.28958@mccc.edu> pjh@mccc.edu (Pete Holsberg) writes:
>>Judging from this information, I would say that you have a library that
>>attempts to be Standard-conforming and a header that does not.
>
>How can I tell if the header conforms or not?

If the header declares fread() to return an int, rather than a size_t as
mandated by the Standard, then it's non-conforming.

>>or perhaps an feature-test macro you can use
>I'm not sure what you mean by that.

Sometimes the non-Standard and Standard versions of the header are combined
into a single file with the sections delimited by #if directives.  For
example, it might be that you can force your <stdio.h> to be conforming by
simply using   #define _ANSI_SOURCE   *before* you include the header.  You'll
have to look at the header to see what symbol, if any, controls this behavior.

Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
Newsgroups: comp.lang.c
From: willdm+@pitt.edu (William D Moore)
Newsgroups: comp.lang.c
Subject: Thanks
Date: 30 Sep 92 19:50:00 GMT
Distribution: usa
Organization: University of Pittsburgh
Originator: willdm@pmax1.cis.pitt.edu

Thanks to everyone who sent me a reply about my "Illegal Pointer Arithmetic"
problem during compile time.  Basically I was writing:

*buf++=NULL;

when I needed to write:

*buf++='\0';

Thanks again.

Will @ Pitt

Newsgroups: comp.lang.c
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: C-formattors (problems with very long lines)
Organization: Computer Science, University of Melbourne, Australia
Date: Wed, 30 Sep 1992 14:09:46 GMT

hermann@uran.informatik.uni-bonn.de (Hermann Stamm) writes:

>fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>> hermann@uran.informatik.uni-bonn.de (Hermann Stamm) writes:
>> 
>> >I wrote my own simple "C-beautifier", which simply does the
>> >following:
>> >
>> >   - discard empty lines
>> >   - insert a '\n' after each ';' found
>> >
>> >This works fine, but now I have 2 questions:
>> >
>> >  1. Is this a correct transformation of any C-Source ?
>> 
>> No. You need to make sure that you don't insert newlines into string
>> or character literals that may contain semi-colons.
>
>Sorry, you are right!
>Below you can find the little prog I am using. It detects both,
>if a ; is inside "..." and inside ' ' . If so, it doesn't insert
>the '\n' after the ; otherwise it does.
>
>The question now is, does the below program correctly transforms
>any compilable C-source into also compilable C-source.

No. You also need to make sure that you don't insert newlines into
macro definitions (#defines), or other pre-processor directive lines,
including #include, #error, and #line.

Your program also doesn't work because quotes may be unmatched inside
comments, when escaped with a back-slash, or inside the other sort of
quotes ("'" or '"').

-- 
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: markst@chips.com (Mark Storkamp)
Newsgroups: comp.lang.c
Subject: Re: Turbo C++ problem
Date: 28 Sep 92 20:04:11 GMT
Organization: Chips and Technologies, San Jose, CA

In article <mL2qRB1w165w@kozmix.hacktic.nl> sander@kozmix.hacktic.nl (Sander van Malssen) writes:
>abutler@ariel.demon.co.uk (Tony Butler) writes:
>
>> Thanks, I'm, using Turbo C v2, which doesn't have a setmode() function.
>> I know how to call int 10, the problem is that any documentation I have
>> read (even regarding int 10) does *not* mention 43/50 line modes, just
>> the 25 line modes & other graphic modes. Obviously there must be *some*
>> way to do it apart from having ansi.sys installed.

	mov	ax,1112h
	xor	bl,bl
	int	10h

Which is: Function 11h (Character Generator)
	  Sub-function 12h (Load 8x8 double dot text mode font
		and initialize parameters)

Mark Storkamp


Newsgroups: comp.lang.c
From: ko@wiliki.eng.hawaii.edu (Scott Ko)
Subject: TEST
Organization: University of Engineering, College of Engineering
Date: Tue, 6 Oct 1992 20:48:27 GMT
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: C libraries
Date: 30 Sep 92 21:49:42 GMT
Article-I.D.: ulogic.343
Distribution: usa
Organization: negligable

Graphics?  Plotter?  Printer?  Sun workstation?  Apollo workstation?
IBM-PC (EGA? VGA? MONO? 8514/a?...)
From: sasghm@theseus.unx.sas.com (Gary Merrill)
Newsgroups: comp.lang.c
Subject: Re: ++i = i++ ?
Date: 29 Sep 92 14:06:06 GMT
Organization: SAS Institute Inc.
Originator: sasghm@theseus.unx.sas.com


In article <1992Sep28.184140.4116@kpc.com>, hollasch@kpc.com (Steve Hollasch) writes:
|> 
|>     I'll assume that you made a typo here and really meant to say
|> 
|>         for (i=0; i < Count; ++i)
|>                            ^ A comma here is a syntax error.

Well, since no one else pointed this out, and in order to forestall
additional errors and confusion ...

A comma here is *not* a syntax error!  The syntax error is

         for (i=0; i < Count, ++i)
                                 ^
                                 missing ';'

Now I admit that

         for (i=0; i < Count, ++i; )

would be pretty unusual code, but it is *syntactically correct*.
(And indeed, there *are* cases when one might *want* a comma
operator in the middle clause.)
-- 
Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / (919) 677-8000
sasghm@theseus.unx.sas.com ... !mcnc!sas!sasghm
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.lang.c
Subject: Re: Is there is (pascal) WITH equivalent in C?
Date: 2 Oct 92 07:38:14 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Organization: University of Arizona

[geeze! doesn't anyone take compiler writing classes any more?]

In article <1992Oct1.114517.3937@rz.uni-karlsruhe.de>, ae24@iamk4516 (Peter Januschke) writes:
>jos@and.nl (Jos Horsmeier) writes:
>> May I strongly suggest _not_ to use such macros, they're obfuscating 
>> the code. Just imagine what would happen if other structs happen to
>> have elements with the same names (bar and baz.) IMHO the WITH construct
>> in Pascal is silly, it just saves a couple of keystrokes, ... 
>                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>                      ||||||||||||||||||||||||||||||||||||
>
>That's just not true. Most non-optimising compilers would generate better
>and faster code from a WITH construct than from the corresponding construct
>without WITH.

I don't think so.  Record field offsets can be calculated at compile
time (and presumably are by all compilers worth the name).  That means
that

   a.b.c.d := a.b.c.e + a.b.c.f ;

should generate exactly the same code as

   with a.b.c do d := e + f ;

Pascal's with statement is nothing more or less than syntactic sugar.


>  WITH a.b.c DO x := y + z;
>
>is always better than writing
>
>  a.b.c.x := a.b.c.y + a.b.c.z;

You know, I think that if you've got code that's got 3 levels of record
field dereferencing in it, the first question you ask should not be
"think I should use a `with' here?", it should be "is there some reason
I can't write a more reasonable data structure access routine?".

-- 
Dave Schaumann			dave@cs.arizona.edu
Newsgroups: comp.lang.c
From: wilson@gauss.cs.jhu.edu (Dwight Wilson)
Subject: Re: Untyped pointer arithmetic
Organization: The Johns Hopkins University CS Department
Date: Thu, 1 Oct 1992 12:54:31 GMT

In article <14813@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>So it is syntactically legal to do
>
>	void *p, *q;
>	ptrdiff_t d;
>
>	d = (char*)q - (char*)p;
>
>Whether that makes sense is up to you.

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.  

-Dwight
From: bjackson@mentor.cc.purdue.edu (Ben Jackson)
Newsgroups: comp.lang.c
Subject: Re: Probably a simple realloc() question
Date: 28 Sep 92 21:08:01 GMT
Organization: Purdue University Computing Center

In article <hjv.717640199@groucho.phil.ruu.nl> hjv@phil.ruu.nl (Hendrik Jan Veenstra) writes:
>Of course this is the obvious way to go (I think), but:
>is it the best/only solution? Are there other solutions that don't run
>the risk that reallocation fails (so preferably a solution that doesn't 
>use realloc at all :-)? I just don't want to waste large amounts of
>memory...

Well, if you're writing this on a UNIX box, you don't need to worry about
having realloc() fail, as a general rule.  With virtual memory, the machine
will continue to give even when it has no physical ram left.  (Yes, there
are exceptions)

On a personal computer (Amiga, Mac, that unmentionable `I' company) you
might have problems allocating an array that large.

One solution would be to make your actual array just an array of pointers
to THING's, which would be much shorter and essentially painless to
realloc() (or at least more so than realloc()'ing an actual array of THINGs)
Then you would allocate each THING individually (or, to be more memory
efficient, in groups of 5, 10, 20, whatever is reasonable for the application)
and assign the pointer in the array to this new THING.

The drawback of this would be that you wouldn't be able to use code which
assumes that the array consists of THING's, as it now consists of THING*'s.

\\_//
 o o    Ben Jackson
< ^ >   bjackson@mentor.cc.purdue.edu
 \~/         ...@glia.biostr.washington.edu
  V     "Natural laws have no pity."
Newsgroups: comp.lang.c