HDTenEightyP/NetNews huggingface dataset:
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.std.c
Subject: Re: Intermediate addr outside object: legal?
Date: 8 Apr 1992 06:35:40 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: godot-1.think.com

In article <2160002@aspen.IAG.HP.COM> shankar@aspen.IAG.HP.COM (Shankar Unni) writes:
>This, of course, does not address the question of what is "the right
>thing to do" when the compiler sees this expression (the user-
>friendliness question).  Is it reasonable for the program to get a
>SIGSEGV on this?  I.e. is this some sort of commonly used (albeit
>questionable) idiom in some context that I'm not aware of?

It depends on what you mean by "user-friendliness".  Which is more
friendly: warning the programmer that their program may not port easily, or
doing what the programmer probably expects?

This kind of code generally arises when you want to emulate arrays whose
indices start at something other than 0.  For instance, if you want the
first element to be index 1, you would decrement the array pointer.

This restriction exists because some C implementations are known to fault
when computing addresses outside of arrays.  When performing pointer
arithmetic they use address registers, and on some architectures address
registers are checked for validity when they are loaded.  Whether this is a
Good Thing is debatable (the hardware designers presumably thought it was,
but what do they know? :-), but we're stuck with such hardware.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Xref: sparky comp.std.c:1791 gnu.gcc.bug:1045
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.std.c,gnu.gcc.bug
Subject: Re: ANSI C spec and GNU C preprocessing
Date: 11 Apr 92 17:29:51 GMT
Article-I.D.: agate.s77mfINNktd
Followup-To: comp.std.c,gnu.gcc.bug
Organization: University of California, Berkeley
To: gnu-gcc-bug@prep.ai.mit.edu
NNTP-Posting-Host: forney.berkeley.edu

In article <1992Apr9.213900.26576@urbana.mcd.mot.com> qbarnes@urbana.mcd.mot.com (Quentin Barnes) writes:

In article <1992Apr9.213900.26576@urbana.mcd.mot.com> you write:
>1) When a conforming preprocessor encounters a '#' directive which
>   is not listed in the preprocessor syntax (ex. '#foo'), what is
>   the correct behavior -- declare a fatal error, display a warning,
>   or pass it unchanged silently to the compiler?
>
>   GNU C silently passes it on and lets the compiler catch the error.
>   Since the spec doesn't say you can do that, I would read that as you
>   can't do it, so it would be a fatal error from the preprocessor.
>   I can't find a place in the spec that says this though.

You won't find such a place in the spec, because the spec doesn't say
that the preprocessor must be a separate pass, and says nothing about
what pass A must pass to pass B, because that's an implementation issue.

The whole reason for some of the traditional-vs-ANSI differences is so
that a single lexer can handle preprocessing and lexing for the compiler;
no separate pass needed, since the preprocessing is now token-based.

So "a conforming preprocessor" is an oxymoron.  ANSI C only says how
the compiler as a whole must behave.

All your other points are wrong because they ignore this point.  The
bit about the #line directives, for example: ANSI specifies the #line
commands that you as the user may give to the compiler.  It says nothing
at all about how cpp communicates with cc1; that's an implementation
detail.


--
Joe Buck	jbuck@ohm.berkeley.edu
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.std.c
Subject: Re: min, max, and ANSI
Date: 10 Apr 92 00:40:39 GMT
Article-I.D.: dog.22620
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
NNTP-Posting-Host: 128.3.112.15

(Since the question was about ANSI C, I have deleted `comp.std.c++'.)

In article <1992Apr9.165859.18578@wam.umd.edu> krc@wam.umd.edu
(Kevin R. Coombes) writes:
>>I have a question about the ANSI C header stdlib.h. A certain compiler
>>... includes macros for min(a,b) and max(a,b) in <stdlib.h>. ...
>>Are min and max SUPPOSED to be in stdlib.h, and have I been just lucky
>>in avoiding this problem in the past?

The ANSI C standard clearly states that <stdlib.h> defines the following:

  - macros:
	NULL
	EXIT_FAILURE
	EXIT_SUCCESS
	RAND_MAX
	MB_CUR_MAX

  - types:
	size_t
	wchar_t
	div_t
	ldiv_t

  - functions:
	atof
	atoi
	atol
	strtod
	strtol
	strtoul
	rand
	srand
	calloc
	free
	malloc
	realloc
	abort
	atexit
	exit
	getenv
	system
	bsearch
	qsort
	abs
	div
	labs
	ldiv
	mblen
	mbtowc
	wctomb
	mbstowcs
	wcstombs

It also notes that future standards may add function names that begin
with |str| and a lowercase letter (e.g., strabc, strrts, etc.).

Other parts of the standard clearly forbid all implementations to
define in <stdlib.h> any names not listed above, except for special
cases involving identifiers beginning with underscore.

The identifiers `min' and `max' do not appear in the list above, and
do not begin with an underscore.  Therefore they may not appear in
<stdlib.h>.

Conclusion: if the vendor claims ANSI conformance, <stdlib.h> is broken.
(If not, well, the standard can hardly control nonstandard implementations.)

In article <1324@hydra.bucknell.edu> cwalker@albiero.tmc.edu
(carleton walker `93) writes:
>	I've always used the MIN and MAX in <mp.h>. I took a peak in
><stdlib.h> and couldn't find a MIN or MAX function. Do you include
><mp.h>?

<mp.h> does not appear in the ANSI standard, so this reply is not
relevant to the question as asked.  Your particular implementation is
not the ANSI C standard---no particular implementation can be---and
may or may not even attempt to conform.

Nonetheless, min and max macros are commonly found in nonstandard
headers (such as <sys/param.h>) on Unix systems, among others.
Sometimes they are spelled in uppercase, sometimes in lowercase.  If
you want your code to compile on non-standard systems, you may wish to
avoid these names.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
Newsgroups: comp.std.c
From: diamond@jit533.jit.dec.com (Norman Diamond)
Subject: Re: Name space question
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Mon, 6 Apr 1992 00:02:11 GMT

In article <1992Apr4.011606.23687@mindcraft.com> fred@mindcraft.com (Fred
Zlotnick) writes:
>Suppose an implementation header defines a macro
>       #define _toupper(ch) ( (ch) + 'A' - 'a' )
>or something similar.  (This is quite common.)

It's not common in ANSI conforming implementations, except possibly as an
extension where the program has to do some non-strictly-conforming thing
in order to request the extension.

>Does this step on the application's namespace?  An application is free to
>declare an identifier "_toupper" as long as it does not have file scope.

It does, for the reason you gave.

>This is a function-like macro, and thus is only expanded when the identifier
>is immediately followed by a left parenthesis.  So I guess my question is:
>Can an identifier that is not an external identifier ever legally be followed
>by a left parenthesis?

If the implementation fails to accept this:
  #include <stdlib.h>
  #include <ctype.h>              /* Can use name _toupper for SOME things */
  main() {
    void (*_toupper)() = &exit;   /* Program declares block-scope variable */
    _toupper(EXIT_SUCCESS);       /* Program uses block-scope variable     */
  }
then the implementation is non-conforming.
--
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: dhesi@cirrus.com (Rahul Dhesi)
Newsgroups: comp.std.c
Subject: Re: PLEASE don't use "long long" for 64 bits + answer to letter
Date: 7 Apr 92 00:54:44 GMT
Organization: Cirrus Logic Inc.

In <1992Apr5.001829.12201@cirrus.com> I wrote:

     It is not a good idea to to allow accidentally repeated words, like
     "long long", to change the the meaning of a declaration.

You may have noticed one or two "accidentally" repeated words in that
article.  Just to make my point more clear, here is the complete list of
repeated words from that article, not including "long long".

     it it
     but but
     could could
     they they
     to to
     the the
     to to
-- 
Rahul Dhesi <dhesi@cirrus.COM>
UUCP:  oliveb!cirrusl!dhesi
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: Typedef Problem
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Sun, 12 Apr 92 09:01:49 GMT

In article <1992Mar28.153738.20577@mcshh.Hanse.DE> buster@mcshh.Hanse.DE (Andreas Burmester) writes:
>To handle strings, I've typedefed
>        typedef char CA[];
>and ran into a problem, I could track down to these definitions:
>(0)     CA s0 = "string 0";
>(1)     CA s1 = "s1";
>(2)     CA s2 = "this is string 2";
>The translator passes (0) and (1), while at (2), it complains
>that "The initializer length exceeds the aggregate length." A
>closer inspection reveals already at (1) things go (at least for
>me) unexpected ways: There are 9 bytes allocated for s1 - note,
>that strlen(s0) == 9 !
>It's obvious that, having processed (0), CA is 'retypdefed' to
>char CA[9]. Then the initializer of s2 is indeed too long.

My understanding of "Array declarators" (ANSI 3.5.4.2) is that the type CA
is an array type and is an incomplete type.  [3.5.4.2 is missing from the
index for "type, incomplete" in the last draft edition.]

My understanding of "Initialization" (ANSI 3.5.7) is that when an array of
unknown size is initialized, the array is the one in the declarator.  The
array whose size is determined by the number of initializers, and which no
longer has incomplete type, is the one in the declarator.  This would be
s0, s1, or s2.  I don't believe that it would be CA.

"Types" (ANSI 3.1.2.5) says that an array type of unknown size is completed,
for an identifier of that type, by specifying the size in a later declaration.
Unfortunately, this wording helps cloud things.  I think that "an identifier
OF that type" does not necessarily mean an identifier that IS the type, so my
personal interpretation (as just given) seems possible.  However, an array
type of unknown size can be completed in some cases without even having an
identifier, so I think that the wording cannot be taken literally.  Therefore
I'd advise getting an interpretation ruling.  [Personal opinion only.]

>The compiler, to name it, is ECO-C, a pre-ANSI translator.
[And to repeat your note] >that strlen(s0) == 9 !

This topic is not suitable for comp.std.c, but your compiler was broken even
under pre-ANSI common practices.  sizeof s0 was 9 but strlen(s0) was 8.
--
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: rudis+@CS.CMU.EDU (Rujith S DeSilva)
Subject: Re: Intermediate addr outside object: legal?
Date: Thu, 09 Apr 92 03:28:52 GMT
Organization: Carnegie Mellon University

In article <11306@ksr.com>, jfw@ksr.com (John F. Woods) writes:
|> The most "*user*-friendly" thing for a compiler to is to severely spank
|> *developers* who write nonportable, illegal code.  Eventually, *developers*
|> would start writing code with few enough bugs that *users* would enjoy
|> using it.
|> 
|> It should not be the compiler's job to *delay* bug reports.

Yeah, I've got really tired of students saying, ``gcc is broken: my program works
as long as I dont't turn on optimization.''  It would be nice to have a compiler
(or a switch on gcc) that is strictly standard conforming, yet does
`unreasonable' and `un-user-friendly' things whenever the user writes
non-conforming code (like `m = m++;').

Rujith de Silva.
Carnegie-Mellon University.
From: smclewin@ultrix.ramapo.edu (Scooter McLune)
Newsgroups: comp.std.c
Subject: Re: const T **
Keywords: const
Date: 14 Apr 92 21:24:31 GMT
Organization: University of Delaware

donne@imec.be (Werner Donne) writes:

>int
>main(void)

>{

>  const char **a;
>  char **b;

>  a = b;

>  return 0;

>}


>Why is the assignment illegal?

The assignment cannot be done because **a is a constant variable, by your
definition.  If you were to do the assignment "b = a" with the code you
have above, there would be no problem.

Scott.

>Werner.
>-- 
>Quick to judge, quick to anger, slow to understand.
>Ignorance and prejudice and fear walk hand in hand.

>Neil Peart.
Newsgroups: comp.std.c
From: pete@borland.com (Pete Becker)
Subject: Re: min, max, and ANSI
Organization: Borland International
Date: Mon, 13 Apr 1992 17:13:30 GMT

In article <10209@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>
>Turbo C 2.01 does have problems in its <stdlib.h> which the -A option does
>not fix.  Example:
>
	Turbo C 2.01 was replaced by Turbo C++ 1.0 over two years ago.
From: shankar@aspen.IAG.HP.COM (Shankar Unni)
Date: Mon, 6 Apr 1992 18:43:06 GMT
Subject: Re: Intermediate addr outside object: legal?
Organization: HP International Contract Programming
Newsgroups: comp.std.c

In comp.std.c, darcy@druid.uucp (D'Arcy J.M. Cain) writes:

> Chapter 3.3.2.1 says that E1[E2] is identical to "(*(E1+(E2)))."  After
> expanding macros the above becomes "(foo - 8000)[9000]" which is
> identical to "(*((foo - 8000)+(9000)))."  Removing superfluous parens
> that gives "*(foo - 8000 + 9000)" or "*(foo + 1000)" which looks
> perfectly legitimate to me.

But you see, the whole point of the question is that the C standard
*cannot* assume that an implementation does constant folding.  We must
look at the expression exactly as if each operation in the expression
were performed separately in some serial order mandated by the standard.

All this discussion just confirms for me that the result of this
expression is "undefined".

This, of course, does not address the question of what is "the right
thing to do" when the compiler sees this expression (the user-
friendliness question).  Is it reasonable for the program to get a
SIGSEGV on this?  I.e. is this some sort of commonly used (albeit
questionable) idiom in some context that I'm not aware of?

Thanks once again,
-----
Shankar Unni                                 Internet: shankar@iag.hp.com
HP International Contract Programming          HPDESK: Shankar UNNI / HP4700
Phone : +1-408-447-4007                          UUCP: ...!hplabs!hpda!shankar
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.std.c
Subject: Re: const T **
Keywords: const
Date: 16 Apr 92 13:33:00 GMT
Organization: AT&T Bell Laboratories, Liberty Corner NJ

In article <1611@imec.UUCP>, donne@imec.be (Werner Donne) writes:
> int
> main(void)

> {

>   const char **a;
>   char **b;

>   a = b;

>   return 0;

> }

> Why is the assignment illegal?

Because otherwise I could do this:

	const char x = 'x';
	char *p;
	const char **pp = &p;	/* char** -> const char** */
	*pp = &x;		/* p = &x */
	*p = 'y';		/* Oops!! */
-- 
				--Andrew Koenig
				  ark@europa.att.com
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: const T **
Keywords: const
Date: 15 Apr 92 11:42:21 EDT

eggert@twinsun.com (Paul Eggert) writes:
>jfw@ksr.com (John F. Woods) writes:
>>it certainly seems to make sense to be able to
>>assign a pointer-to-pointer-to-char into a pointer-to-pointer-to-constant-char.
>Actually, it doesn't make sense to allow such assignments, because if you
>allowed them, you could convert pointer-to-constant-char to pointer-to-char
>without any cast or diagnostic, which leads to obvious problems.  Here's an
>example.  (I write `char const' instead of `const char' because it's clearer
>if you always make `const' follow the type that it modifies.)
>	char const *c = "abc";
>	char const **cc;
>	char *p;
>	char **pp = &p;
>	cc = pp; /* violates C constraint */
>	*cc = c;
>	*p = 0; /* assigns to read-only storage */
>If C allowed such assignments, the line marked ``violates C constraint'' above
>would be strictly conforming C, and there would be no compile-time diagnostic
>for the problem in the last line that (at least on my machine) makes the
>program dump core.

If C allowed such assignments, the program would still not be strictly
conforming, because the last line modifies "an object with a const-qualified
type though use of an lvalue with non-const-qualified type".  Losing the
compile-time diagnostic is regrettable, but note that there is no diagnostic
required by the following:

	#include <string.h>

		*strchr("hammer me", ' ') = 0;

even though it also modifies an object with const-qualified type.

Allowing such assignments would allow correct programs to be written with
less gratuitous noise.
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: Name space question
Date: 6 Apr 92 12:07:39 EDT

fred@mindcraft.com (Fred Zlotnick) writes:
>The C standard reserves certain name spaces for the implementor: __*,
>_[A-Z]*, and for identifiers with file scope (and this is where my
>question arises) _*.  (See section 4.1.2.1 of the ANSI edition, or,
>according to Plauger's book, clause 7.1.3 of the ISO edition, of the
>Standard.)
>Suppose an implementation header defines a macro
>	#define _toupper(ch) ( (ch) + 'A' - 'a' )
>or something similar.  (This is quite common.)  Does this step on the
>application's namespace?  An application is free to declare an identifier
>"_toupper" as long as it does not have file scope.  Can such a
>declaration ever get expanded by the macro?  This is a function-like
>macro, and thus is only expanded when the identifier is immediately
>followed by a left parenthesis.  So I guess my question is: Can an
>identifier that is not an external identifier ever legally be followed
>by a left parenthesis?

main() {
	int blee;
	double _toupper();

	/* code which does not use _toupper() */
}

This code fragment declares an identifier _toupper with block scope, which
is legal (as long as the program does not create a declaration with file
scope, which means the program can't actually use the function).  Declaring
a macro with that name would probably make the program fail to compile.

I think, therefore, that the implementation may not #define _[0-9a-z]*
identifiers, since they are not reserved for all scopes.
Newsgroups: comp.std.c
From: CONSLT24@Zeus.unomaha.edu (Issa El-Hazin)
Subject: Need to know how to fflush(stdin) in VMS C?
Organization: University of Nebraska at Omaha
Date: Wed, 8 Apr 1992 03:10:58 GMT
X-News-Reader: VMS NEWS 1.11

Does anybody know how to flush the stdin in VMS 'C'? I'm using the system();
function to run a command and would like to flush any key(s) the user might
press while waiting for the command to complete (esp. since the system(); call
takes a long time to spawn and run if there are too many people on the system
(Is there a faster alternative to using the system() call? I'm using VMS 5.4.3)
Also if anybody knows how to disable the Ctrl-Y and Ctrl-Z from within a 'C'
program I would be greatly appreciative. I'm modifying a VMS menu program (5000
lines) that I've wrote and if anybody is interested in running it they can do
so by telneting to zeus.unomaha.edu and login as a guest then typing "window"
at the $. The program is located in perm$5:[conslt24.public]. Please feel
free to use or to get a copy of it. Back to my question I'm doing something
similar to the next program and I can't figure out why it's not working.


#include <stdio.h>

main()
{

char test;
int array[10];

	printf("\n Type a letter: ");
	scanf("%c",&test);	/* wait until I'm ready		      */

	sleep(5);		/* while waiting for 5 seconds        */
				/* Type a string and press <enter>    */

	fflush(stdin);		/* flush standard input (keyboard)   */

	scanf("%s",&array);	/* read what's in the input buffer    */

	printf("\n%s",array);	/* will print the string typed before */
				/* flushing the stdin		      */
}


Any suggestions are welcomed and are greatly appreciated.

Thanks in advance

/-Issa-/
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: const T **
Keywords: const
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Thu, 16 Apr 92 00:35:14 GMT

In article <11434@ksr.com> jfw@ksr.com (John F. Woods) writes:
>       "both operands are pointers to qualified or unqualified versions of
>       compatible types, and the type pointed to by the left has all the
>       qualifiers of the type pointed to by the right."
>I don't know why the C Standard Committee only specified one level.  And all
>of the members of the committee who used to post here seem to have been chased
>off, so I guess we'll never know.

They've previously said why.  They couldn't find better wording without
excessive trouble.
--
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: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: Intermediate addr outside object: legal?
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Tue, 14 Apr 92 01:57:13 GMT

In article <2160003@aspen.IAG.HP.COM> shankar@aspen.IAG.HP.COM (Shankar Unni) writes:
>In comp.std.c, barmar@think.com (Barry Margolin) writes:
>>In article <2160002@aspen.IAG.HP.COM> shankar@aspen.IAG.HP.COM (Shankar Unni) writes:
>>>This, of course, does not address the question of what is "the right
>>>thing to do" when the compiler sees this expression (the user-
>>>friendliness question).  Is it reasonable for the program to get a
>>>SIGSEGV on this?  I.e. is this some sort of commonly used (albeit
>>>questionable) idiom in some context that I'm not aware of?
>>
>>It depends on what you mean by "user-friendliness".  Which is more
>>friendly: warning the programmer that their program may not port easily, or
>>doing what the programmer probably expects?
>
>Well, I might as well come out and say it: this case came up when
>someone trying to optimize TeX 3.14 ran across it. Apparently Web2C
>(which translates the original TeX web code into C) puts out code like
>this, and from the message I got, it did so all over the place. Which is
>why I was asking : is this a peculiarity of Web2C, or do other programs
>also do this sort of junk?

The question of user-friendliness is not a comp.std.c topic, except when
a revised standard is being developed and there are proposals for the
standard to ALLOW user-friendly conforming implementations.

The question of whether the present standard ALLOWS SIGSEGV for violations
is suitable and has a perfectly clear answer.  Yes.  And as rationale, it
has already been pointed out why it is reasonable to allow this behavior,
since it would be expected on some reasonable architectures.

The last question also is not particularly a comp.std.c topic, but it does
arise and cause repercussions all too frequently.  The answer to this too
is yes, there is a lot of broken code out there.  Mr. Margolin pointed out
that some programmers find it more friendly to be warned when their code
is broken.  I agree.  But Mr. Margolin and I seem to be in the minority.
It is a fact of life that many programmers have preferred writing broken
code, are writing broken code now, and will continue writing broken code
forever more.
--
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,comp.std.c++