HDTenEightyP/NetNews huggingface dataset:
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: fwrite+fread of pointer
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Fri, 13 Nov 1992 10:18:13 GMT

In article <15935@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>	#include <stdlib.h>
>	#include <stdio.h>
>	int main(argc, argv) int argc; char **argv; {
>		char dummy;
>		char *p = &dummy;
>		FILE *f = fopen("WORK", "w+b");
>		fwrite(&p, sizeof p, 1, f);
>		rewind(f);
>		fread(&p, sizeof p, 1, f);
>		fclose(f);
>		printf("%d\n", p == &dummy);
>		exit(0);
>	    }
>What I want to know is whether, assuming nothing else goes wrong, the
>program _must_ print 1 or whether it may print 0.

ANSI 4.9.2, page 126 lines 33 to 34:  "Data read in from a binary stream
shall compare equal to the data that were earlier written out to that
stream, under the same implementation."  So I almost say it must print 1.

The clause "under the same implementation" can only mean that the file
might be read by a different program (or different invocation of the same
program) than the one that wrote the file, and as long as those were
translated by the same implementation, the data must remain equal.
But of course, in a different program, the variable "p" is likely to be
at a different location.  We should reasonably expect this to be an
exception, but the standard doesn't hint at an exception.  This troubles me.

The real reason I am troubled is that until now, I thought that it was
theoretically possible to implement garbage collection in C.  Each pointer
would have to be a handle and each object would need additional information
so that when an object is moved, all of the pointers in the program could
be updated automatically.  But this would yield a second exception to this
part of the standard -- and it could yield a 0 for Dr. O'Keefe's program.
Perhaps an interpretation ruling should say how many exceptions are allowable.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"It's been a lovely recession."
Newsgroups: comp.std.c
From: tim@osiris.usi.utah.edu (Tim Burns 581-4439)
Subject: Allocating memory like an array
Originator: tim@osiris.usi.utah.edu
Reply-To: tim@osiris.usi.utah.edu (Tim Burns 581-4439)
Organization: School of Engineering and Applied Sciences, UCLA
Date: Thu, 5 Nov 92 20:39:39 GMT


Hello,

I am trying to call LINPACK-type (ESSL) routines from a C-program and the
problem I have is that the way malloc allocates memory is incompatible 
with the way that arrays are allocated.  Instead of having to declare my
arrays at the beginning of a program, I want to be able to allocate
memory dynamically.  Right now, when I allocate my array using the 
standard array allocation:  double A[L][M], where L and M are constants,
everything works fine.  (Whether or not dbx can see that A is an array is 
a litmus test)

(dbx) print A
(
(0.0, 0.0, 0.0, 0.0)
(1.0, 1.0, 1.0, 1.0)
(2.0, 2.0, 2.0, 2.0)
)
(dbx) print &A
0x2ff7f7a0
(dbx) print &A[0][0]
0x2ff7f7a0
(dbx) print &A[0][1]
0x2ff7f7a8
(dbx) print &A[1][0]
0x2ff7f7c0

However, if I declare A using the numerical recipes suggestion of memory
allocation, 

  double **m;

  m = (double **) malloc((unsigned) (nrh-nrl+1) * sizeof(double*));
  if (!m) myerror("dmatrix", "allocation failure making pointers to rows.",
                  FAIL_DIE);
  m -= nrl;

  for ( i = nrl; i <= nrh; i++ ) {
    m[i] = (double *) malloc((unsigned) (nch - ncl + 1) * sizeof(double));
    if (!m[i]) myerror("dmatrix", "allocation failure allocating rows.",
                       FAIL_DIE );
    m[i] -= ncl;

I get a declaration which is completely different.  (What we have is a set of
pointers to each row in A when m is returned to point at &A.  The memory I
allocate is not guaranteed to be continues but I have experimented quite a 
bit with declaring matrixes this way, and I have always gotten continues 
memory.

Does anyone out there have a routine which does dynamic memory allocation
which forces allocation __exactly__ the same as array allocation?  Or,
can anyone give me a tip on how I might begin constructing such a utility?

Thank you for any help,

Tim Burns


-- 
  *__T__*     Even the most brilliant scientific discoveries will in time
    _i_       change and perhaps grow obsolete, as new scientific mani-
   */m\*      festations emerge.  But Art is eternal; for it reveals the
              inner landscape which is the soul of man.  --Martha Graham
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: is fflush(stdin) conformant???
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Thu, 5 Nov 1992 01:54:51 GMT

In article <MGK.92Nov2131855@cedar.sql.sybase.com> mgk@sql.sybase.com (Michael Keirnan aka Joe Cool) writes:
>the instructor has advised flushing stdin in conjunction with using scanf()
>to "flush the unwanted newline."

This works on some implementations.  Ask the student if the course is
supposed to teach an implementation-dependent style.  If it's supposed
to teach ANSI C, the student should demand a refund of the tuition.

>So what sayeth the gospel on the subject?

Undefined.  (But implementations are allowed to define it if they wish.)
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"It's been a lovely recession."
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: A declarations without any declarators.
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Fri, 6 Nov 1992 11:13:56 GMT

In article <1992Nov6.013858.736@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>Can we all agree that:
>	typedef float;
>... violates the first constraint in section 3.5?

I can agree, but ALL of us?  Good luck  :-)

>Good.  Now what about these odd looking declarations:
>	typedef struct S;
>	typedef enum { red, green, blue };
>It appears that these are standard conforming, yes?

Yup.  There's a famous line saying something like, rules that would prohibit
ugly code would also prohibit good code.  Now this raises the question of
why the first constraint in section 3.5 is there in the first place.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"It's been a lovely recession."
Xref: sparky comp.std.c:2996 comp.lang.c:16230
From: mikef@dcs.ed.ac.uk (Mike Fourman)
Newsgroups: comp.std.c,comp.lang.c
Subject: Array size checks
Date: 9 Nov 92 17:59:29 GMT
Organization: Department of Computer Science, University of Edinburgh

3.3.2.2 Function Calls
"Each argument shall have a type such that its value may be assigned to an 
object with the unqualified version of the type of its corresponding 
parameter."

3.3.16.1 Simple Assignment
"both operands are pointers to qualified or unqualified versions of
compatible types, ..."

[or other options]

Does this mean that if I have the following

int big_array[10] ;
void function_using_small_array( int argument_array[5] ) ;
void function_using_ptr_to_small_array( int (*ptr_to_argument_array)[5] ) ;

then the following behaviour (cf gcc) is conforming??

function_using_small_array( big_array ) ; /* no warning -- O dear! */

function_using_ptr_to_small_array( &big_array ) ; /* warning -- OK */

Do any compilers warn about the first usage? Shouldn't they?

-- 
Prof. Michael P. Fourman                     email        mikef@dcs.ed.ac.uk
Dept. of Computer Science                    'PHONE (+44) (0)31-650 5198 (sec)
JCMB, King's Buildings, Mayfield Road,              (+44) (0)31-650 5197
Edinburgh EH9 3JZ, Scotland, UK                 FAX (+44) (0)31 667 7209
-------------------------------------------------------------------------------
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: Allocating memory like an array
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Fri, 6 Nov 1992 07:46:16 GMT

In article <1992Nov5.203939.1323@fcom.cc.utah.edu> tim@osiris.usi.utah.edu (Tim Burns 581-4439) writes:
>(dbx) print A

That's not a standards question.  However, the remaining portion is
borderline (IMO) and maybe useful to enough people, here goes.

>if I declare A using the numerical recipes suggestion of memory allocation, 
>  double **m;
>  m = (double **) malloc((unsigned) (nrh-nrl+1) * sizeof(double*));
>  if (!m) myerror("dmatrix", "allocation failure making pointers to rows.",
>                  FAIL_DIE);
>  m -= nrl;
>  for ( i = nrl; i <= nrh; i++ ) {
>    m[i] = (double *) malloc((unsigned) (nch - ncl + 1) * sizeof(double));
>    if (!m[i]) myerror("dmatrix", "allocation failure allocating rows.",
>                       FAIL_DIE );
>    m[i] -= ncl;
>The memory I allocate is not guaranteed to be continues but I have
>experimented quite a bit [...] always gotten continues memory.

You haven't experimented enough, I promise you.

  double **m;
  double *m0;
  size_t nr = nrh - nrl + 1;  /* or int or whatever, same as i, nrl, etc. */
  size_t nc = nch - ncl + 1;
  m0 = malloc(nr * nc * sizeof(double));
  if (!m0) myerror("dmatrix", "allocation failure making matrix.", FAIL_DIE);
  m = malloc(nr * sizeof(double*));
  if (!m) myerror("dmatrix", "allocation failure making pointers.", FAIL_DIE);
  for ( i = nrl; i <= nrh; i++ ) {
    m[i] = m0 + i * nc;
  }
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"It's been a lovely recession."
From: bhoughto@sedona.intel.com (Blair P. Houghton)
Newsgroups: comp.std.c
Subject: Re: Allocating memory like an array
Date: 6 Nov 92 22:14:27 GMT
Organization: Intel Corp., Chandler, Arizona
NNTP-Posting-Host: alfalfa.intel.com

In article <1debc4INNieg@chnews.intel.com> bhoughto@sedona.intel.com (Blair P. Houghton) writes:
[...crap deleted...]
>				--Blair
>				  "Isn't this just a little basic?"

No, it's just a little plain wrong.

				--Blair
				  "Try 'a lot.'"
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: Typedefing built in data types
Followup-To: alt.religion.computers
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Thu, 5 Nov 1992 02:05:44 GMT

In article <1992Nov3.093404.9124@odin.diku.dk> jkut@diku.dk (Jonatan Kutchinsky) writes:
>we simulate a Motorola 68000 processor. We decided decided to typedef the
>built in types char, short, and long to new names, BYTE, WORD, and LWORD.

The standard permits these typedefs.  The standard does not rule on style.

>The reason why we want to do this, is that we want to emphasize the
>difference between the data used to control the simulation, etc.,
>and the data that the simulated microprocessor is processing. We are using
>ints, chars and longs to do everything else than containing data from the
>simulated memory and registers, and while it is processed by instructions.

I personally think that looks very nice.  Some famous programs have similar
typedefs for certain kinds of portability, and some people have wished that
other famous programs would have similar typedefs for data formats that go
over a network, etc.  But this topic belongs in alt.religion.computers.

>The problem is that our teacher has the opinion that this use of typedef is
>a bad thing, and that it makes the program less readable when you do not
>know that LWORD really stands for long, without looking in the header file.

It is true that you don't know that LWORD really stands for long, without
looking in the header file.  Also you don't know how many bits long has,
without looking in the C implementation's manuals.  You have to read or else
hope that it happens to be the correct length for the simulated processor.
This topic belongs in, I don't know, maybe comp.software-eng.

Your teacher is allowed to believe that this use of typedef is a bad thing
(at least, I think Danish laws allow freedom of belief :-)
Followups are directed to alt.religion.computers.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"It's been a lovely recession."
From: bhoughto@sedona.intel.com (Blair P. Houghton)
Newsgroups: comp.std.c
Subject: Re: on "use", and the lvalue-ness of string literals
Date: 8 Nov 92 22:30:00 GMT
Organization: Intel Corp., Chandler, Arizona
NNTP-Posting-Host: alfalfa.intel.com

In article <18277@ksr.com> jfw@ksr.com (John F. Woods) writes:
>If you cannot deduce that "foo" has array type from "The multibyte character
>sequence is used to initialize an array of static storage duration and length
>just sufficient to contain the sequence", then I suggest you quietly put your
>keyboard down and go and lie down until the urge to program passes.

What I deduce from that is that the "multibyte character
sequence" is not itself an array but an indicator of the
initial values of an actual array.  The sentence says
nothing about the type of the source of the characters,
it gives rather that of the destination.

And the nap was nice, thanks.

>The only time a string literal does not become an anonymous array is when it

"Does not become?"  Not "is not?"  You contradict yourself.

Your eyelids are growing heavy.

>is used as an initializer (read "Initialization 3.5.7").  In all other cases
>it is an array and has array type.  Therefore, when it appears in an lvalue
>context, it is not a modifiable lvalue (because lvalues of array type are
>not modifiable (see 3.2.2.1 Lvalues and Function Designators)),

It is not a modifiable lvalue because the standard explicitly
forbids attempts to modify it.

You are getting sleepy, very sleeeeeepy.

>and therefore
>"foo" = "bar"; violates the Constraint in section 3.3.16 that "An assignment
>operator shall have a modifiable lvalue as its left operand", an therefore
>a compiler *must* issue a diagnostic.  The statement about modifying string
>literals doesn't enter into it.

The cookies of the bull are many and near.  This is only
one of a number greater than one of reasons that this
assignment is bogus.  I would not attempt to tell a compiler
writer which reason to deduce first; it could upset his
syntax tree.

You are aSLEEP!

>>E.g.,
>>	"foo"[2] = 'g';
>>results in undefined behavior.
>
>But no diagnostic is required in this case, because no Constraint is violated.

When I snap my fingers, you will awake.

				--Blair
				  "Is that a TAMBOURINE I see behind you?"
Newsgroups: comp.std.c
From: jones@ils.nwu.edu
Subject: New Ph.D. Program
Organization: institute for the learning sciences
Date: Mon, 9 Nov 1992 20:14:55 GMT

T h e   L  E  A  R  N  I  N  G    S  C  I  E  N  C  E  S    P h. D.   P r o g r
a m


Preparing individuals for productive work and a   high quality of life in
today's society is a complex  challenge for schools and corporations. To meet
this challenge, Northwestern University has established a unique Ph.D. program
in the Learning Sciences. Its purpose is to advance the research and
development of innovative educational structures and technologies.

Research in the Learning Sciences is aimed at creating environments that offer
all students a rich variety of opportunities for learning to think effectively,
both within and outside of formal learning settings. Graduate student and
faculty research efforts are supported by a multimedia, networked computing 
infrastructure and an unusual commitment to developing technologies that
function effectively within their intended settings. 

The Learning Sciences is a synthesis of computational and social science
disciplines including artificial intelligence, cognitive and developmental
psychology, educational research, linguistics, computer science, anthropology
and fields that develop strategies for teaching complex subject matter. 

Through research, field work and apprenticeships, the Ph.D. program will
prepare its graduates to assume leadership roles in advancing the scientific
understanding and systematic practices of learning and teaching.

Students are eligible for competitively-awarded multi-year funding. To qualify
for financial aid, candidates should apply by January 15, 1992. Applications
received after that date may be  considered. Individuals with relevant teaching
experience or a strong academic  background in a field related to the Learning
Sciences are encouraged to apply. For  application materials or for further
information, contact:

Professor Roy Pea
Ph.D. Program Chair 
The Learning Sciences 
Northwestern University
1890 Maple Avenue
Evanston, IL  60201
phone: 708-491-8152
fax:    708-491-5258
email: jones@ils.nwu.edu
 
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: Yet another question about va_start.
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Fri, 6 Nov 1992 11:40:51 GMT

In article <1992Nov6.015516.2350@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>In 4.8.1.1 it says:
>	"The parameter paramN is the identifier of the rightmost
>	parameter..."
>Is this a restriction of standard conforming programs?

This time I'll get it write.
s/standard conforming programs/strictly conforming programs/whew

Yes.

>On standard conforming implementations?

How could it be?  The program is the one with code invoking va_start().

>Note that some implementations permit:
>	#include <stdarg.h>
>	va_list ap;
>	void foobar (int arg1, ...) {
>		va_start (ap, any bloddy thing you want!$#^% );
>	}

Some implementations permit dereferencing null pointers too.
There's no Constraints paragraph in section 4.8.1.1.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"It's been a lovely recession."
Newsgroups: comp.std.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: fwrite+fread of pointer
Organization: TauMetric Corporation
Date: Fri, 13 Nov 1992 18:44:21 GMT

ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:

>I would like to know what the standard says about the following program:

[ writes the contents of a pointer with fwrite, reads it back with fread ]

>What I want to know is whether, assuming nothing else goes wrong, the
>program _must_ print 1 or whether it may print 0.

[ that is, whether the value read == the value written ]

ANSI C Standard 4.9.2:

"Data read in from a binary stream shall compare equal to the data that
were earlier written out to the stream, under the same implementation."

In the example, the file was opened in binary mode, so this applies.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: mcsbc2gw@dct.ac.uk
Newsgroups: comp.std.c
Subject: reg
Date: 5 Nov 92 10:41:51 GMT
Organization: Dundee Institute of Technology


C PROGRAMS are difficult to analyse at the best of times

Does anyone know how to pass the address of an array of structs, to a scanf
statement without it returning a NULL pointer assignment. The array of structs
were passed to the procedure GET_INPUT and I figure it well may be something to
do with the fact that I've a floating point variable in the struct. Or I
suspect it maybe something to do with the address of the pointer....

Please can anyone help me? I am no novice to C but this one has really got me
buggered! 

Waiting your reply

MCSBC2GW

Graeme Wright at D.I.T.


Newsgroups: comp.std.c
From: brown@NCoast.ORG (Stan Brown)
Subject: Re: is fflush(stdin) conformant???
Organization: Oak Road Systems, Cleveland Ohio USA
Distribution: comp
Date: Fri, 6 Nov 1992 01:50:45 GMT

In article <MGK.92Nov2131855@cedar.sql.sybase.com> mgk@sql.sybase.com (Michael Keirnan aka Joe Cool) writes:

ANSI sec 4.9.5.2 (ISO 7.9.5.2, I believe):

"int fflush(FILE *stream);

"Description

"If stream points to an output stream or an update stream in which the
most recent operation was not input, the fllush function causes any
unwritten data for that stream to be delivered to the host environment
to be written to the file; otherwise, the behavior is undefined. ..."

In John Woods's felicitous image, undefined behavior means that the
program can do anything, including causing demons to fly into (or is it
out of?) your nose.

Someone who is teaching a course and advocates fflush(stdin); may be
teaching about some vendor's version of C, but is not teaching an ANSI C
course.
-- 
Stan Brown, Oak Road Systems                      brown@Ncoast.ORG
Cleveland, Ohio, USA
"Only the futility of the first flood prevents God from unleashing another."
            --Chamfort, as quoted in Claude Arnaud's {Chamfort: A Biography}
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.std.c
Subject: Re: on "use", and the lvalue-ness of string literals
Date: 5 Nov 92 14:40:17 GMT

In article <1d9stpINNq4e@chnews.intel.com>, bhoughto@sedona.intel.com (Blair P. Houghton) writes:
> I'm pleased to see, though, that Larry Jones has taken over
> Doug's old post of "Committee Member with Chip on Shoulder."

Anything to make you happy, Blair. :-)

I'm afraid I have been a mite bit tetchy lately -- must be old age. 
I'll try to tone it down.

Now, what was that you were saying about adding pointers?!?
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com  or  ...uunet!sdrc!larry.jones
It seems like once people grow up, they have no idea what's cool. -- Calvin
From: andrew@teslab.lab.oz.au (Andrew Phillips)
Newsgroups: comp.std.c
Subject: Re: Allocating memory like an array
Date: 9 Nov 92 23:26:43 GMT
Organization: Technology Services, Chief Secretary's Dept, Sydney

This should really be in comp.lang.c, shouldn't it?

tim@osiris.usi.utah.edu (Tim Burns 581-4439) writes:
: Does anyone out there have a routine which does dynamic memory allocation
: which forces allocation __exactly__ the same as array allocation?  Or,
: can anyone give me a tip on how I might begin constructing such a utility?

The syntactic equivalence of pointers and arrays is a major problem of C.

	/* array of L arrays of M doubles */
	double A[L][M];

gives a continguous block of memory, as does:

	/* pointer to array of M doubles */
	double (*A)[M];

	/* Allocate L arrays of M doubles */
	A = (double (*)[M])malloc(L * sizeof(*A));
	if (L != 0 && M != 0 && A == (double (*)[M])0) .... //error


/* cf. char s[10]; and char *s = malloc(sizeof(*s)); ... */

However, the array of pointers to arrays example you gave (from
Numeric Recipes in C?) has a lot to commend it.  One major advantage
is if the array is large there may not be enough contiguous memory to
allocate a two-dimensional array but it may be allocated in smaller
chunks of one-d arrays.

Of course, if you are calling library routines that require two-d
arrays there's not much you can do.
-- 
Andrew Phillips (andrew@teslab.lab.oz.au) Phone +61 (Aust) 2 (Sydney) 287 6551
From: bhoughto@sedona.intel.com (Blair P. Houghton)
Newsgroups: comp.std.c
Subject: Re: on "use", and the lvalue-ness of string literals
Date: 6 Nov 92 17:58:08 GMT
Organization: Intel Corp., Chandler, Arizona
NNTP-Posting-Host: alfalfa.intel.com

In article <2221@sdrc.COM> scjones@thor.sdrc.com (Larry Jones) writes:
>In article <1d9stpINNq4e@chnews.intel.com>, bhoughto@sedona.intel.com (Blair P. Houghton) writes:
>> I'm pleased to see, though, that Larry Jones has taken over
>> Doug's old post of "Committee Member with Chip on Shoulder."
>
>Anything to make you happy, Blair. :-)

Well, that's the net.party.line... :-)

>Now, what was that you were saying about adding pointers?!?

Uh, er, well, ...

Oh!  Uh, the, uh, beagles were getting a bit lonely
while I was at work on all-nighters, and, uh, I said
I was thinking of getting some pointers to keep
them company...ehh, yeah, that's it...that's the ticket.

				--Blair
				  "Got some retired
				   greyhounds, instead."
Newsgroups: comp.emacs