HDTenEightyP/NetNews huggingface dataset:
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.std.c
Subject: Re: calloc()
Date: 10 Sep 1992 16:41:03 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <14455@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>Now I wonder:  if I want to allocate an array with elements of known size
>but with number of elements not known until run-time, and if I don't really
>care what the initial contents are, _is_ there something in the standard to
>make
>	p = calloc(NumberOfElements, sizeof *p)
>better than
>	p = malloc(NumberOfElements * sizeof *p) ?

calloc() could compatibly be defined as:

void *calloc (size_t nelem, size_t size) {
    void *result;
    result = malloc(nelem * size);
    if (result)
        memset(result, 0, nelem * size);
    return result;
}

>I thought I knew how C works, but if one is using a C that checks
>subscripts at run-time, what _might_ it do with a dynamic array allocated
>using malloc()?  I'm not asking so much about actual systems as about what
>the standard requires/permits.

An array allocated with malloc() is conceptually an array of N 1-byte
elements.  If calloc() were the primitive, malloc() could be defined as:

void *malloc (size_t size) {
    return calloc(size, 1);
}

(this zeroes the returned memory unnecessarily, but there's nothing that
says that malloc() can't return zeroed memory).

C's rules for automatic conversion between an array and a pointer to its
first element, and its rules for equivalence of array[subscript] and
array+subscript, guarantee that there's no real need to distinguish whether
a block of memory was allocated as an array or not.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: How is struct assignment defined (idle query)?
Date: 8 Sep 92 13:19:44 EDT

msb@sq.sq.com (Mark Brader) writes:
>> > Does ANSI say that structure assignment is done by member-wise copy or
>> > by bit-wise copying?
>(As I said earlier, I do not believe that the answer to this is clear.)
>> How would a standard-conforming program tell the difference?
>Since the bitwise copy is a superset of the member-wise copy, a conforming
>program might be able to tell the difference *only if* the standard
>requires bitwise copying and the implementation copies member-wise.

And *if* the Standard required programs to have wheels, "cat.c" would be
a station wagon.  I don't see any hint in the Standard that bitwise copying
is required.  I do find that:

	(3.5.2.1) "As discussed in 3.1.2.5, a structure is a type consisting
	of a sequence of named members, whose storage is allocated in an
	ordered sequence..."
	(3.1.2.5) "A _structure type_ describes a sequentially allocated
	nonempty set of member objects, each of which has an optionally
	specified name and possibly distinct type."
	[ note that 3.5.2.1 specifies that the unnamed *member objects*
	must be bit-field members ]

So, I would argue that while a structure *object* may contain unnamed internal
padding, the *type* does not.  So, when a structure *value* is evaluated,
because it has an associated *type*, the *value* does not (logically) contain
padding, and need not be copied when the = operator drops it into its
destination.

Failing any words from the standard to the contrary, I conclude that any
program which depends on bitwise copying of compiler-inserted padding is
depending on something for which the standard omits any explicit definition of
behavior, and therefore the program opens up the Pandora's Box of Undefined
Behavior (1.6).
Newsgroups: comp.std.c
From: gordon@sneaky.lonestar.org (Gordon Burditt)
Subject: Re: How is struct assignment defined (idle query)?
Organization: Gordon Burditt
Date: Sat, 5 Sep 1992 07:03:55 GMT

>Does ANSI say that structure assignment is done by member-wise copy or
>by bit-wise copying?

How would a standard-conforming program tell the difference?

>The reason I ask is that if it is a bit-wise copy, then any padding in
>a struct would have to have some (presumably inplementation defined)
>value written to it so that the padding bytes could be copied.

No, either the implementation has to use a method of copying that
will copy uninitialized memory (without causing faults, etc.), OR
it has to arrange that padding is initialized, OR it has to
do an element-by-element copy.  (Warning:  element-by-element
copies had better avoid problems with floating-point trapping NaNs
if the implementation supports them.)  I suspect most
implementations choose the first possibility.


					Gordon L. Burditt
					sneaky.lonestar.org!gordon
From: clive@x.co.uk (Clive Feather)
Newsgroups: comp.std.c
Subject: Re: struct hack, was Re: strcpy implementation question
Date: 7 Sep 92 10:49:32 GMT
Organization: IXI Limited, Cambridge, UK

In article <9209040741.AA16120@enet-gw.pa.dec.com> diamond@jit081.enet.dec.com (04-Sep-1992 1639) writes:
>In article <1992Sep4.015335.3612@thinkage.on.ca> dat@thinkage.on.ca (David Adrien Tanguay) writes:
>>diamond@jit081.enet.dec.com (03-Sep-1992 1325) writes:
>>>In article <PINKAS.92Sep2173635@skywalker.intel.com> pinkas@skywalker.intel.com (Israel Pinkas) writes:
>>>> The variable length struct is a hack.  There is nothing in the language that
>>>> prevents the compiler from performing bounds checking on accesses to name.
>>> Bounds checking is not allowed to affect output of a valid but ugly program.
>> I had the impression that the last time it came up here the conclusion was
>> that this trick was not sanctioned[...]  3.3.6 "Additive Operators"
>> says that you aren't guaranteed to go past the end of an array object,
> No (though it was the conclusion of some others) and yes, respectively.
> You can't go past the end of an array object.  But if malloc() or some other
> variable has defined the end of the actual array object, then the + operator
> can get you that far, regardless of the declared type that some other array
> variable had before getting flattened to a pointer.

But there is an intepretation that says that, given

    int a [5][5];

the access "a [1][6]" is illegal, because it goes past the bounds of the
array "a [1]". In other words, the declared type of the array does
restrict what can happen to a pointer derived from it.
-- 
Clive D.W. Feather     | IXI Limited         | If you lie to the compiler,
clive@x.co.uk          | 62-74 Burleigh St.  | it will get its revenge.
Phone: +44 223 462 131 | Cambridge   CB1 1OJ |   - Henry Spencer
Fax:   +44 223 462 132 | United Kingdom      |
From: clive@x.co.uk (Clive Feather)
Newsgroups: comp.std.c
Subject: Re: void expressions and volatile types
Date: 7 Sep 92 10:40:43 GMT
Organization: IXI Limited, Cambridge, UK

In article <BtnI48.D9I@twwells.com> bill@twwells.com (T. William Wells) writes:
> The problem is then what to do with statements like a; and a=b;
> when a is a volatile object. The first expression accesses a but
> then discards the value, which is fine. The other does NOT do
> what you'd expect, though. The reason is that the assignment has a
> value which is the value of a after the assignment, which can only
> be obtained by accessing a. Thus a=b results in a sequence like:
>
>	load b
>	store a
>	load a
>
> rather than the intended load and store.

Here's the mistake. The value of the expression can be obtained by
remembering the value stored into a - it is not necessary to re-fetch
it, even though a is volatile.

The storing of a value into a is a side-effect, and so takes place
sometime before the next sequence point. Any other change that takes
place to a (e.g. because it is a memory-mapped device) between the same
pair of sequence points counts as a double assignment, and is therefore
undefined, and therefore the implementation can do what it wants
(including not reading a after storing).

-- 
Clive D.W. Feather     | IXI Limited         | If you lie to the compiler,
clive@x.co.uk          | 62-74 Burleigh St.  | it will get its revenge.
Phone: +44 223 462 131 | Cambridge   CB1 1OJ |   - Henry Spencer
Fax:   +44 223 462 132 | United Kingdom      |
Newsgroups: comp.std.c
From: langevin@indian.bbn.com (Tim Langevin)
Newsgroups: comp.std.c
Subject: Memory alignment
Date: 15 Sep 1992 16:27:26 GMT
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Distribution: world
Reply-To: langevin@indian.bbn.com. (Tim Langevin)
NNTP-Posting-Host: bbn.com

I'd like the net.wisdom on this one...

   Is the following piece of code conforming ANSI C?
   Is there a better way to do this?

Thanks,

Tim Langevin


**start here**

#include <stddef.h>
#include <stdlib.h>

typedef union
{
  enum { red, green, blue } a;
  signed char b;
  unsigned char c;
  short d;
  unsigned short e;
  int f;
  unsigned int g;
  long h;
  unsigned long i;
  float j;
  double k;
  long double l;
  char * m;
} ALL_TYPES;

typedef struct 
{
  size_t size;
  void *next;
  ALL_TYPES aligner;
} HEADER;

#define TEST_SIZE 20

void *get_mem (size_t size);
void free_mem (void * mem_ptr);

int main (void)
{
    void * mem_ptr;
    mem_ptr = get_mem (TEST_SIZE);
    free_mem (mem_ptr);
    return 0;
}

void *get_mem (size_t user_size)
{
    void * mem_ptr;
    HEADER *header;

    mem_ptr = malloc (sizeof (HEADER) + user_size);
    header = (HEADER *) mem_ptr;
    header->size = user_size;
    header->next = 0;

    return (void *) ((char *)mem_ptr + sizeof(HEADER));
}

void free_mem (void * mem_ptr)
{
    free ( (void *) ((char *) mem_ptr - sizeof (HEADER)));
}



Newsgroups: comp.std.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: How is struct assignment defined (idle query)?
Organization: SoftQuad Inc., Toronto, Canada
Date: Sat, 5 Sep 92 16:50:14 GMT

> > Does ANSI say that structure assignment is done by member-wise copy or
> > by bit-wise copying?

(As I said earlier, I do not believe that the answer to this is clear.)

> How would a standard-conforming program tell the difference?

Since the bitwise copy is a superset of the member-wise copy, a conforming
program might be able to tell the difference *only if* the standard
requires bitwise copying and the implementation copies member-wise.
If that *is* the case, the following program is (I hope) strictly con-
forming, but prints "Failure!" on an implementation which has certain
alignment properties and which does member-wise copying.

	#include <stdio.h>
	#include <stdlib.h>
	#include <string.h>
	main() {
		static struct {char a; long b; char c;} zeroes, *p;
		p = malloc (sizeof *p); if (!p) return 1;
		memset (p, 'X', sizeof p);
		*p = zeroes;
		if (memchr (p, 'X', sizeof p)) printf ("Failure!\n");
		return 0;
	}

Untested code, because I don't have an ANSI C compiler handy.
-- 
Mark Brader		   "Doing the wrong thing is worse than doing nothing."
SoftQuad Inc., Toronto     "Doing *anything* is worse than doing nothing!"
utzoo!sq!msb, msb@sq.com		     -- Lynn & Jay: YES, PRIME MINISTER

This article is in the public domain.
Newsgroups: comp.std.c
From: cheselka@cactus.org (Michael R. M. Cheselka)
Subject: NaN
Organization: Capital Area Central Texas UNIX Society, Austin, Tx
Date: Mon, 7 Sep 1992 04:03:57 GMT

Today, I encountered this NaN thingy, as well as something else...but I
don't recall it off hand( Int or Inf or something...).  I looked in the 3rd
edition of "C a reference manual" by Harbison and Steele, but found
nothing.  Where is this stuff covered?  Is it IEEE?  Is it in the ANSI
standard?  How much is the ANSI standard, and where can I get it?
-- 
cheselka@cactus.org               N5UVV              Michael R. M. Cheselka
os9@gnu.ai.mit.edu        Hangs out on 145.21mhz       400 W. 34th st. #103
membership@cactus.org                                 Austin, TX 78705-1331
{...}!cs.utexas!cactus.org!cheselka (512)452-9412v ( 24hours answer. mach.)
Xref: sparky comp.std.c:2609 comp.sys.ibm.pc:525
From: matt@iquery.iqsc.COM (Matt Reedy)
Newsgroups: comp.std.c,comp.sys.ibm.pc
Subject: Change to time() fn?
Date: 11 Sep 92 19:48:27 GMT
Followup-To: comp.std.c
Organization: IQ Software Corp.

In looking at the Microsoft C 7.0 reference manual, we noticed the
time() function has changed its base value from 1/1/1970 to 12/31/1899.
Is this a Posix, ANSI, or other standards body change or is it Microsoft?
Will all the C vendors begin changing to this?

matt
-- 
Matthew Reedy                 UUCP: uunet!iquery!matt
IQ Software Corporation       Internet: matt@iqsc.COM
400 N Loop 1604 E, Suite 100
San Antonio, TX  78232        (512) 490 6684  Fax: (512) 490-3590
Newsgroups: comp.std.c
From: lou@xilinx.com (Lou Sanchez-Chopitea)
Subject: Scope of arguments in prototype
Keywords: scope, prototypes
Organization: Xilinx Inc.
Date: Mon, 14 Sep 1992 22:55:46 GMT

Hi,
    What is the scope of the arguments in a prototype? In particular do I have
to worry about "a" and "b" in:

    double func ( double a, int b);

if it is a header file, conflicting with variables a user might wish to define?

    	    	    	    	Cheers

    	    	    	    	    Lou



-- 
Lou Sanchez-Chopitea                EMail:  lou@xilinx.com
Software Engineer                   SnailMail:  2100 Logic Drive
SpeakMail: (408) 879-5059                       San Jose, CA 95124
FaxMail: (408) 559-7114
Newsgroups: comp.std.c
From: c4craig@teal.csn.org (Craig Anderson)
Subject: POSIX version of chsize/ftruncate?
Organization: Colorado SuperNet, Inc.
Date: Mon, 14 Sep 1992 21:01:09 GMT


How should I port a DOS call to chsize() to STD C / POSIX?

In SunOS and BSD/386 I find:

int ftruncate(int fd, off_t length)
  truncate a file to a specified length

In DOS Turbo C++ I find:

int chsize(int handle,k long size)
  Changes the file size.

Thanks for any suggestions,

Craig H. Anderson
C4 Network, Inc.
518 17th Street, Suite 1400
Denver, CO 80202
    (303) 825-8183
FAX (303) 893-6510
c4craig@csn.org
Newsgroups: comp.std.c
From: darcy@druid.uucp (D'Arcy J.M. Cain)
Subject: Re: calloc()
Date: Sun, 13 Sep 1992 14:23:40 GMT
Organization: D'Arcy Cain Consulting

steve@taumet.com (Steve Clamage) writes:
>That said, suppose we have a system where int and size_t are 16 bits,
>but it is possible to allocate an object bigger than 64K.  A

But isn't size_t guaranteed to be big enough to specify any object?  It
is stated in a kind of roundabout way in the standard (you have to follow
up sizeof) but I don't think there is any doubt that if an object can be
larger than 64K then size_t must reflect this.

-- 
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   |
Newsgroups: comp.std.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: calloc()
Organization: TauMetric Corporation
Date: Mon, 14 Sep 1992 17:54:31 GMT

darcy@druid.uucp (D'Arcy J.M. Cain) writes:

>steve@taumet.com (Steve Clamage) writes:
>>That said, suppose we have a system where int and size_t are 16 bits,
>>but it is possible to allocate an object bigger than 64K.  A

>But isn't size_t guaranteed to be big enough to specify any object?  It
>is stated in a kind of roundabout way in the standard (you have to follow
>up sizeof) but I don't think there is any doubt that if an object can be
>larger than 64K then size_t must reflect this.

size_t is the type returned by the sizeof operator.  I believe you
must be able to apply sizeof to any object you can declare.  Suppose
ints and size_t are each 16 bits, and the compiler rejects any attempt
to declare an object greater than 64K:
	int big    [32767];	/* OK */
	int bigger [32769];	/* ERROR: too big */
This could be a conforming implementation.

Now suppose that the implementor wants to allow access to extra
memory when it is available, and allows calls like
	calloc(1024, 100)	/* 100K allocation */
for example.  I don't think this violates any rules.  You can't
use sizeof to find the size of a dynamically allocated region.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: diamond@jit081.enet.dec.com (08-Sep-1992 0914)
Newsgroups: comp.std.c
Subject: Re: struct hack
Date: 8 Sep 92 00:14:51 GMT

In article <1992Sep07.104932.20060@x.co.uk> clive@x.co.uk (Clive Feather) writes:
>In article <9209040741.AA16120@enet-gw.pa.dec.com> diamond@jit081.enet.dec.com(04-Sep-1992 1639) writes:
>> You can't go past the end of an array object.  But if malloc() or some other
>> variable has defined the end of the actual array object, then the + operator
>> can get you that far, regardless of the declared type that some other array
>> variable had before getting flattened to a pointer.

>But there is an intepretation that says that, given
>    int a [5][5];
>the access "a [1][6]" is illegal, because it goes past the bounds of the
>array "a [1]". In other words, the declared type of the array does
>restrict what can happen to a pointer derived from it.

Is that an actual interpretation ruling or was that only someone's posted
opinion on Usenet?  The standard certainly does define [], +, and * in
sufficiently unambiguous terms.

If you have the actual texts of the interpretation rulings, would you
please kindly post them?

I am also curious as to the "officially" correct thing to do when an
interpretation ruling contradicts the standard (whether correcting an
error that everyone agrees was an error, or otherwise).
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."
From: karl@ima.isc.com (Karl Heuer)
Newsgroups: comp.std.c
Subject: Re: Scope of arguments in prototype
Keywords: scope, prototypes
Date: 15 Sep 92 22:48:05 GMT
Organization: Interactive Systems, Cambridge, MA 02138-5302

In article <1992Sep14.225546.4277@xilinx.com> lou@xilinx.com (Lou Sanchez-Chopitea) writes:
>Hi,
>    What is the scope of the arguments in a prototype? In particular do I have
>to worry about "a" and "b" in:
>    double func ( double a, int b);
>if it is a header file, conflicting with variables a user might wish to define?

Identifiers declared as formal arguments in a prototype declaration have very
short scope, so in that sense you're safe.  (This fact does cause problems if
you try to declare something like
	extern char *asctime(struct tm const *);
since the short scope prevents this from serving as the first declaration of
the struct tag; for this reason it's necessary to put the struct declaration
before the prototype, or at least predeclare the tag with
	struct tm;
to establish a scope.)

However, there's a different danger: the header may exhibit incorrect behavior
if the user, before including the header, has defined a *macro* with the name
|a| or |b|.  For this reason, it's better to leave out the identifiers in
declaration prototypes, or use names that are within your documented
namespace.  ("__a" works if this is part of the standard library.)

Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
Newsgroups: comp.std.c
From: eggert@twinsun.com (Paul Eggert)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: Twin Sun, Inc
Date: Fri, 11 Sep 1992 02:04:06 GMT

a_rubin@dsg4.dse.beckman.com (Arthur Rubin) writes:

>>	int a, b;
>>	long c;

>>	c = a * b;

>(peter commented further that this works on a PDP-11).
>Aside from there being no guarantee that "long" is longer than "int", I
>don't think it is LEGAL for ANSI C to do this

No, a conforming C implementation can use an n*n -> 2n multiplication
primitive in this case.  If (int) (a*b) would not overflow, then you
get the same answer either way, so the `as-if' rule applies; and if
(int) (a*b) would overflow, then the result is undefined, so the
implementation can do what it pleases, including delivering the
mathematically correct answer!
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.std.c
Subject: calloc()
Date: 10 Sep 92 09:10:24 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

I was correcting a student's C program today (I seem to be the debugger of
choice, not dbx...) and while pointing out that
	int *p;
	p = calloc(n, sizeof (int));
	p[0] = 20;
would go BOOM! if calloc() ran out of memory, I asked "why does it matter
that the new array be initialised to 0 bytes?"  The student said "it
doesn't, but I want an _array_, and I thought you had to use calloc()
for that, doesn't it keep an index?"  (In the student's vocabulary,
index turned out to mean "the number of elements".)

On looking in Plauger & Brodie (I _know_ it isn't the standard; I ordered
on through the department over a year ago) I find that they describe
malloc() as allocating "a data object"  and calloc() as allocating
"an array data object".

Now I wonder:  if I want to allocate an array with elements of known size
but with number of elements not known until run-time, and if I don't really
care what the initial contents are, _is_ there something in the standard to
make
	p = calloc(NumberOfElements, sizeof *p)
better than
	p = malloc(NumberOfElements * sizeof *p) ?

If there is, I'll switch to calloc() immediately.  In particular, I have
been doing things like

	q = malloc(strlen(p)+1);
	assert(q);
	strcpy(q, p);
	... use q[i] ...

and some of the recent discussion about the old variable-length struct hack
have me wondering whether this is strictly legitimate; should I use calloc()
even here?  I thought I knew how C works, but if one is using a C that checks
subscripts at run-time, what _might_ it do with a dynamic array allocated
using malloc()?  I'm not asking so much about actual systems as about what
the standard requires/permits.
-- 
You can lie with statistics ... but not to a statistician.
Newsgroups: comp.std.c
From: eggert@twinsun.com (Paul Eggert)
Subject: Re: NaN
Organization: Twin Sun, Inc
Date: Mon, 7 Sep 1992 06:25:06 GMT

cheselka@cactus.org (Michael R. M. Cheselka) writes:

>Today, I encountered this NaN thingy....

NaN and Infinity are not part of the C Standard.
They're part of the IEEE floating point standard (IEEE Std 754-1985).
The exact relationship between IEEE floating point and Standard C
is still being discussed, but in the meantime your best bet is to
read the IEEE floating point standard.  Unlike the C Standard,
it's short and easy to follow.
From: ratinox@splinter.coe.northeastern.edu (Richard Pieri/Stainless Steel Rat)
Newsgroups: gnu.emacs,comp.emacs
Subject: dired rmail
Date: 7 Sep 92 19:23:05 GMT
Reply-To: ratinox@meceng.coe.northeastern.edu
Followup-To: gnu.emacs
Organization: 3WA, Boston Office. Or Nu Meta Chi. Take your pick.
X-Get-A-Clue: Have two, they're small.
X-Signature-Virus-Protection: Version 1.51
X-Posting-Software: GNUS 3.14.1 [ NNTP-based News Reader for GNU Emacs ]

A while back, someone asked about being able to run Rmail on a file in a
dired mode buffer. So I was hacking around and figured it couldn't be that
difficult to do, so...

(defun dired-rmail ()
  "Run Rmail on this file."
  (interactive)
  (rmail-input (dired-get-filename)))

It can be bound to "R" inside dired-mode hook with

(setq dired-mode-hook
      (local-set-key "R" 'dired-rmail))

--Rat

||||| | | | |  |  |  |   |   |    |    |    |   |   |  |  |  |  | | | | | |||||
                                                   __        ___ 
Richard Pieri, Northeastern's Stainless Steel Rat/   | /| / /   | The Worlds
Internet: ratinox@meceng.coe.northeastern.edu   /__  |/ |/ / /| | Welfare Works
    UUCP: ...!northeastern.edu!meceng!ratinox  /   | /| / / / | | Association:
  BITNET: UA_RLP@NUHUB{.BITNET}               /__  |/ |/ / /  | | I will solve
  USNail: 14 Westdale RD  Holbrook, MA 02343 /   | /| / / /___| | any problem
 ICBMnet: 42 deg 1 min N, 71 deg 0 min W    /    |/ |/ /_//_____| for you.
Newsgroups: comp.emacs