HDTenEightyP/NetNews huggingface dataset:
From: darcy@druid.uucp (D'Arcy J.M. Cain)
Subject: Re: Macros for ANSI prototypes
Date: Tue, 18 Aug 1992 17:01:08 GMT
Organization: D'Arcy Cain Consulting

robert@isgtec.com (Robert Osborne) writes:
>darcy@druid.uucp (D'Arcy J.M. Cain) writes:
>> [...] The K&R code just becomes one of the stages of the
>> compilation. [...]
>>     ANSI C --> K&R C --> Assembler --> a.out
>> You see the K&R is simply an intermediate stage and is thrown out after
>> along with the .s and .o files.
>Gaak!  This is gross.
>You can't throw away the K&R step because you need the source for
>debuggers.

Who said you had to throw it away immediately?  In fact the example I use
later involved copying the K&R code to another box and compiling there.  By
"after" I meant "after it is no longer needed."  I kind of thought that was
obvious.

>The K&R systems are used also for development; there are enough
>problems with the compilers and with the speed of compile without
>adding yet another preprocessing step.
>
>It would only take one major bug introduced by the ANSI to K&R
>step to remove the developer time savings.

If your tools don't work then get ones that do.  I mean if we are going
to discuss the use of various tools we have to assume that cpp does macro
processing by the accepted rules, cc compiles C code and all the other
tools perform as advertised.  I don't think it matters where a major bug
is introduced.  If a tool is broken it will cost the developer time.
Just ask anyone who does development using compilers from you-know-who
with a version number of x.0.

>The ANSI source and the K&R source are now distinct between
>platforms.   This does NOT leave me with any warm fuzzies.

Say what?  There is *one* source.  It goes through X translation phases
on its way to becoming an executable.  You aren't supposed to further
develop with the intermediate stages.  Changing the K&R code would be
just as bad as if you had to modify the assembler.

>I do not consider this even remotely as elegant as the prototype macros.

My way:

int foo(char *, int);
...
int foo(char *bar, int n)
{
  /* stuff */
}

Your way: (I don't have the original message but I think this is close)

int foo(__DECL((char *, int));
...
int foo __DEFN((char *bar __ int n))
{
  /* stuff */
}

What is your definition of elegant?

-- 
D'Arcy J.M. Cain (darcy@druid.com)  |
D'Arcy Cain Consulting              |   There's no government
Toronto, Ontario, Canada            |   like no government!
+1 416 424 2871          DoD#0082   |
From: elias@proxxi.se (Elias M}rtensson (proxxi))
Newsgroups: comp.lang.c
Subject: How many malloc's can I use?
Date: 17 Aug 92 18:16:15 GMT
Organization: proxxi

Does ANSI C specify the maximum number of malloc calls that can safely
be made? Can I do a couple of thousand malloc's and still count on
that everything will work fine? I am not interested in any
descriptions of the MS-DOS limitations or anything like that. I just
want to know what ANSI C says.

And does ANSI C specify that largest block of memory that can be
malloc'ed?

###################
# Elias Martenson #
# elias@proxxi.se #
###################
Newsgroups: comp.lang.c
From: adam@microware.com (Adam Goldberg)
Subject: Re: Memory alignment of struct elements
Organization: Microware Systems Corp., Des Moines, Iowa
Date: Mon, 17 Aug 1992 14:02:14 GMT

sasghm@theseus.unx.sas.com (Gary Merrill) writes:


>In article <1992Aug12.133132.10723@Princeton.EDU>, udalski@astro.Princeton.EDU (Andrzej Udalski) writes:
>|> I am writing the software for a big database and the space is very
>|> important. If I try to use a 
>|> 
>|> struct { char ch ; float f }
>|> 
>|> the compiler (both in SunOS 4.0.1 and Interactive SYSVR3) allocates
>|> 8 bytes for it, starting the "f" element at fifth byte of the structure.
>|> This makes both reading and writing such records from/to a binary database 
>|> file (consisting of 5-byte-long records) very inconvinient, requiring
>|> a declaration of character array of 5 bytes and using "memcpy()". Is there 
>|> a way to force the compiler to align the struct elements following their 
>|> true length?

>This depends upon the compiler, of course.  Many compilers have such
>an option, but (depending upon the architecture, etc.) it may not
>be a good idea to use it.  You might simply try:

>	struct { float f; char ch; }

>which will not require the internal padding you are encountering.
>In general, to avoid such padding you should define your structure
>members in decreasing order of alignment requirements.  Note that
>the compiler will tend to add padding to the *end* of the structure
>in order to achieve correct alignment in *arrays* of such structures.
>Still, such an approach may help you.

That's all well and good, but what if, say, you are coding an implementation
of LIM EMS 4.0, which takes as a parameter a structure which, in assembler,
looks like this:

Parm Struct
MemIn      dd   ?   ; 4 bytes
MemIType   db   ?   ; 1 byte
MemISize   dw   ?   ; 2 bytes
MemOut     dd   ?   ; 4 bytes
MemOType   db   ?   ; 1 byte	
MemOSize   dw   ?   ; 2 bytes
Parm Struct

In C, this *could* be :

typedef struct PARM {
  char *MemIn, MemIType;
  short MemISize;
  char *MemOut, MemOType;
  short MemOSize;
} PARM, *pPARM;

Except for the addition of superflourous padding bytes.  Is there any
standard way to FORCE the C Struct to be identical to the Asm struct?

No, I didn't think so.  There ought to be, though.  I've been forced to
do nasty things like:

typedef struct PARM {
  char MemIn[4], MemIType, MemISize[2];
  char MemOut[4],MemOType, MemOSize[2];
};

Then on each usage of, say 'MemOut', I've got to:

   (char *)(p->MemOut)

Ugly.


-- 
Adam G.
adamg@microware.com, or ...!uunet!mcrware!adamg
The above is not to be construed in any way as the official or unofficial
statements of Microware, or any Microware employees.
Newsgroups: comp.lang.c
From: karl@ima.isc.com (Karl Heuer)
Subject: Re: Macros for ANSI prototypes
Organization: Interactive Systems, Cambridge, MA 02138-5302
Date: Tue, 18 Aug 1992 18:37:20 GMT

In article <3116@isgtec.isgtec.com> robert@isgtec.com (Robert Osborne) writes:
>darcy@druid.uucp (D'Arcy J.M. Cain) writes:
>>     ANSI C --> K&R C --> Assembler --> a.out

This is exactly what I do, too.

>Gaak!  This is gross.
>
>You can't throw away the K&R step because you need the source for debuggers.

Why?  The debuggers that I use don't care about anything except the line
numbers.  They don't actually interpret the source code.  (In any case, it's
easy enough to keep the intermediate file around during the debugging phases.)

>It would only take one major bug introduced by the ANSI to K&R
>step to remove the developer time savings.

My deprotoizer is only 137 lines long, including comments.  It's deliberately
simplified.  If it fails to recognize something, it will almost certainly
cause the next phase of compilation to complain, rather than produce a wrong
answer.

>I do not consider this even remotely as elegant as the prototype macros.

Well, that's your choice, I guess.

Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
Newsgroups: comp.lang.c
From: hm342st@unidui.uni-duisburg.de (Michael Staats)
Subject: Re: POWER OF LARGE NUMBERS
Date: 19 Aug 92 13:33:06 GMT
Organization: Rechenzentrum Uni-Duisburg

In <1992Aug19.140602.1509@tac.fi> tiok_ks@tac.fi writes:

>In article <thompson.714156001@daphne.socsci.umn.edu>
>thompson@atlas.socsci.umn.edu (T. Scott Thompson) writes:

>> Alright!  Who volunteers for 7 ^ (7 ^ 7)?
>>                                 ...
>>                              10 ^ (10 ^ 10) ?
>> 
>> P.S.  Mathematica 2.1 on a Sparc 2 does 6 ^ (6 ^ 6) in 5.02 CPU seconds.

>OK, I can do the latter one - after all, it's greater:

>1E+10 000 000 000

>It took about 4 seconds of my personal CPU, but my
>hands are slow, so it took about 10 secs of I/O time.
>But after all, that's an exact number... ;-)

>Now, who's going to calculate the smaller ones, like
>7 ^ (7 ^ 7) ?

Now I don't think it's too complicated. The answer is of course

1E+10 000 000 000 (Base 7)

It took me and a friend about one minute CPU time (two
parallel processors) to verify this solution, I/O was about
the same.

So long
Michael
-- 
Michael Staats
Theoretische Tieftemperaturphysik
Universitaet Gesamthochschule Duisburg
michael@hal9000.uni-duisburg.de
Newsgroups: comp.lang.c
From: behrenss@Informatik.TU-Muenchen.DE (Soenke Behrens)
Subject: Re: How do you connect all the records together?
Organization: Technische Universitaet Muenchen, Germany
Date: Mon, 17 Aug 1992 08:48:37 GMT

From your post, it was less than clear exactly how your datastructures
or your code looked like. Nonetheless, here goes:

Have a pointer to your struct type, have a pointer to an array of pointers
to your struct type. Now, everytime a record is to be inputed, malloc()
memory for it, realloc() the memory in your array, store the pointer you
got, input the struct. And so on.

When you want to output them: Simply look at all the stored pointers.

Easy enough. Really :) Write it down if you have trouble imagining it.

Soenke

-- 
===========================================================================
More than silver, more than gold, I need   !    behrenss@informatik.
electricity. I need it for my dreams.      !    tu-muenchen.de
(RACTER)                                   !  FIDO: 2:246/13 Soenke Behrens
From: l1z@ecl.psu.edu
Newsgroups: comp.lang.c
Subject: Using super VGA in C?
Date: 19 Aug 92 12:19:29 EDT
Organization: Engineering Computer Lab, Pennsylvania State University

Please help! I want to be able to use high-resolution (1024 X 768 X 256 color)
in my C codes. But I don't know how to set the video mode. I am using the
MicroSoft C 5.0 on a PC. the graph.h file only support the standard VGA modes.
Can any one tell me how I can use super VGA modes? Thanks in advance.

Joe
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.lang.c
Subject: Re: Computer terms, etc
Summary: may still be missing the point
Date: 17 Aug 92 02:16:11 GMT

-> From: scotth@felix.filenet.com (Scott Hopson)
-> Message-ID: <19590@fritz.filenet.com>
->>> *foo[] is a pointer to an array
->> No, it's an array of pointers, because [] has higher precedence than *.
-> Sorry, it was 2:00 AM when I wrote that, I guess I forgot to put
-> "of pointers" on the end.
->
-> *foo[] is a pointer to an array [of pointers]
->
-> thanks for the correction.

Um... I think Scott is still missing out on exactly what he's being
corrected upon.  Objects type (*foo[]) are not pointers in any way,
shape, or form.  They are arrays.  Again: the object named "foo" by
the above declaration is NOT A POINTER (though it sometimes
plays one in certain expressions).

To convince yourself that this is so, consider the results of
applying sizeof to such an object.

Now, with that said, if such a type is declared to be a formal
parameter, it is "rewritten" by the compiler to be of type (char**).  
In which case the type is "pointer to pointers to chars", no array
involved. 

Hear me now and understand me later:

Renounce the foul heresy that "array declarations really declare
constant pointers in C", firstly because it is the Font of Many Errors,
and leads inevitably to Bad Code, but also because it isn't true.  If
you don't renounce this heresy, I prophesy that Subtle Pointer Bugs will
hound you all the days of your programming life.  YOU have been WARNED. 

--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
Newsgroups: comp.lang.c
From: patrick@blmc46.QE.Bell.CA (Patrick Seynave)
Subject: Re: getc() with timeout
Organization: Bell Canada -- OD Information Architectures
Distribution: na
Date: Wed, 12 Aug 1992 18:27:08 GMT

Ignore the preceeding message, I found the solution by myself...
Newsgroups: comp.lang.c
Subject: C interpreter for Unix
From: beppe@edy.elettra.trieste.it (Giuseppe Surace)
Date: 21 Aug 92 17:25:52 +0100
Distribution: world

  Does anyone know if in the free software exist a 'C interpeter' for Unix
  systems.

			Thanx in advance
			  Giuseppe Surace


Keywords: 

Newsgroups: comp.lang.c
From: lds@ccrl.nj.nec.com (Duan-Shin Lee)
Subject: Does anyone have experience with Sun ANSI c compiler?
Keywords: Sun ANSI
Organization: C&C Research Labs, NEC USA, Princeton, N.J.
Date: Thu, 13 Aug 92 20:08:37 GMT

Hi,
Does anyone have experience with SUN ANSI C compiler?
Sun claims that it supports quadruple precision floating
point operations.  I am wondering how fast these operations
are.  For example, if you compute the exponential function
for ten thousand times, what is the time difference required
between using double and quadruple ?

Please email your response to me at lds@ccrl.nj.nec.com.
Thank you very much.

Duan-Shin Lee
C&C Research Lab.
NEC USA




-- 
Duan-Shin Lee
C & C Research Lab, NEC USA
Tel:(609)951-2456
lds@ccrl.nj.nec.com
From: rsahu@triton.unm.edu (Raikanta Sahu)
Subject: Simple C question 
Date: Sat, 22 Aug 92 06:22:23 GMT
Organization: University of New Mexico, Albuquerque
Distribution: unm

I thought the following piece of code was perfectly legal.
--------------------------------------------------------
#include <stdio.h>

main()

{
 char s[] = "Hello world!" ;

 printf("OK \n" ) ;
}
---------------------------------------------------------

Here is what I get from the compiler.

ccom: Error: test.c, line 6: no automatic aggregate initialization
       char s[] = "Hello world!" ;
      ----------^
ccom: Error: test.c, line 6: illegal lhs of assignment operator
       char s[] = "Hello world!" ;
      ---------------------------^


Can anybody please explain why automatic initialization is not accepted ?

Thanks.

-sahu,r 
Newsgroups: comp.lang.c
From: tmyoung@rodan.acs.syr.edu (Thomas M. Young)
Subject: cc optimizer problem
Organization: Syracuse University, Syracuse, NY
Date: Fri, 21 Aug 92 14:53:23 EDT

I've got a program that does a bunch of number crunching inside some 
nested loops.  When I try to optimize the program via the cc -O option,
the program doesn't execute any of the instructions inside the innermost
loop.  When compiled with the -g option, the code runs without a hitch.
Does anybody out there have any idea why this might be happening? I'd
really like to avoid hand-optimizing this code.

--
Tom Young                                         tmyoung@rodan.acs.syr.edu
From: robert@isgtec.com (Robert Osborne)
Newsgroups: comp.lang.c
Subject: Re: Macros for ANSI prototypes
Date: 20 Aug 92 15:04:10 GMT

darcy@druid.uucp (D'Arcy J.M. Cain) writes:
#robert@isgtec.com (Robert Osborne) writes:
#>darcy@druid.uucp (D'Arcy J.M. Cain) writes:
#>> [...] The K&R code just becomes one of the stages of the
#>> compilation. [...]
#>>     ANSI C --> K&R C --> Assembler --> a.out
#>> You see the K&R is simply an intermediate stage and is thrown out after
#>> along with the .s and .o files.
#>Gaak!  This is gross.
#>You can't throw away the K&R step because you need the source for
#>debuggers.
#
#Who said you had to throw it away immediately?  In fact the example I use
#later involved copying the K&R code to another box and compiling there.  By
#"after" I meant "after it is no longer needed."  I kind of thought that was
#obvious.

Well since the K&R code is always needed while the .s and .o are not
this wasn't that 'obvious'.

#>The K&R systems are used also for development; there are enough
#>problems with the compilers and with the speed of compile without
#>adding yet another preprocessing step.
#>
#>It would only take one major bug introduced by the ANSI to K&R
#>step to remove the developer time savings.
#
#If your tools don't work then get ones that do.  I mean if we are going
#to discuss the use of various tools we have to assume that cpp does macro
#processing by the accepted rules, cc compiles C code and all the other
#tools perform as advertised.  I don't think it matters where a major bug
#is introduced.  If a tool is broken it will cost the developer time.
#Just ask anyone who does development using compilers from you-know-who
#with a version number of x.0.

Get a grip.  I was just saying the cost of the added complexity of a
extra preprocessing step has to be weighed against the cost of not
using it.   If the minor difficulties caused by cpp were not grossly 
overwhelmed by being able to conditionally compile and #include files
would you use it?  If the development ease/speed gains from using C
didn't overwhelm the power of assembler would you use C?

#>I do not consider this even remotely as elegant as the prototype macros.
#
#My way:
#
#int foo(char *, int);
#...
#int foo(char *bar, int n)
#{
#  /* stuff */
#}
#
#Your way: (I don't have the original message but I think this is close)
#
#int foo(__DECL((char *, int));
#...
#int foo __DEFN((char *bar __ int n))
#{
#  /* stuff */
#}

I agree the original method, not mine, suggested was very (VERY!) ugly.
I don't use the ANSI style for function arguments so...
My way:

    --- in some include ---
    #ifdef HAS_PROTOTYPES
    #define PROTO(s) s
    #else
    #define PROTO(s) ()
    #endif
    
    --- in junk.c ---
    int foo PROTO((char *, int));

    int foo(bar, n)
	char *bar;
	int n;
    {
    }
    
Since prototypes are generated by a tool (mkptypes in our case)
this is easier and more elegant (in my mind and that in those of
the rest of our group) than either of the above methods.

Rob.
--
Robert A. Osborne   ...!uunet.ca!isgtec!robert or robert@isgtec.com
Newsgroups: comp.lang.c,comp.programming
From: bjp2399@ultb.isc.rit.edu (B.J. Prusha )
Subject: Re: A LITTLE BRAINTEASER...
Originator: bjp2399@ultb
Organization: Rochester Institute of Technology
Date: Thu, 13 Aug 1992 18:04:36 GMT


Howdy, I'm not that much of a C guru, but a friend and I think the
code below should do it.  There are no structures, but recursion 
is used.  We haven't tried this yet, so don't slap us too hard if we
made a major foopah.  Assume all includes are made.

void do_it();

main ()

{
   char ch;

   getch(ch);
   if (ch != EOL)
   {
       do_it();
       printf("%c",ch);
   }
   
}

void do_it()

{

  ch char;

  getch(ch);
  if (ch != EOL)
   
   {   do_it();
       printf("%c",ch);
   }
}




NOTE: this will not print out an end of line character.  This should do
the same thing if using files instead of lines, with a few mods.


-- 
Remember, thou art mortal
Newsgroups: comp.lang.c
From: thompson@atlas.socsci.umn.edu (T. Scott Thompson)
Subject: Re: POWER OF LARGE NUMBERS
Reply-To: thompson@atlas.socsci.umn.edu
Organization: University of Minnesota
Date: Mon, 17 Aug 1992 18:00:22 GMT

dave@cs.arizona.edu (Dave Schaumann) writes:

>In article <QUANSTRO.92Aug16132245@mari.StOlaf.edu>, quanstro@mari (goon) writes:
>>In article <1992Aug16.052157.1991@organpipe.uug.arizona.edu> dave@cs.arizona.edu (Dave Schaumann) writes:
>>
>>   >>	Does any one know how to raise power of possibly 100 digits 
>>   >>to possibly 100 digits. Any algorithm or code will be appriciated.
>>   >
>>   >Is there any hope of solving this?
>>
>>   Only if you're willing to give up most of the significant digits.
>[...]
>>
>>You just contradicted yourself. It is possible. It just takes more
>>memory and more programming (you can't expect the hardware to handle
>>this sort of case). Check out the man page for mp (a set of arbitrary
>>precision arith. functions) if you are on a UNIX system. There is also
>>a GNU version of these functins.

>Take a look at the specification again.  We're talking about calculations
>that will yield results with 10 ** 10 ** 100 digits.  Try to do that with
>a so-called `arbitrary precision' software package, and you'll find out
>that it wants memory for that precision.  We're talking about numbers so
>hugely vast we can't even talk about how many *digits* they have without
>using exponents!  A megabyte has (about) 10**6 bytes in it, so we're talking
>about 10**94 megabytes just to hold the result.  Suppose you can load 1
>megabyte in a 10**-12 seconds (new warp-drive technology), it would take you
>10**78 seconds to load your value.  That's more than 10**71 years.

>So I restate my point: yes, you can write software to deal with numbers
>that large, but NOT without dropping 99.9% of your accuracy.

Actually it is worse than that since the number of digits needed is
(roughly!)
                10 ** (10 ** 100)

which is _much_ larger than (10 ** 10) ** 100.  (Remember folks, 
exponentiation is _not_ associative!)

I am no physicist but I'll go out on a limb with this conjecture:

No "arbitrary precision" package can compute the solution because the
number of bits needed to represent the answer exceeds the number of
atoms in the universe.

(Well, I suppose we could wait for the new "quantum" computers to
come along. :-) )
From: f88ho@efd.lth.se (Hans Olsson)
Newsgroups: comp.lang.c
Subject: Re: A LITTLE BRAINTEASER...
Date: 15 Aug 92 11:53:52 GMT
Organization: Lund Institute of Technology, Sweden

In article <josef.713800013@uranium> Josef Moellers <mollers.pad@sni.de> writes:
>In <Bswt31.7zC@research.canon.oz.au> andy@research.canon.oz.au (Andy Newman) writes:
>
>>aet@mullian.ee.mu.OZ.AU (bert thompson) writes:
>>>hi!
>>>
>>>i have a small problem that's been bugging for a while now.
>>>
>>>here's a program that reverses input from the keyboard:
>>>
>>>main()
>>>	char ch = getchar();
>>        ^^^^^^^
>>	NOT AGAIN!
>>>	if (ch == EOF)
>>>		;
>>>	else {
>>>		main();
>>>		putchar(ch);
>>>	}
>>>}
>>>
>>>the interesting thing about the program is that it uses no data structures
>>>(structs, arrays, pointers, etc..), to do its thing. everything is thrown
>>>on the stack.
>
>>Another interesting thing about this program is that its broken!
>
>>So how may machines does this work on? Want to run it on something
>>without memory protection and let the little sucker recurse and
>>recurse...
>
>It'll run perfectly on systems that have signed characters!
>EOF usually is -1, so '\377' will expand to -1.

It won't run perfectly on systems that have signed characters,
because it can't handle files containing '\377'.


(BTW:
A simple solution to the original problem
is of course to take the line-reversing program and
pipe the result to the file-reversing program!)