HDTenEightyP/NetNews huggingface dataset:
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: When a compiler must choke
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Thu, 15 Oct 1992 01:35:24 GMT

In article <ldon82INN7j@exodus.Eng.Sun.COM> linden@positive.Eng.Sun.COM (Peter van der Linden) writes:
>Section 2.1.1.3 of the ANSI C standard sayeth:
>       "A conforming implementation shall produce [a] ... diagnostic message
>        ... for every translation unit that contains a violation of any syntax
>        rule or constraint.   Diagnostic messages need not be produced in 
>        other circumstances."
>
>By "syntax rule or constraint", is the standard referring only to the
>information contained in its paragraphs headed "Syntax" and "Constraints"?

Yes.  This involves case-insensitive, quantity-insensitive, comparisons of
"syntax" vs. "Syntax" and "constraint" vs. "Constraints"  :-)

>So, for example, if a program violates something specified only in a 
>paragraph headed "Implementation limits" or "Semantics", a conforming 
>implementation is not *obliged* to emit a diagnostic message?

True again, it is not obliged.

Now for your other question:
>Subject: When a compiler must choke

The answer is never.  If a program violates syntax and/or constraints
(with diagnostic) and/or limits and/or semantics (with or without diagnostic)
the compiler does not have to choke.  It can continue to produce good code
(if there exists some meaningful good code and the compiler wishes to do so),
or bad code such as something that will post true facts to alt.folklore.urban.
--
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."
Newsgroups: comp.std.c
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: FILE *yyin=stdin; not ANSI-C??
Date: Fri, 9 Oct 1992 17:12:22 GMT
Organization: U of Toronto Zoology

In article <1992Oct8.220811.7882@utwente.nl> emmerik@utrcu1.civ.utwente.nl (Emmerik P.J.L. van) writes:
>The following looks to me perfectly legal ANSI-C code.
>
>FILE *yyin = {stdin}, *yyout = {stdout};

Sorry, it's not.  Nothing in ANSI C promises that stdin and stdout are
constants.  Therefore they cannot (portably) be used to initialize
extern/static variables.
-- 
MS-DOS is the OS/360 of the 1980s.      | Henry Spencer @ U of Toronto Zoology
              -Hal W. Hardenbergh (1985)|  henry@zoo.toronto.edu  utzoo!henry
Newsgroups: comp.std.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: struct hack
Organization: SoftQuad Inc., Toronto, Canada
Date: Wed, 14 Oct 92 07:08:47 GMT

This is getting repetitive, but I think I do have to say it once more.
I assume everyone knows the context by now.

> There is a difference.  The p in my original posting pointed to a
> single char *in the array returned by malloc*.  The decayed f->s, on
> the other hand, points to a single char in the array f->s.

There is no difference.  The standard says (in 3.1.2.5 = 6.1.2.5) that
a pointer provides a reference to the pointed-to type.  It does not say
that it carries any additional information.  We agree that p and the
decayed f->s point to the same char.  This char is in the array f->s,
and also, *simultaneously*, in the array returned by malloc.

> All of the justifications for allowing this hack have been based on
> the fact that the pointer was returned by malloc.  This is, however,
> not the case; f->s was *not* returned by malloc.  It is a one char
> array, which degenerates to a pointer into *this* array (and only
> co-incidentally, into the array returned by malloc), and thus, the
> results of accessing further char's behind the one declared are
> undefined.

It is *not* coincidental, which is exactly the point.  The pointer,
either p or the decayed f->s, points into the array returned by malloc
*because we made it do so*, using only operations allowed and defined
by the standard, and because we took advantage of the fact that a pointer
does *not* contain information as to how its value was derived.[1]
Therefore the access in question is valid.

[1] More precisely, a strictly conforming program mustn't be able to
tell if it carries such extra information.  Due to the "as if" rule,
a bounds-checking implementation is free to attach extra information
to pointers and use this information only to detect undefined accesses.
It could even issue a run-time warning if you used the "struct hack";
the standard never prohibits warnings.  But it must not *prevent* the
"struct hack" from working, since it is valid; if bounds information
could be used to terminate the program, then the bounds attached to
the decayed f->s must be those of the array returned by malloc.  In
practice I think it is easier for such an implementation to attach
the bounds to the arrays rather than the pointers, and with each
pointer to carry the information of what array it is pointing into;
then both f and the decayed f->s can be identified as pointing into
the array returned by malloc.
-- 
Mark Brader		  "We may take pride in observing that there is not a
SoftQuad Inc., Toronto	   single film showing in London today which deals with
utzoo!sq!msb		   one of the burning issues of the day."
msb@sq.com		      -- Lord Tyrell, British film censors' chief, 1937

This article is in the public domain.
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: Static function prototypes and definitions
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Tue, 13 Oct 1992 01:13:03 GMT

In article <1bcn2mINN680@news.aero.org> lmiller@aero.org (Lawrence H. Miller) writes:
>If I have a static function defined in a file, must the 
>prototype also have the word static?

The first prototype with file scope must say "static."
All prototypes with block scope that appear before the first prototype with
file scope must also say "static."

After the first prototype with file scope, later prototypes may either say
"static" or "extern" or may omit the storage class entirely.  Reasons:

ANSI 3.1.2.2, page 22 lines 16 to 18:  "If the declaration of an identifier
for an object or function contains the storage-class specifier extern, the
identifier has the same linkage as any visible declaration of the identifier
with file scope."  So it retains internal linkage from the first file scope
declaration, even if it says "extern" this time.

Same page, lines 20 to 21:  "If the declaration of an identifier for a
function has no storage-class specifier, its linkage is determined exactly
as if it were declared with the storage class specifier extern."  So by
this roundabout method, it again retains internal linkage.

>My reading of the standard is that the word static is forbidden in block
>scope declarations,

Where did you read that?  Section, page, and line numbers please.

>but gnu C requires it.

Sounds like it's probably right, depending on where the particular
declaration is located.

In article <bjEsPb0L@twinsun.com> eggert@twinsun.com (Paul Eggert) writes:
>I can't reproduce the problem that you describe.  Given the program
>	void f(void) { static void g(void); g(); }
>	static void g(void) {}
>`gcc -ansi -pedantic' (GCC 2.2.2) issues a diagnostic, as required by
>the C standard:
>	t.c: In function `f':
>	t.c:1: warning: invalid storage class for function `g'

Well then, you reproduced a different problem.  Of course, this doesn't
affect whether gcc conforms or not, because the standard allows conforming
implementations to issue spurious false misleading error messages.

>The proper way to write this is:
>	static void g(void);
>	void f(void) { g(); }
>	static void g(void) {}

That is a proper way.  Another proper way is the one gcc complained about.

>The GCC manual says:
>     Some users try to use `-pedantic' to check programs for strict ANSI
>     C conformance.  They soon find that it does not do quite what they
>     want: it finds some non-ANSI practices, but not all--only those
>     for which ANSI C *requires* a diagnostic.

Nope, it found a practice for which ANSI C doesn't require a diagnostic
and for which there is no good reason to issue a diagnostic.
Demand a refund for your copy of GCC :-)
--
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: msb@sq.sq.com (Mark Brader)
Newsgroups: comp.std.c
Subject: Re: struct hack
Date: 8 Oct 92 17:41:01 GMT
Organization: SoftQuad Inc., Toronto, Canada

> As has also been pointed out to me in email, I made a mistake at the
> end of my previous posting, which in fact negated most of my argument.
> 
> The expression f->s does not have type char*, it has type char[1].  It
> does not refer to the array returned by malloc, but simply to a small
> part of it, the part defined in the structure.

Hmm, I missed that too, but it doesn't affect anything.  The char * value
that we were both talking about is the one that f->s decays to as soon as
it's used in an appropriate context.  This, too, points to a single char,
but not because the member s has a length of 1; it's because a char *
only ever points to a single char.  p only points to a single char too.
p and the decayed f->s are interchangeable.
-- 
Mark Brader		 "... [A]toms and universes are the same.  All the
SoftQuad Inc., Toronto	      world is recursive, and that's why we never
utzoo!sq!msb, msb@sq.com      know where to begin."	-- Charles Goldfarb

This article is in the public domain.
From: ejh@wvnvms.wvnet.edu
Newsgroups: comp.std.c
Subject: compiling under medium
Date: 12 Oct 92 15:44:44 GMT
Organization: West Virginia Network for Educational Telecomputing

I am new to the group so I hope this has not been asked before.

I am writing a program and I have now gotten to the point of it being to large
to fit into the small memory model.  I would like to compile it under the
medium model.  The trouble comes in when I have a .obj file which was compiled
under the small memory model.  Is there a way which I can compile my program
and this .obj file under the medium model.  

I do not have the source for the .obj, but I do have a header file for it.

Any help here would greatly be appreciated. 
Newsgroups: comp.std.c
From: emmerik@utrcu1.civ.utwente.nl (Emmerik P.J.L. van)
Subject: FILE *yyin=stdin; not ANSI-C??
Organization: University of Twente
Date: Thu, 8 Oct 1992 22:08:11 GMT

The following looks to me perfectly legal ANSI-C code.

sgi-cad> cat test.c
# include <stdio.h>
FILE *yyin = {stdin}, *yyout = {stdout};
main()
{
}

Nevertheless i get the following results when compiling on a
Silicon Graphics workstation:

sgi-cad> cc -cckr test.c
sgi-cad> cc -ansi test.c
accom: Error: test.c, line 2: integer constant expected
       FILE *yyin = {   (__stdin) }, *yyout = { (__stdout) };
       ---------------------------^
sgi-cad> cc -xansi test.c
sgi-cad> cc -ansiposix test.c
accom: Error: test.c, line 2: integer constant expected
       FILE *yyin = {   (__stdin) }, *yyout = { (__stdout) };
       ---------------------------^

Who is wrong, me or the SGI C-compiler?
If i am wrong, how do i initialize a FILE pointer to point to
standard input/output.

I am working with version 4.0.1 of the IRIS operating system.

Pleace Email to emmerik@utwente.nl

-- 
Pieter van Emmerik                    | Phone:  +31-74-464231
HDS info management                   | FAX:    +31-74-464110
P.O.box 23                            | E-mail: emmerik@utwente.nl
7550 AA  Hengelo, The Netherlands     |         hp4nl!utrcu1!emmerik
From: wagner@lub001.lamar.edu
Newsgroups: comp.std.c
Subject: Aggregate Initialization   **NOT**
Date: 15 Oct 92 10:17:11 GMT
Article-I.D.: lub001.1992Oct14.171711.1655
Organization: Lamar University - Beaumont

Hi

I have a small problem with my compiler, and I hope someone out there can be of 
assistance.  I am using a DEC 5100 running Ultrix V4.2, this is a recent
upgrade.  My problem is with the C compiler.  

In my code I have a statment similar to the following:

	int array_name[] = {value,value,value,...};

Now, this statement is correct in every reference I can find, but when I
compile it the compiler returns an error and says that aggregate initialization
is not allowed.

My question is: Is this a bug with my compiler or is it just a sucky compiler!

I would appreciate any suggestions as how to either fix this or get around it.
Thanks 

Kenneth Wagner
Newsgroups: comp.std.c
From: dat@thinkage.on.ca (David Adrien Tanguay)
Subject: Re: struct hack
Organization: Thinkage, Ltd.
Date: Fri, 16 Oct 1992 18:03:20 GMT

msb@sq.sq.com (Mark Brader) writes:
>There is no difference.  The standard says (in 3.1.2.5 = 6.1.2.5) that
>a pointer provides a reference to the pointed-to type.  It does not say
>that it carries any additional information.  We agree that p and the
>decayed f->s point to the same char.  This char is in the array f->s,
>and also, *simultaneously*, in the array returned by malloc.

Will the following also work?

	struct blah { int i; char s[1]; };
	union {
		char xxx[10*sizeof(struct blah)];
		struct blah f;
	} u;
	u.f.s[1] = 'x';

Or?
	struct blah farr[10];
	farr[0].s[1] = 'x';
-- 
David Tanguay       dat@Thinkage.on.ca  dat@Thinkage.com  uunet!thinkage!dat
Thinkage, Ltd.           Kitchener, Ontario, Canada          [43.40N 80.47W]
From: linden@positive.Eng.Sun.COM (Peter van der Linden)
Newsgroups: comp.std.c
Subject: When a compiler must choke
Date: 14 Oct 1992 17:46:42 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: positive

Section 2.1.1.3 of the ANSI C standard sayeth:
       "A conforming implementation shall produce [a] ... diagnostic message
        ... for every translation unit that contains a violation of any syntax
        rule or constraint.   Diagnostic messages need not be produced in 
        other circumstances."

By "syntax rule or constraint", is the standard referring only to the
information contained in its paragraphs headed "Syntax" and "Constraints"?

So, for example, if a program violates something specified only in a 
paragraph headed "Implementation limits" or "Semantics", a conforming 
implementation is not *obliged* to emit a diagnostic message?

--

Peter van der Linden     linden@eng    415 336-6206

Donner Party, your table for 24 -- uh, 23 -- uh 22, is ready.
Newsgroups: comp.std.c
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: FILE *yyin=stdin; not ANSI-C??
Organization: Computer Science, University of Melbourne, Australia
Date: Mon, 12 Oct 1992 05:17:10 GMT

jos@and.nl (Jos Horsmeier) writes:

>You're right, but the ANSI C standard _does_ `promise' that stdin and
>stdout are `expressions of type ``pointer to FILE'' that point to the
>FILE objects associated [...]'
>So, the original poster can solve his/her problem by moving the assignments
>away from the initialization code and simply do an assignment like:
>
>FILE *yyin, *yyout;
>/* ... */
>yyin= stdin; yyout= stdout;

These initializations actually come from the "lex" tokenizer skeleton code;
to solve the problem you need to add
	if (!yyin) yyin = stdin;
	if (!yyout) yyout = stdout;
either at the start of yylex(), or more efficiently in the initialization
code which (in my version) is in yylook().

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: lmiller@aero.org (Lawrence H. Miller)
Newsgroups: comp.std.c
Subject: Re: Static function prototypes and definitions
Date: 14 Oct 1992 21:58:29 GMT
Organization: The Aerospace Corporation, El Segundo, CA
NNTP-Posting-Host: palomar.aero.org

In article <bjFLFApU@twinsun.com> eggert@twinsun.com (Paul Eggert) writes:
>To answer Miller's question, the program
>
>       void f(void) { void g(void); g(); }
>       static void g(void) { }
>
>has undefined behavior because g has both external and internal linkage.
>See ANSI C 3.1.2.2 (Linkages of Identifiers).

Hmmm.  Perhaps not:

	3.1.2.2 Linkage of Identifiers

	  If the declaration of a file scope identifier for an
	object or a function contains the storage-class specifier
	static, the identifier has internal linkage.
		
		[So g has internal linkage.]

	  If the declaration of an identifier for an object or
	function contains the storage-class specifier extern, the
	identifier has the same linkage as any visible declaration
	of the identifier with file scope.

	[It goes on to say that if there is no other storage-class
	specifier, it is extern.]


So the question becomes, what is the definition of "visible
declaration"?  We look back in 3.1.2.1 and we find:

	3.1.2.1  Scopes of Identifiers

	  An identifier is visible (i.e., can be used) only within
	a region of program text called its scope...

	  Every other identifier has scope determined by the 
	placement of its declaration...If the declarator or type
	specifier...appears outside of any block or list of
	parameters,, the identifier has file scope, which terminates
	at the end of the translation unit.

Now I interpret this to mean what it says: a function definition has
FILE SCOPE, i.e., from the START to the END of the file.

	[The declaration of g within f has the same linkage as
	the file scope definition of g, i.e., internal.]

So:
>
>       void f(void) { void g(void); g(); }
>       static void g(void) { }

should be valid, not undefined.

-- 
Larry Miller		The Aerospace Corporation
lmiller@aero.org	PO Box 92957		
310-336-5597		LA, CA 90009-2957
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.std.c
Subject: Re: FILE *yyin=stdin; not ANSI-C??
Date: 9 Oct 92 19:07:51 GMT
Organization: AND Software BV Rotterdam

In article <Bvv6Gn.KEn@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
|In article <1992Oct8.220811.7882@utwente.nl> emmerik@utrcu1.civ.utwente.nl (Emmerik P.J.L. van) writes:
|>The following looks to me perfectly legal ANSI-C code.
|>
|>FILE *yyin = {stdin}, *yyout = {stdout};
|
|Sorry, it's not.  Nothing in ANSI C promises that stdin and stdout are
|constants.  Therefore they cannot (portably) be used to initialize
|extern/static variables.

You're right, but the ANSI C standard _does_ `promise' that stdin and
stdout are `expressions of type ``pointer to FILE'' that point to the
FILE objects associated [...]'
So, the original poster can solve his/her problem by moving the assignments
away from the initialization code and simply do an assignment like:

FILE *yyin, *yyout;
/* ... */
yyin= stdin; yyout= stdout;

kind regards,

Jos aka jos@and.nl
Newsgroups: comp.std.c
From: kanze@us-es.sel.de (James Kanze)
Subject: Re: struct hack
Organization: SEL
	<KANZE.92Oct7212215@slsvdnt.us-es.sel.de> <1992Oct8.174101.19668@sq.sq.com>
Date: 10 Oct 92 15:23:57

In article <1992Oct8.174101.19668@sq.sq.com> msb@sq.sq.com (Mark
Brader) writes:

> > As has also been pointed out to me in email, I made a mistake at the
> > end of my previous posting, which in fact negated most of my argument.
> > 
> > The expression f->s does not have type char*, it has type char[1].  It
> > does not refer to the array returned by malloc, but simply to a small
> > part of it, the part defined in the structure.

> Hmm, I missed that too, but it doesn't affect anything.  The char * value
> that we were both talking about is the one that f->s decays to as soon as
> it's used in an appropriate context.  This, too, points to a single char,
> but not because the member s has a length of 1; it's because a char *
> only ever points to a single char.  p only points to a single char too.
> p and the decayed f->s are interchangeable.

There is a difference.  The p in my original posting pointed to a
single char *in the array returned by malloc*.  The decayed f->s, on
the other hand, points to a single char in the array f->s.

The array returned by malloc has the size that was given to malloc.
Pointer arithmetic is legal as long as the pointer points somewhere
between the first char returned and the last char returned plus one.
Pointer arithmetic that would move the pointer outside of this range,
or dereferencing the pointer when it points to the last char plus one,
results in undefined bahavior, and a system is fully within its rights in
treating this as a bounds error.

The array f->s has a size of one.  Pointer arithmetic is legal on this
expression as long as the resulting pointer points either to the one
char in the array, or to the char behind it.  Pointer arithmetic that
would move the pointer to any other char, or dereferencing the pointer
when it points to the char behind the array, results in undefined
behavior, and a system is fully within its rights in treating this as
a bounds error.

All of the justifications for allowing this hack have been based on
the fact that the pointer was returned by malloc.  This is, however,
not the case; f->s was *not* returned by malloc.  It is a one char
array, which degenerates to a pointer into *this* array (and only
co-incidentally, into the array returned by malloc), and thus, the
results of accessing further char's behind the one declared are
undefined.
--
James Kanze                     GABI Software, Sarl.
email: kanze@us-es.sel.de       8 rue du Faisan
                                67000 Strasbourg
                                France
Newsgroups: comp.std.c
From: eggert@twinsun.com (Paul Eggert)
Subject: Re: Static function prototypes and definitions
Organization: Twin Sun, Inc
Date: Mon, 12 Oct 1992 22:03:51 GMT

lmiller@aero.org (Lawrence H. Miller) writes:

>If I have a static function defined in a file, must the 
>prototype also have the word static?  My reading of the
>standard is that the word static is forbidden in block
>scope declarations, but gnu C requires it.

I can't reproduce the problem that you describe.  Given the program

	void f(void) { static void g(void); g(); }
	static void g(void) {}

`gcc -ansi -pedantic' (GCC 2.2.2) issues a diagnostic, as required by
the C standard:

	t.c: In function `f':
	t.c:1: warning: invalid storage class for function `g'

The proper way to write this is:

	static void g(void);
	void f(void) { g(); }
	static void g(void) {}


It's not necessarily a good idea to use GCC to check for conformance.
The GCC manual says:

     Some users try to use `-pedantic' to check programs for strict ANSI
     C conformance.  They soon find that it does not do quite what they
     want: it finds some non-ANSI practices, but not all--only those
     for which ANSI C *requires* a diagnostic.
From: lmiller@aero.org (Lawrence H. Miller)
Newsgroups: comp.std.c
Subject: Static function prototypes and definitions
Date: 12 Oct 1992 20:27:02 GMT
Organization: The Aerospace Corporation, El Segundo, CA
Distribution: world
NNTP-Posting-Host: palomar.aero.org

Several allegedly ANSI conforming compilers differ in how
static functions are to be specified in prototypes.

If I have a static function defined in a file, must the 
prototype also have the word static?  My reading of the
standard is that the word static is forbidden in block
scope declarations, but gnu C requires it.

If the word static is forbidden, is this really invalid:

	void f(void)
	{
	  static void g(void);
	  . . .
	  g();
	}

Is this correct:

	void f(void)
	{
	  void g(void);
	  . . .
	  g();
	}

Or is this required:

	static void g(void);

	void f(void)
	{
	  . . .
	  g();
	}

All assuming the file later contains a definition of g:

	static void g(void)
	{
	  . . .
	}


-- 
Larry Miller		The Aerospace Corporation
lmiller@aero.org	PO Box 92957		
310-336-5597		LA, CA 90009-2957
Newsgroups: comp.std.c