HDTenEightyP/NetNews huggingface dataset:
From: blume@kastle.Princeton.EDU (Matthias Blume)
Newsgroups: comp.std.c
Subject: Re: Allocating memory like an array
Date: 6 Nov 92 21:44:46 GMT
Reply-To: blume@kastle.Princeton.EDU (Matthias Blume)
Organization: Dept. of Computer Science, Princeton University

In article <1debc4INNieg@chnews.intel.com>, bhoughto@sedona.intel.com
(Blair P. Houghton) writes:
|> In article <1992Nov5.203939.1323@fcom.cc.utah.edu>
tim@osiris.usi.utah.edu (Tim Burns 581-4439) writes:
|> >memory dynamically.  Right now, when I allocate my array using the 
|> >standard array allocation:  double A[L][M], where L and M are constants,
|> 
|> What you see is that `A' has a type compatible with `(double *)',
|> whereas what the _Numerical_Recipes_ method does is create
|> `m' as compatible with `(double **)'.
|> 
|> All you need to do is allocate enough space for the
|> two-dimensional array.  C's array-memory mapping is flat,
|> in row-major order.
|> 
|> You want L rows of M columns of doubles, so you need
|> 
|> 	m = (double *) malloc ( L * M * sizeof(double) );
|> 
|> and now `m' is compatible with `A'.
|> 
|> Accesses to `m' can now be made using C's array-access syntax;
|> That is,
|> 
|> 	int row, col;
|> 	...
|> 
|> 	m[row][col]
|> 
|> gives the number at row and col.
|> 
|> 	m[row][col+1]
|> 
|> gives the next number in `m', and
|> 
|>         m[row+1][col]
|> 
|> gives the number in the next row, i.e., L elements away from
|> the number in this row of `m'.
|> 
|> 				--Blair
|> 				  "Isn't this just a little basic?"

Haven't we seen this kind of wrong explanation only few weeks ago in
comp.lang.c?
How shall the poor compiler know, after defining

	double **m;

that m[x][y] means an element, which is x*M+y elements away from the
origin of m?  What you need is either to declare

	double (*m) [M];

which doesn't give you the freedom to have variable dimensions except
for L, or

	double *m;
	# define access(matrix,x,y,dim) ((matrix) [(x) * (dim) + (y)])

which has to be used like:

	m = malloc (L * M * sizeof (double));

	... access (m, x, y, M) ...

Of course, you may want to ``hide'' ``m'' and ``M'' inside access.
In ANSI C you can write

	# define m(x,y) (m[(x) * M + (y)])

because the ANSI C preprocessor will not go into a recursion on m.
With this kludge you can use ``m'' almost like ever:

	... m (x, y) ...

instead of
	... m [x][y]

Enjoy!
-Matthias
Newsgroups: comp.std.c
From: rfg@netcom.com (Ronald F. Guilmette)
Subject: Yet another question about va_start.
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Fri, 6 Nov 1992 01:55:16 GMT

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?  On standard
conforming implementations?  Both?  Neither?

Note that some implementations permit:

	#include <stdarg.h>

	va_list ap;

	void foobar (int arg1, ...)
	{
		va_start (ap, any bloddy thing you want!$#^% );
		/* ... */
	}

-- 

// Ron ("Loose Cannon") Guilmette
// uucp: ...uunet!lupine!segfault!rfg
// New new motto:  Quality control is a state of mind.
//   misc.forsale.computers ad, circa 2007:
//       Used Cray wrist watch for sale; 25 bucks or best offer.
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.std.c
Subject: fwrite+fread of pointer
Date: 13 Nov 92 06:51:59 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

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

	#include <stdlib.h>
	#include <stdio.h>

	int main(argc, argv)
	    int argc;
	    char **argv;
	    {
		char dummy;
		char *p;
		FILE *f;

		f = fopen("WORK", "w+b");
		p = &dummy;
		fwrite(&p, sizeof p, 1, f);
		rewind(f);
		fread(&p, sizeof p, 1, f);
		fclose(f);
		printf("%d\n", p == &dummy);
		exit(0);
	    }

In order to save space I have omitted to test the results of fopen(),
fwrite(), and fread(), tests which I would not omit in practice.

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

Newsgroups: comp.std.c
From: rfg@netcom.com (Ronald F. Guilmette)
Subject: A different question about va_start & va_end.
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Fri, 6 Nov 1992 01:45:00 GMT

Must a standard conforming implementation accept:

	#include <stdarg.h>

	int i;
	int j;
	va_list ap;

	void foo (int bar, ...)
	{
		i = (va_start (ap, bar), 99);
		j = (va_end (ap), 88);
	}

In other words, may a programmer safely assume that invocations (or
expansions) of va_start and va_end are themselves expressions?

The function declarations shown in 4.8.1.1 and 4.8.1.2 seem to suggest
that the answer is yes.

-- 

// Ron ("Loose Cannon") Guilmette
// uucp: ...uunet!lupine!segfault!rfg
// New new motto:  Quality control is a state of mind.
//   misc.forsale.computers ad, circa 2007:
//       Used Cray wrist watch for sale; 25 bucks or best offer.
Newsgroups: comp.std.c
From: Christopher.Vance@adfa.oz.au (Christopher JS Vance)
Subject: Re: A different question about va_start & va_end.
Originator: cjsv@ccadfa.cc.adfa.oz.au
Organization: Computer Science, University College, UNSW/ADFA, Canberra, Australia
Date: Mon, 9 Nov 1992 00:34:30 GMT

In article <BxAL1r.J3r@jrd.dec.com> diamond@jit.dec.com (Norman Diamond) writes:
| In article <1992Nov6.014500.1353@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
| >In other words, may a programmer safely assume that invocations (or
| >expansions) of va_start and va_end are themselves expressions?
| >The function declarations shown in 4.8.1.1 and 4.8.1.2 seem to suggest
| >that the answer is yes.
| 
| 4.8.1, page 123 lines 17 to 19, says that va_start and va_arg must
| be macros, while va_end may be either macro or identifier.  However,
| if we interpret the function declarations as specifying usage syntax,
| then I would say that they must be expressions, as you say.
| 
| The va_list ap; declaration must be moved inside the function.
| 4.8, page 123 lines 11 to 12.  Ah wait a minute.  The function has to
| have this declaration, not necessarily a definition.  So you can keep
| the file scope one (with external linkage at that) and just copy it
| into the function as well.  I wonder if this is a bug (different rule
| from what was intended) in the standard.

Past practice on a Pyramid in the (partially) related varargs.h was
that va_end was simply a closing brace, while va_start was some gnarly
stuff with an extra opening brace.  I guess they relied on people
putting va_start and va_end in the right places, matching them
appropriately, and always requiring the va_end, which some lazy people
leave out on many architectures.  Pyramid have changed this now.

I certainly would never expect to use va_start and va_end other than
as equivalents of statements, unless I knew chapter and verse of the
standard which said explicitly that it was okay to treat them as
expressions.  Even then, not until all my obsolete machines go away...

Since Pyramid will apparently never ship a stdarg.h for the machine
I'm using, despite shipping a compiler which groks (some?) prototypes,
I'll never know.

-- Christopher

Disclaimer: I can't even afford a copy of the standard.  Either one.
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Newsgroups: comp.std.c
Subject: Re: Allocating memory like an array
Date: 7 Nov 92 10:48:30 GMT
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo

In article <1debc4INNieg@chnews.intel.com> bhoughto@sedona.intel.com (Blair P. Houghton) writes:
>In article <1992Nov5.203939.1323@fcom.cc.utah.edu> tim@osiris.usi.utah.edu (Tim Burns 581-4439) writes:
>>memory dynamically.  Right now, when I allocate my array using the 
>>standard array allocation:  double A[L][M], where L and M are constants,

>What you see is that `A' has a type compatible with `(double *)',

Reread the section on compatibility.  In most expressions this A would decay
into a pointer of type double* (some would say it decays into a constrained
subtype of some form that isn't described very well in the standard...), so
it's close, but it's better to omit false red herrings.

>whereas what the _Numerical_Recipes_ method does is create
>`m' as compatible with `(double **)'.

This is sort of necessary, if he wants to use C-like syntax to access the
elements.  He needs Iliffe vectors as well, in order to do that.

>All you need to do is allocate enough space for the two-dimensional array.
>C's array-memory mapping is flat, in row-major order.

And construct a way to access each element with his desired syntax.  If he
uses your method, he has to construct AND USE macros to compute the address
of each element, instead of using C-like syntax to access each element.

>You want L rows of M columns of doubles, so you need
>	m = (double *) malloc ( L * M * sizeof(double) );
>and now `m' is compatible with `A'.

I guess your declaration was    double *m;

>Accesses to `m' can now be made using C's array-access syntax; That is,
>	int row, col;
>	m[row][col]
>gives the number at row and col.

m[row] gives the number at row, in the one-dimensional array that was
allocated.  That is, if a number has been stored there first.

m[row][col] gives a diagnostic for violating the Constraint in 3.3.2.1,
followed by undefined behavior such as (usually) denial of execution.
For the second subscript, either m[row] or col is required to be a pointer.
--
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: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.std.c
Subject: Re: reg
Date: 10 Nov 92 04:14:21 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <1992Nov5.104151.1038@dct.ac.uk>, mcsbc2gw@dct.ac.uk writes:
> Does anyone know how to pass the address of an array of structs, to a scanf
> statement without it returning a NULL pointer assignment.

I guess "a scanf statement" means "an expression which is a call to scanf()". 
I don't know what it means "to return a NULL pointer assignment".
But most of alll, I don't understand why anyone would _try_ to pass the
address of an array of structs to scanf().  There is nothing that scanf()
could possibly do with it.  What kinds of arguments does scanf() want?
Apart from the format control string, which is const char *,
there are two kinds of arguments:
    pointers to (arrays of) characters for %c, %s, and %[
    pointers to SINGLE NUMBERS for the other formats.
Plauger&Brodie 1989 has a nice table on p115, "Scan Format Specifiers".
	
If you have
	struct foo {int i; float f;} arr[10];
it might make sense to pass
	&arr[k].i
or	&arr[k].f
but never (arr) on its own.

> Please can anyone help me?  I am no novice to C
With the utmost possible respect, the wording of the question makes me doubt
this assertion.  Why not post a larger fragment of the code, and post it to
comp.lang.c?

Newsgroups: comp.std.c
From: rfg@netcom.com (Ronald F. Guilmette)
Subject: A declarations without any declarators.
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Fri, 6 Nov 1992 01:38:58 GMT

Can we all agree that:

	typedef float;

... violates the first constraint in section 3.5?

Good.  Now what about these odd looking declarations:

	typedef struct S;
	typedef enum { red, green, blue };

It appears that these are standard conforming, yes?


-- 

// Ron ("Loose Cannon") Guilmette
// uucp: ...uunet!lupine!segfault!rfg
// New new motto:  Quality control is a state of mind.
//   misc.forsale.computers ad, circa 2007:
//       Used Cray wrist watch for sale; 25 bucks or best offer.
Newsgroups: comp.std.c,comp.lang.c
From: dkeisen@leland.Stanford.EDU (Dave Eisen)
Subject: Re: Array size checks
Organization: Sequoia Peripherals, Inc.
Date: Mon, 9 Nov 92 19:21:55 GMT

In article <BxGnB6.5nt@dcs.ed.ac.uk> mikef@dcs.ed.ac.uk (Mike Fourman) writes:
>
>int big_array[10] ;
>void function_using_small_array( int argument_array[5] ) ;
>
>Do any compilers warn about this usage? Shouldn't they?
>

Yeah, I think they should. Because while what you wrote is
perfectly legal and standard C, it is probably not what you 
meant. Compilers are free to warn about anything they like,
as long as they generate correct code for these legal, but
dubious, constructs. 

I have no idea if in fact any compilers do warn about this 
usage.


-- 
Dave Eisen                               Sequoia Peripherals: (415) 967-5644
dkeisen@leland.Stanford.EDU              Home:                (415) 321-5154
       There's something in my library to offend everybody. 
          --- Washington Coalition Against Censorship
From: bhoughto@sedona.intel.com (Blair P. Houghton)
Newsgroups: comp.std.c
Subject: Re: Allocating memory like an array
Date: 6 Nov 92 17:52:04 GMT
Organization: Intel Corp., Chandler, Arizona
NNTP-Posting-Host: alfalfa.intel.com

In article <1992Nov5.203939.1323@fcom.cc.utah.edu> tim@osiris.usi.utah.edu (Tim Burns 581-4439) writes:
>memory dynamically.  Right now, when I allocate my array using the 
>standard array allocation:  double A[L][M], where L and M are constants,

What you see is that `A' has a type compatible with `(double *)',
whereas what the _Numerical_Recipes_ method does is create
`m' as compatible with `(double **)'.

All you need to do is allocate enough space for the
two-dimensional array.  C's array-memory mapping is flat,
in row-major order.

You want L rows of M columns of doubles, so you need

	m = (double *) malloc ( L * M * sizeof(double) );

and now `m' is compatible with `A'.

Accesses to `m' can now be made using C's array-access syntax;
That is,

	int row, col;
	...

	m[row][col]

gives the number at row and col.

	m[row][col+1]

gives the next number in `m', and

        m[row+1][col]

gives the number in the next row, i.e., L elements away from
the number in this row of `m'.

				--Blair
				  "Isn't this just a little basic?"
Newsgroups: comp.std.c
From: mjn@pseudo.uucp (Murray Nesbitt)
Subject: Re: is fflush(stdin) conformant???
Organization: Private system in Toronto, ON
Date: Thu, 5 Nov 1992 11:02:41 GMT


mgk@sql.sybase.com (Michael Keirnan aka Joe Cool) writes:

>I am not actually comtemplating using this construct. A coworker is
>enrolled in a course where the instructor has advised flushing stdin
>(yes, stdin) in conjunction with using scanf() to "flush the unwanted
>newline." This seemed rather odd to me, but hey, what do I know?
>So what sayeth the gospel on the subject?

fflush()ing an input stream has no defined effect in ANSI C - it is
intended for output streams or update streams (in which the most
recent I/O operation was not input) only.

It may "flush the unwanted newline" on some particular systems, but if
the instructor claims it is a universal way of doing this in C, she's
wrong.

-- 
Murray
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: on "use", and the lvalue-ness of string literals
Date: 6 Nov 92 14:24:28 EST

bhoughto@sedona.intel.com (Blair P. Houghton) writes:
>In article <27143@dog.ee.lbl.gov> torek@horse.ee.lbl.gov (Chris Torek) writes:
>>In article <1992Nov2.162310.10094@ichips.intel.com> bhoughto@sedona.intel.com
>>(Blair P. Houghton) writes:
>>>	"A string literal is a primary expression.
>>>	 It is an lvalue..."
>>>    "foo" = "bar";	/* Is this okay? */
>>No, it is a `non-modifiable lvalue', just like an array---and in fact,
>>a string literal *is* an array (type `array N of char', even though the
>>actual char's may themselves be const).
>The Standard says something about translation phase 7 and
>adding a '\0' and initializing an array with static storage
>duration.
>It doesn't say directly that "foo" has array type (in the
>context above),

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.

The only time a string literal does not become an anonymous array is when it
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)), 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.

>E.g.,
>	"foo"[2] = 'g';
>results in undefined behavior.

But no diagnostic is required in this case, because no Constraint is violated.

Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: A different question about va_start & va_end.
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Fri, 6 Nov 1992 11:25:03 GMT

In article <1992Nov6.014500.1353@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>Must a standard conforming implementation accept:

s/standard conforming implementation/conforming implementation/

>	#include <stdarg.h>
>	int i, j;
>	va_list ap;
>	void foo (int bar, ...) {
>		i = (va_start (ap, bar), 99);
>		j = (va_end (ap), 88);
>	}
>In other words, may a programmer safely assume that invocations (or
>expansions) of va_start and va_end are themselves expressions?
>The function declarations shown in 4.8.1.1 and 4.8.1.2 seem to suggest
>that the answer is yes.

4.8.1, page 123 lines 17 to 19, says that va_start and va_arg must
be macros, while va_end may be either macro or identifier.  However,
if we interpret the function declarations as specifying usage syntax,
then I would say that they must be expressions, as you say.

The va_list ap; declaration must be moved inside the function.
4.8, page 123 lines 11 to 12.  Ah wait a minute.  The function has to
have this declaration, not necessarily a definition.  So you can keep
the file scope one (with external linkage at that) and just copy it
into the function as well.  I wonder if this is a bug (different rule
from what was intended) in the standard.
--
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: cs460129@ucs.usl.edu (Martinez Velez Jose Carlos)
Subject: Help on c book
Organization: Univ. of Southwestern La., Lafayette
Date: Fri, 6 Nov 1992 23:23:35 GMT

  I'm trying to find a good c book to learn c. Does anyone know of a good 
book to learn c?  I already know pascal and modula-2, so a book that relates
c to this language will also be helpful......

             thanks in advance.
     
                                E-mail: fjl0014@usl.edu
                                        cs460129@ucs.usl.edu
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.std.c
Subject: Re: is fflush(stdin) conformant???
Date: 5 Nov 92 14:31:33 GMT
Distribution: comp

In article <MGK.92Nov2131855@cedar.sql.sybase.com>, mgk@sql.sybase.com (Michael Keirnan aka Joe Cool) writes:
> I am not actually comtemplating using this construct. A coworker is
> enrolled in a course where the instructor has advised flushing stdin
> (yes, stdin) in conjunction with using scanf() to "flush the unwanted
> newline."

Is your coworker actually paying money for this "course"?  If so, I'd
advise him to demand an instructor who actually knows something about
the subject.  4.9.5.2 The fflush Function (emphasis mine):

	If stream points to an output stream or an update stream in
	which the most recent operation was not input, the fflush
	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*.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com  or  ...uunet!sdrc!larry.jones
I always send Grandma a thank-you note right away.  ...Ever since she
sent me that empty box with the sarcastic note saying she was just
checking to see if the Postal Service was still working. -- Calvin
Newsgroups: comp.std.c
From: lwv26@cas.org (Larry W. Virden)
Subject: Looking for tools and softcopy articles to assist in porting to ANSI C
Reply-To: lvirden@cas.org (Larry W. Virden)
Organization: Nedriv Software and Shoe Shiners, Uninc.
Date: Tue, 10 Nov 1992 15:18:48 GMT


What tools do folks use in assisting their movement to ANSI C as well as
new development under ANSI C?  Are there tools which, similar to lint,
warn programmers of dangerous constructs, assist in pointing out missing
header files, etc.?  

Also, are there some 'biblical' references available from internet that could
be used by K&R trained C programmers to make the transition to ANSI C?  Thanks!
-- 
Larry W. Virden                 UUCP: osu-cis!chemabs!lvirden
Same Mbox: BITNET: lvirden@cas  INET: lvirden@cas.org
Personal: 674 Falls Place,   Reynoldsburg, OH 43068-1614
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.std.c
Subject: Re: A different question about va_start & va_end.
Date: 8 Nov 92 18:33:15 GMT

In article <1992Nov6.014500.1353@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
< Must a standard conforming implementation accept:
< 
< 	#include <stdarg.h>
< 
< 	int i;
< 	int j;
< 	va_list ap;
< 
< 	void foo (int bar, ...)
< 	{
< 		i = (va_start (ap, bar), 99);
< 		j = (va_end (ap), 88);
< 	}
< 
< The function declarations shown in 4.8.1.1 and 4.8.1.2 seem to suggest
< that the answer is yes.

Indeed they do, but I distinctly remember discussions involving current
implementations of <varargs.h> that include unbalanced braces in
va_start and va_end, and I thought the intent was to allow that kind of
implementation.  I think this is deserving of a formal request for
interpretation.  And, while you're at it, you ought to ask about whether
the intent was to require the va_list to be a local variable or not as
Norman Diamond pointed out.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com  or  ...uunet!sdrc!larry.jones
I don't NEED to compromise my principles, because they don't have
the slightest bearing on what happens to me anyway. -- Calvin
Newsgroups: comp.std.c