HDTenEightyP/NetNews huggingface dataset:
From: ted@ocsmd.ocs.com (Ted Scott)
Subject: Re: character pointers in funtion calls
Organization: Online Computer Systems, Inc.
X-Newsreader: Tin 1.1 PL5
Date: Fri, 18 Dec 1992 17:36:40 GMT

der Mouse (mouse@thunder.mcrcim.mcgill.edu) wrote:
: In article <BzD1w3.1z5@ocsmd.ocs.com>, ted@ocsmd.ocs.com  I wrote:
: > Step 1: Get a good C primer and look at the memory sections, then
: > walk through the code you present here and see if you can find some
: > of these problems:
: Hm, I think you might do well to follow this advice yourself in a
: couple of cases.
Only a couple?!? My I *am* _starting_ to learn this dialect. I don't give
advice I won't follow, doesn't mean I remember everything. 

:>:   return (i);            <- (and implicitly free the memory on the stack
:>                              where i had a happy albiet brief life) 
:>                              returning the old value of i which may or may 
:>                              not be overwritten when printf uses the stack. 
:
: No, no, no.  It is correct that the storage allocated to the variable i
: goes away when f returns.  This *does not matter*, since no reference
: to that storage survives.  The return statement returns the value that
: was stored there, not, as you seem to think, a pointer to the storage
: in question. 
Yes, of course, must a been thinking of that other language.
(a waist is a terrible thing to mind... or something).

<At the white board: returns are by value, not by reference...>

: That value is itself a pointer, but it points to a string
: literal, which does *not* go away.
And is usually read only storage. 

Thanks.
--

-Ted (I been a bad boy, Abbot) Scott          
tscott@ocsmd.ocs.com           I was told that I'm a P.C. person:
(301) 601-2252                               Politically Challenged, that is.
Xref: sparky comp.lang.c:18586 comp.unix.bsd:10347
From: cbusch@ub.d.umn.edu (Chris)
Newsgroups: comp.lang.c,comp.unix.bsd
Subject: Segmentation faults
Date: 17 Dec 1992 22:00:22 -0600
Organization: University of Minnesota, Duluth
Distribution: world
NNTP-Posting-Host: ub.d.umn.edu




Hi,
    Why is the following code producing a segmentation fault???
I am compiling this code on an Encore Multimax running UMAX 4.3 Unix.
Please send replies to CBUSCH@ub.d.umn.edu.


void cls()
{
   printf("\33[2J");
}

void gotoxy(x,y)
int x,y;
{
   printf("\33[%d;%dH",y,x);
}

void writexy(x,y,s)
{
   printf("\33[%d;%dH%s",y,x,s);
}
   
void start1()
{
   printf("\33[?25l"); /*BTW what does this do with an ANSI terminal?*/
}

void start2()
{
   printf("\33[1;24r"); /*BTW what does this do with an ANSI terminal?*/
}

void end()
{
   printf("\33[?25h"); /*BTW what does this do with an ANSI terminal?*/
}


int main()
{  /*This code is for testing the above for use with terminals*/
   char s[80];
   int x,y;
   start1(); 
  start2();
   do{
      writexy(1,1,"enter x y string:");
      scanf("%d%d%s",&x,&y,s);
      writexy(x,y,s);
   }while(s[0]!='#');


   end();
   return 0; 
}
From: mikey@ontek.com (euphausia superba)
Newsgroups: comp.lang.c
Subject: Re: Locating A Record Within A File
Date: 11 Dec 92 19:42:33 GMT
Organization: Ontek Corporation -- Laguna Hills, California

In comp.lang.c, martelli@cadlab.sublink.org (Alex Martelli) writes:
| mitch@nosc.mil (Ray Mitchell) writes:
| 
| :Assume that a file consists of a series of records and it is desired to
| :locate a specific record.  My assumption is that in the general case it
| :is not portable to simply fseek or fsetpos to (sizeof(record) * recordnumber)
| :since a file can contain more than just the individual bytes forming each
| :record.  Instead, the file should start with a table of offsets, initially
| :determined by ftell or fgetpos, which may be later given back to fseek or
| :fsetpos to locate the desired record.
| 
| [discussion of solutions to problem of growing the size of the
|  lookup table]

I sense a fallacy here.  Since the lookup table itself is part
of the file, you can't index into it any more portably than you
could have indexed into the records themselves.  The overhead of 
reading is that of sequentially reading the table of record
offsets until finding the offset for the record you're interested
in.  This will be faster if the size of the entries in the index
is significantly smaller than the size of the records, but it will
be a far cry from fseek.

Possible ways of achieving the random-access behavior you describe
are (a) carrying around an fpos_t wherever you would have previously
wanted to have "record number" or (b) constructing a lookup table
in memory ahead of time.

       the krill, i guess off_t is out of the question

Newsgroups: comp.lang.c
From: champion@cch.coventry.ac.uk (Alun)
Subject: Re: Question to test general C knowledge
Organization: Coventry University, Coventry, UK.
Date: Fri, 18 Dec 1992 15:31:34 GMT

In article <1992Dec18.093717.7661@jussieu.fr> fred@trot.ibp.fr (Frederic PETROT) writes:
~d_north@ondec.lonestar.org (David G. North, CCP) writes:
~>Or better yet, what is the type and value of the following expression:
~>  "this is a test"[4]
~
~try this one (due to a friend of mine):
~
~main()
~{
~   printf("%c", unix["abc"]);
~}
~

Why does this print 'b' ??
I could understand the indexing with numbers but with [unix] ??

Please help a confused individual.

I consider myself competent with the C and find it difficult to understand
why anyone would ask these type of questions in an interview - surely these
don't show someones level of competence.

Regards

  -Alun
  
-- 
  *I'm as bad as the worst - but thank God(?) I am as good as the best.*
    *People who think they know everything annoy those of us that do.*
A.Champion                |  That's an interesting point, in the sense of
(champion@uk.ac.cov.cch)  |    being very not interesting at all. - The Liar
From: Mike.Tedder@f181.n363.z1.fidonet.org (Mike Tedder)
Newsgroups: comp.lang.c
Subject: Zmodem source
Date: Thu, 17 Dec 92 16:58:00 PDT
Organization: FidoNet node 1:363/181

 > > Hello.  I lost your message in a HD crash, but I was able to
 > > read part of it. You said something about you knew where I
 > > could get 'C' source for Zmodem? And as a trade, I would give
 > > you the VAX/VMS version?  Am I correct?  Thanks.

 > Although I may be able to get the 'C' source for you... you
 > must be thinking of someone else. I have no use for VAX/VMS
 > stuff at all...

Sorry... wrong person... oh well.... How soon do you think you could have the source for me?  Thanks.

--  
        Mike Tedder  -  via FidoNet Node: 1:363/42
             UUCP:  -  ...tarpit!tous!business!181!Mike.Tedder
             ARPA:  -  Mike.Tedder@f181.n363.z1.fidonet.org
Newsgroups: comp.lang.c
From: monty@intuitiveedge.com (Montgomery Zukowski)
Subject: recursive variable arguments, can it be done?
Reply-To: monty@intuitiveedge.com
Organization: The Ohio State University
Date: Mon, 14 Dec 1992 20:52:26 GMT

Let's say I have two functions f1(...) and f2(...) which take a variable  
argument lists.

Is there any way to have f1 call f2 function like printf() by passing part of  
the variable argument list (the last part), or if not, then the whole thing?

In other words how could I call
f2(va_list ap) 

instead of 

f2(arg1,arg2,arg3,arg4, etc...)

I know that printf() has another function vprintf() which has that sort of  
functionality, but I wonder if there is a simpler way to specify a va_list so  
I don't have to have another function declaration like vprintf does for  
printf.

I'm using gcc.

Please email me responses since I don't read this newsgroup often.
monty@IntuitiveEdge.com

Thanks,
Monty
Newsgroups: comp.lang.c
From: misar@rbg.informatik.th-darmstadt.de (walter misar)
Subject: Re: WHAT WENT WRONG?
Date: Fri, 18 Dec 1992 16:34:46 GMT
Organization: TH Darmstadt

In article <10441.107.uupcb@cutting.hou.tx.us>, david.brooks@cutting.hou.tx.us (David Brooks)  writes:
> The following code is intended to compute the factorial of a given
> number. Unfortunately it gives weird results for numbers larger than 12
> or so... Does anyone have an idea why? I tried compiling it under Huge
> memory model and still the same effects.
> 
> 
> #include <stdio.h>
> 
> main()
> {
>     double x, y;
> 
>     printf("\nEnter number to factorialize:");
>     scanf("%d", &x);
> 
>     for(y=x-1;y>1;y--) x*=y;
> 
>     printf("\nFactorial= %d\n", x);
> }
> 
> 
> Undoubtedly the problem comes from playing with numbers that are too
> big. Is there something obvious that I am overlooking here? Or is there
> some hidden secret for dealing with big numbers that only rocket
> scientists and C gurus are aware of? Any help is appreciated!

Just use %f instead of %d (means decimal integer) in scanf and printf.

-- 
Walter Misar                        It is impossible to enjoy idling thoroughly
misar@rbg.informatik.th-darmstadt.de       unless one has plenty of work to do.
Newsgroups: comp.lang.c
Subject: Re: Question to test general C knowledge
From: a_rubin@dsg4.dse.beckman.com (Arthur Rubin)
Date: 15 Dec 92 19:46:52 GMT
   <1992Dec12.224541.29854@thunder.mcrcim.mcgill.edu> 
 <1992Dec13.045828.1714@crd.ge.com> <1992Dec14.150401.1283@cae.prds.cdx.mot.com> <1992Dec15.144244.3559@crd.ge.com>
Organization: Beckman Instruments, Inc.

In <1992Dec15.144244.3559@crd.ge.com> volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe) writes:

>In article <1992Dec14.150401.1283@cae.prds.cdx.mot.com>, dan@cae.prds.cdx.mot.com (Dan Breslau) writes:
>|> volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe) writes:
>|> 
>|> >You miss the point. One of them will happen first. Does the second
>|> >one constitute a modification? Look at it this way: When the "++" operator
>|> >is evaluated, the machine throws a card up in the air with the words
>|> >"put 3 in i" on it. That's the side effect associated with the "++" operator.
>|> >And since the value of the "++i" subexpression is "3", when the "="
>|> >operator is evaluated, the machine throws up another card in the air with
>|> >the words "put 3 in i" on it. The side effects are applied in the order
>|> >in which they fall. But since both side effects do the same thing, is
>|> >the object really being "modified" again when the second card falls?
>|> 
>|> No, really, you're missing the point.  The point is that you can't
>|> assume that the compiler will behave rationally just because common sense
>|> says it should.  The compiler will behave rationally _only_ where the
>|> ANSI standard says it should (modulo bugs and/or non-compliance.)
>|> 
>|> Dan Breslau
>|> dan@codex.com

>No, you're missing the point. Real compilers don't go out of their way 
>to take advantage of undefined behavior and cause trouble. If I had
>the expression "x = ++y", the compiler is going to generate some
>code for that. 

Nope, you're missing the point.  I admit, it seems unlikely, but the following
code could be generated for x = ++y;

mov   r,y
inc   r
mov   x,r
inc   y

If you replace x by y in that, you find that y is incremented twice.

Beside, the standard says it's undefined.

--
Arthur L. Rubin: a_rubin@dsg4.dse.beckman.com (work) Beckman Instruments/Brea
216-5888@mcimail.com 70707.453@compuserve.com arthur@pnet01.cts.com (personal)
My opinions are my own, and do not represent those of my employer.
My interaction with our news system is unstable; please mail anything important.
Newsgroups: comp.lang.c
From: brown@NCoast.ORG (Stan Brown)
Subject: Re: RFD: splitting comp.lang.c
Organization: Oak Road Systems, Cleveland Ohio USA
Date: Fri, 18 Dec 1992 08:21:42 GMT

In article <1992Dec16.153843.13370@cadkey.com> steveg@cadkey.com (Steve Gallichio) writes:
>In article <1992Dec16.151243.12903@cadkey.com> eric@cadkey.com (Eric Holtman) writes:
>>Therefore, I propose the following splits for this newsgroup
> 
>How about comp.lang.c.howdoigetunbufferedinputwhenusinggetchar ?

and comp.lang.c.i-cant-be-bothered-to-read-the-faq
and comp.lang.c.it-must-be-a-C-question-cause-i-write-in-C

-- 
Stan Brown, Oak Road Systems                      brown@Ncoast.ORG
"There are no good guys.  There's bad guys and worse guys.  The best one
can hope for is to defend the bad against the worse."
                                 -- {Almost History} by Christopher Bram
From: volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe)
Newsgroups: comp.lang.c
Subject: Re: Question to test general C knowledge
Date: 15 Dec 92 14:42:44 GMT
Reply-To: volpe@ausable.crd.ge.com
Organization: GE Corporate Research & Development

In article <1992Dec14.150401.1283@cae.prds.cdx.mot.com>, dan@cae.prds.cdx.mot.com (Dan Breslau) writes:
|> volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe) writes:
|> 
|> >You miss the point. One of them will happen first. Does the second
|> >one constitute a modification? Look at it this way: When the "++" operator
|> >is evaluated, the machine throws a card up in the air with the words
|> >"put 3 in i" on it. That's the side effect associated with the "++" operator.
|> >And since the value of the "++i" subexpression is "3", when the "="
|> >operator is evaluated, the machine throws up another card in the air with
|> >the words "put 3 in i" on it. The side effects are applied in the order
|> >in which they fall. But since both side effects do the same thing, is
|> >the object really being "modified" again when the second card falls?
|> 
|> No, really, you're missing the point.  The point is that you can't
|> assume that the compiler will behave rationally just because common sense
|> says it should.  The compiler will behave rationally _only_ where the
|> ANSI standard says it should (modulo bugs and/or non-compliance.)
|> 
|> Dan Breslau
|> dan@codex.com

No, you're missing the point. Real compilers don't go out of their way 
to take advantage of undefined behavior and cause trouble. If I had
the expression "x = ++y", the compiler is going to generate some
code for that. It's going to figure out what value needs to go in x, and
what value needs to go in y, and the code is going to generate the 
appropriate side effects in some order. If the "y" were changed to
an "x" in the source code, I would be very surprised if the resulting
object code differed by any more than the corresponding variable
substitution. In that case, the generated code will apply two side effects
to the same variable, in no particular order. In general, this would 
leave the final value indeterminate, but when those two side effects are 
identical, why would one expect a rational compiler to leave anything 
other than the """right""" answer in the variable? 

Now, someone else posted an example of the kind of code that a compiler
might generate for such an expression which would result in the
"""unexpected""" answer. However, I also raised an issue concerning
whether or not the expression *really* violates the shall-rule in
3.3, and that depends on the definition of the term "modify" as used
in section 3.3. As far as I can tell, no one has commented on that issue
yet. My rebuttal against his code example was that if the expression
in question could be shown to be conformant, then the generated code
violates the semantics of the value of an assignment expression, and
the implementation generating such code would be non-conformant.

-- 
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
Xref: sparky comp.lang.c:18263 comp.lang.c++:17868 comp.misc:4564
From: kdq@quest.UUCP (Kevin D. Quitt)
Newsgroups: comp.lang.c,comp.lang.c++,comp.misc
Subject: Re: What is Object Oriented Programming? Is C doomed?
Date: Sat, 12 Dec 92 09:51:25 PST
Reply-To: srhqla!quest!kdq
Organization: Job quest  (805) 251-8210,  So Cal: (800) 400-8210

hartman@ulogic.UUCP (Richard M. Hartman) writes:
> 
> OOP and C++ is NOT a "silver bullet", any more than "structured programming"
> was.  It is a new tool that gives us the potential for things that were
> more difficult before, but in and of itself does NOTHING.  That is the
> job of the software designer.  If it is done poorly, it is done poorly
> no matter what the language or paradigm.

    This is the heart of the matter:  OOP is another device which
helps mediocre programmers to produce good code.  Good programmers can
also make use of it, but they've *always* produced good code.


 _
Kevin D. Quitt      96.37% of all statistics are made up.     srhqla!quest!kdq
Newsgroups: comp.lang.c
From: oz@ursa.sis.yorku.ca (Ozan Yigit)
Subject: Re: Need good hashing functions
Organization: York U. Student Information Systems Project
Date: Mon, 14 Dec 1992 17:44:33 GMT

Stephen Schow writes:

   I am looking for hashing functions for a school project.  If anyone has any
   ideas and/or book suggestions that can help me find some good hashing
   functions to use in my project, I would appreciate it.

   Note - We are hashing single english words.

The following is required reading:

	B. J. McKenzie, R. Harries, T. Bell.
	Selecting a Hashing Algorithm
	Software - Practice and Experience,
	20(2):209-224, Feb 1990.

Here are the functions used in that paper, from a posting by
raghu@norway.fishkill.ibm.com (Raghu Hudli) to comp.programming,
slightly re-formatted by me.

enjoy...	oz
---
With diligence, it is possible to | electric: oz@sis.yorku.ca
make anything run slowly. -T.Duff | ph:[416] 736 2100 x 33976

--- cut here ---

/*
 * return the least significant n bits of h
 */
static unsigned int
BITS(unsigned int h, unsigned int n)
{
	register int bits = 0;
	while (n--) {
		bits = bits << 1;
		bits += 1;
	}
	return (bits & h);
}

/*
 * ETH Modula-2 Cross Compiler
 * Recommended table length = 1699
 */
unsigned int
hasheth(const char *key)
{
	int tableLength = 1699;
	register unsigned int h = 0;
	register const char *c = key;

	while (*c)
		h = BITS(*c++, 8) * (h % 257) + 1;
	return (h % tableLength);
}

/*
 * GNU C preprocessor
 * Recomended table length=1403
 */
unsigned int
hashgnuccpp(const char *key)
{
	int tableLength = 1403;
	register unsigned int h = 0;
	register const char *c = key;

	while (*c)
		h = 4 * h + *c++;
	return (BITS(h, 31) % tableLength);
}

/*
 * GNU C compiler front end
 * Recomended table length=1008
 */
unsigned int
hashgnucc1(const char *key)
{
	int tableLength = 1008;
	register unsigned int h = 0;
	register const char *c = key;

	while (*c)
		h = 613 * h + *c++;
	return (BITS(h, 30) % tableLength);
}

/*
 * Portable C Compiler
 * Recomended table length=1013
 */
unsigned int
hashpcc(const char *key)
{

	int tableLength = 1013;
	register int h = 0;
	register const char *c = key;

	while (*c)
		h = 2 * h + *c++;
	return (((unsigned int) BITS(h, 15)) % tableLength);
}

/*
 * Unix 4.3BSD C preprocessor based
 * Recomended table length=2000
 */
unsigned int
hashcpp(const char *key)
{
	int tableLength = 2000;
	register int h = 0;
	register const char *c = key;
	register unsigned int index;

	while (*c)
		h = 2 * h + *c++;

	if ((index = h % 2000) >= 0)
		return (index % tableLength);
	else
		return (index % tableLength + 2000);
}

/*
 * AT&T C++ compiler based.
 * Recomended table length=257
 */
unsigned int
hashcplusplus(const char *key)
{
	int tableLength = 257;
	register unsigned int h = 0;
	register const char *c = key;

	while (*c)
		h = 2 * h + *c++;
	return (h % tableLength);
}

/*
 * ICON translator
 * Recommended table length = 257
 */
unsigned int
hashicon(const char *key)
{
	int tableLength = 257;
	register unsigned int h = 0;
	register const char *c = key;

	while (*c)
		h += BITS(*c++, 8);
	return (h % tableLength);
}
Newsgroups: comp.lang.c
From: mcdonald@aries.scs.uiuc.edu (J. D. McDonald)
Subject: Re: Questions about token merging and trigraphs
Organization: UIUC SCS
Date: Thu, 17 Dec 1992 20:58:00 GMT

In article <1992Dec17.183045.2737@sal.wisc.edu> alan@sal.wisc.edu (Alan Watson) writes:

>In article <mcdonald.610@aries.scs.uiuc.edu> mcdonald@aries.scs.uiuc.edu (J. D. McDonald) writes:
>>That last it **UTTERLY WRONG**. I found that **many** of my programs
>>broke!! **MANY** .. and they had lots of occurences of ??!, 
>>??) ??(, ??[. and ??] in them, in **critical** places!!!
>>
>>I chose them as delimiters in a special ASCII file format for data,
>>and chose them as no one would be likely to try to use them as
>                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>actual strings in the text-comment portion of the file!! They are coded
>>into the program in strings .. and it would not have been so bad had
>>not the idiotic ANSI committee decided that they would be replaced in
>>strings as well as code!!

>It sounds like your code was broken in the first place; never make 
>assumption about what your users might and might not do.

The users have nothing to do with this. They are files created by the
program; the're encrypted binary files from text source. I, and I alone,
write this source (its art, not programming :-) )

Doug McDonald
From: kdq@quest.UUCP (Kevin D. Quitt)
Newsgroups: comp.lang.c
Subject: Re: WHAT WENT WRONG?
Date: Thu, 17 Dec 92 20:51:39 PST
Reply-To: srhqla!quest!kdq
Organization: Job quest  (805) 251-8210,  So Cal: (800) 400-8210

bketcham@stein.u.washington.edu (Benjamin Ketcham) writes:

>In article <10441.107.uupcb@cutting.hou.tx.us> david.brooks@cutting.hou.tx.us
>>     ... Does anyone have an idea why? I tried compiling it under Huge
>>memory model and still the same effects.                          ^^^^
> ^^^^^^^^^^^^
>
>AAAAAAAAAAAAGGGHHHHHHH!!!!!!!
>

>>    printf("\nEnter number to factorialize:");
>>    scanf("%d", &x);
             ^^
    What?, no AAAAAAAAAAAAGGGHHHHHHH!!!!!!! here?

>>    printf("\nFactorial= %d\n", x);
>>}                        ^^ 
>
>AAAAAAAAAAAAGGGHHHHHHH!!!!!!!



 _
Kevin D. Quitt      96.37% of all statistics are made up.     srhqla!quest!kdq
Newsgroups: comp.lang.c
From: dfuller@portal.hq.videocart.com (Dave Fuller)
Subject: Re: C Programming Question  -- Quiz
Organization: VideOcart Inc.
X-Newsreader: Tin 1.1 PL3
Date: Fri, 11 Dec 1992 18:24:08 GMT

dkeisen@leland.Stanford.EDU (Dave Eisen) writes:
: >: Example 2 was fine. In fact, all three programs were fine
: >: other than the fact that main didn't return a value.

My apologies for declaring this questionable.
I think i posted a little quickly.

Dave Fuller
dfuller@portal.hq.videocart.com


Newsgroups: comp.lang.c,gnu.gcc.help
From: steve@taumet.com (Steve Clamage)
Subject: Re: How precise is preprocessor math? (I'm using gcc)
Organization: TauMetric Corporation
Date: Fri, 18 Dec 1992 17:12:24 GMT

tom@flood.com (Tom Chatt) writes:

|volpe@ausable.crd.ge.com writes:
|| [someone else's confusion about cpp deleted] 
|| 
|| This simply expands to:
||      printf("Q1=%g q=%q\n", 2.*6371.0/GRIDSPACE_KM*(1.+sin(70.)), q);
|| 
|| And then the compiler evaluates it, or more likely, just the
|| constant expression part of it. (It probably isn't likely that it
|| evaluates sin(70) at compile time, but it's allowed to.)

|The compiler is allowed to evaluate routine calls at compile time???
|I think not! ...

|If Chris Volpe was suggesting the more limited proposition that
|certain standard calls, such as sin(), are "known" to the compiler,
|that's plausible, but still seems dubious. "sin" is not a resrved
|word in C, and nothing would prevent me from writing my own "sin()"
|routine which did something completely different.

In Standard C, "sin" (and each standard library function) is reserved
for use as a global identifier.  (ANSI Standard, section 4.1.2.1)
This means that you may not portably write your own global function
called "sin", even when you don't use any math functions.

The C implementor has considerable freedom in designing and
implementing the C library and the compiler interface to it.  It
might happen that some functions share data or otherwise rely on
internals of other functions.  A replacement for a library function
could then cause other functions to fail.  It also might happen
that functions were grouped into a single monolithic library.  It
would not be possible to replace just one.  Both of these scenarios
are allowed by the Standard.

You don't have to agree that either of these designs is a good idea.
Nonetheless, there might be very good reasons for choices like these
on a particular system, giving a good performance advantage.

The compiler is indeed allowed to evaluate the above expression at
compile time, but I don't know of any compilers which do.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.lang.c