HDTenEightyP/NetNews huggingface dataset:
From: volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe)
Newsgroups: comp.std.c
Subject: Re: Standard conformance and GCC 2.3.3
Date: 31 Dec 92 15:00:47 GMT
Reply-To: volpe@ausable.crd.ge.com
Organization: GE Corporate Research & Development

In article <1992Dec30.203555.3615@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
|> In article <1992Dec30.173634.15487@crd.ge.com> volpe@ausable.crd.ge.com writes:
|> +In article <C02I8I.58I@jrd.dec.com>, diamond@jit533.jit.dec.com (Norman Diamond) writes:
|> +|> >-----------------------------------------------------------------------------
|> +|> >#9)  GCC fails to issue errors in cases where a static function is referenced
|> +|> >     but never defined, even when the -pedantic-errors option is used.
|> +|> >static void s (); int main () { s (); return 1; }
|> +|> 
|> +|> Again I see no violation of a constraint.  Furthermore, if you returned
|> +
|> +Me neither, but...
|> 
|> See ANSI section 3.7, constraints.

Opps. You're right. Thanks.

|> 
|> +|> >-----------------------------------------------------------------------------
|> +|> >#20)  GCC incorrectly issues errors for the following standard-conformant
|> +|> >      ANSI C code when the -pedantic-errors option is used.
|> +|> >static enum E1 { red, green, blue};
|> +|> >static struct S1 { int member; };
|> +|> >static union U2 { int member; };
|> +|> >void foobar () {
|> +|> >	auto enum E2 { red, green, blue };
|> +|> >	auto struct S2 { int member; };
|> +|> >	auto union U2 { int member; };
|> +|> >}
|> +|> 
|> +|> Spurious diagnostics are allowed, though now they return to the status of
|> +|> unfriendly and misleading.  What happened when you tried executing it?
|> +
|> +These diagnostics are prefectly friendly and very helpful. Since the
|> +declarations allocate no storage (there's no object being defined), a 
|> +storage class specifier is useless and superfluous.
|> 
|> I disagree violently with the assertion that the issuance of errors for
|> perfecly "standard conformant" code is "perfectly friendly and very helpful".
|> Anyone who says such a thing obviously does not port code for a living!

I disagree violently with the assertion that any errors one might make
would necessarily result in non-standard-conformant code. Just because 
it's conformant doesn't mean it's intended. Anyone who says such a thing
obviously never writes original code for a living, or otherwise is a 
complete programming God who has never made a mistake and never found
lint to be the least bit useful. 

I would *never* write the above piece of code intentionally, no matter
how conformant it is, and I would appreciate some kind of warning that
I had obviously omitted some variable names in those declarations.

-- 
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
Newsgroups: comp.std.c
From: jet@boxer.nas.nasa.gov (J. Eric Townsend)
Subject: Maximum depth of #if preprocessing directives
Organization: Numerical Aerodynamic Simulation, NASA Ames
Date: 24 Dec 92 13:32:37



I looked in 2.2.4.1, but I don't recognize any of the translation
limits as applying to the maximum depth of #if directives.  Could
someone tell me where I should look, or if such a limit exists?

thanks

--
             J. Eric Townsend --  jet@nas.nasa.gov -- 415.604.4311
              '92 R100R, DoD# 0378, BMWMOA, AMA, ACLU, EFF, CPSR
                                "HotHead Rules!"
Newsgroups: comp.std.c
From: diamond@jit533.jit.dec.com (Norman Diamond)
Subject: Re: uninitialized++;
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Thu, 31 Dec 1992 03:41:31 GMT

In article <1992Dec30.172142.22789@taumet.com> mike@taumet.com (Mike Ball) writes:
>diamond@jit533.jit.dec.com (Norman Diamond) writes:
>>In article <9236508.13290@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>>>hbf@gandalf.uio.no (Hallvard B Furuseth) writes:
>>>>Can this fail  - on some machine?  - in ANSI?
>>  main () { int uninitialized; uninitialized += 0; return 0; }
>>I think this one is not allowed to fail.

>To quote from the standard., section 1.6
>"Undefined behavior - behavior, upon use of a nonportable or erroneous
>program construct, or erroneous data, or of indeterminately valued objects,
>for which the standard imposes no requirements."
>And 3.5.7
>"If an object that has automatic storage duration is not initialized
>explicitly, its value is indeterminate."
>Sounds like any use of the value, even adding 0, is undefined.

I would be happy to agree, but still am not quite convinced.  Is it true
that the standard imposes no requirements in this case?  Examples have been
posted for other problems in the past, where the values of variables were
indeterminate, but the standard still imposed some requirements; the values
had to be within some known set of possibilities.  Does an uninitialized
int variable also have to have a value within some known set of possibilities,
i.e. in the range INT_MIN to INT_MAX?  I believe the standard is unclear.
--
Norman Diamond                diamond@jit.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
Pardon me?  Or do I have to commit a crime first?
Newsgroups: comp.std.c
From: mike@taumet.com (Mike Ball)
Subject: Re: uninitialized++;
Organization: TauMetric Corporation
Date: Wed, 30 Dec 1992 17:21:42 GMT

diamond@jit533.jit.dec.com (Norman Diamond) writes:

>In article <9236508.13290@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>>hbf@gandalf.uio.no (Hallvard B Furuseth) writes:
>>>Can this fail  - on some machine?  - in ANSI?
>  main () { int uninitialized; uninitialized += 0; return 0; }
>I think this one is not allowed to fail.

To quote from the standard., section 1.6
"Undefined behavior - behavior, upon use of a nonportable or erroneous
program construct, or erroneous data, or of indeterminately valued objects,
for which the standard imposes no requirements."

And 3.5.7
"If an object that has automatic storage duration is not initialized
explicitly, its value is indeterminate."

Sounds like any use of the value, even adding 0, is undefined.
-- 
Michael S. Ball (mike@taumet.com)
TauMetric Corporation
Newsgroups: comp.std.c
From: msb@sq.sq.com (Mark Brader)
Subject: Overflow in constant expression (was: Standard conformance and GCC 2.3.3)
Organization: SoftQuad Inc., Toronto, Canada
Date: Wed, 30 Dec 92 07:50:41 GMT


> #2)  GCC fails to detect the error in the following code, even when the
>      -pedantic-errors option is used.
> 
> unsigned long overflow = LONG_MAX + 3; /* ERROR */

I presume this is being called erroneous because of the constraint:

#  Each constant expression shall evaluate to a constant that
#  is in the range of representable values for its type.

in section 3.4 (ANSI) / 6.4 (ISO).  However, 3.4/6.4 also says:

#  The semantic rules for evaluation of a constant expression
#  are the same as for non-constant expressions.

This presumably includes the assertion in 3.3/6.3:

#  If an "exception" occurs during the evaluation of an expression
#  (that is, if the result is not mathematically defined or not in
#  the range of representable values for its type), the behavior
#  is undefined.

Since the constraint on the constant-expression applies to the *result*
of evaluating it, but the undefined behavior due to overflow applies
*during* the evaluation, I think "undefined behavior" wins.  That is,
the compiler is allowed to ignore the overflow and compute some value
for the constant-expression that is a valid long value.  Having done
so, it has satisfied the constraint and need not report an error.

It may be asked what, in that case, the words "in the range of
representable values for its type" are doing in 3.4/6.4.  And my
answer is that I don't know; the Rationale is silent on the point.
It seems to me that the words are entirely redundant in this context.
Maybe they were an attempt to specify that the expression had to
evaluate without any exceptions occurring, but if so, I think the
attempt was unsuccessful.
-- 
Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, msb@sq.com
#define	MSB(type)	(~(((unsigned type)-1)>>1))

This article is in the public domain.
From: volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe)
Newsgroups: comp.std.c
Subject: Re: Struct hack one last time (one last time)
Date: 3 Jan 93 22:07:29 GMT
Reply-To: volpe@ausable.crd.ge.com
Organization: GE Corporate Research & Development

In article <1993Jan1.173852.26630@taumet.com>, steve@taumet.com (Steve Clamage) writes:
|> mjs@hubcap.clemson.edu (M. J. Saltzman) writes:
|> 
|> >In a previous article (now expired at my site), I asked if the
|> >notorious "struct hack" was still conformant if the tail array in the
|> >struct was of type other than char.  Since no-one ever replied, I'll
|> >ask one more time.
|> 
|> I don't see that the type of the array makes any difference.

When dealing with malloced storage, it shouldn't, since such storage may be 
used for an array of any type.

|> 
|> I do believe that the hack is not strictly conforming, however, since
|> you would be using array indices outside the declared array bounds
|> (char or double makes no difference).  The results of doing so are

It's not outside the bounds of the malloced array.

|> undefined.  Nonetheless, I don't know of any implementations where this
|> would not work.
|> 
|> I have thought of a plausible implementation where the struct hack
|> would fail, however.
|> 
|> An implementation is allowed to add padding to the end of a struct.

Only for alignment purposes. The Standard is pretty clear on that.

|> Suppose that the implementation adds space to the end of each struct
|> type where it encodes information used for run-time error checking.
|> The struct hack would fail in this case, since it would overwrite data
|> used by the run-time system.  I believe the implementation would still
|> be conforming, since we are in the arena of undefined behavior.

I disagree that we are in the area of undefined behavior, but regardless,
your implementation is non-conforming. Consider the following strictly
conforming program:

int main(void)
{
  struct foo {
    double field[1];
  };

  struct bar {
    double field[2];
  };

  union both {
    struct foo small;
    struct bar big;
  };

  union both bothvar;
  bothvar.big.field[1] = 1.0;
  bothvar.small.field[0] = 0.0;
  return 0;
}

Your hypothetical implementation would store padding at the end of each
structure type in which it would record the dimensions of the "field" 
member of each struct. But then writing into bothvar.big.field[1] would
presumably overwrite this dimension information in bothvar.small, causing
strange bounds errors when trying to write into bothvar.small.field[0].

|> -- 
|> 
|> Steve Clamage, TauMetric Corp, steve@taumet.com

-- 
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
Newsgroups: comp.std.c
From: rfg@netcom.com (Ronald F. Guilmette)
Subject: Re: Overflow in constant expression (was: Standard conformance and GCC 2.3.3)
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Wed, 30 Dec 1992 09:39:06 GMT

In article <1992Dec30.075041.10907@sq.sq.com> msb@sq.sq.com (Mark Brader) writes:
+
+> #2)  GCC fails to detect the error in the following code, even when the
+>      -pedantic-errors option is used.
+> 
+> unsigned long overflow = LONG_MAX + 3; /* ERROR */
+
+I presume this is being called erroneous because of the constraint:
+
+#  Each constant expression shall evaluate to a constant that
+#  is in the range of representable values for its type.

Yes.

+in section 3.4 (ANSI) / 6.4 (ISO).  However, 3.4/6.4 also says:
+
+#  The semantic rules for evaluation of a constant expression
+#  are the same as for non-constant expressions.
+
+This presumably includes the assertion in 3.3/6.3:
+
+#  If an "exception" occurs during the evaluation of an expression
+#  (that is, if the result is not mathematically defined or not in
+#  the range of representable values for its type), the behavior
+#  is undefined.
+
+Since the constraint on the constant-expression applies to the *result*
+of evaluating it, but the undefined behavior due to overflow applies
+*during* the evaluation, I think "undefined behavior" wins.

Well, you're wrong.  x3j11 has already ruled on this exact issue. In
Technical Information Bulletin #1, request for interpretation #31
(and its response) make it quite clear that as fas as x3j11 is concerned,
the expression (LONG_MAX + 3), when appearing in a context requiring
a constant expression, is a constraint violation.  Interestingly enough,
it is also x3j11's interpretation (or so I have been led to believe)
that the expression (ULONG_MAX + 3) does *not* violate any constraint!
(But that's an entirely separate issue.)


// Ron ("Loose Cannon") Guilmette    uucp: ...uunet!lupine!segfault!rfg
//
//      "On the one hand I knew that programs could have a compelling
//       and deep logical beauty, on the other hand I was forced to
//       admit that most programs are presented in a way fit for
//       mechanical execution, but even if of any beauty at all,
//       totally unfit for human appreciation."
//                                              -- Edsger W. Dijkstra
-- 

// Ron ("Loose Cannon") Guilmette    uucp: ...uunet!lupine!segfault!rfg
//
//      "On the one hand I knew that programs could have a compelling
//       and deep logical beauty, on the other hand I was forced to
//       admit that most programs are presented in a way fit for
//       mechanical execution, but even if of any beauty at all,
//       totally unfit for human appreciation."
//                                              -- Edsger W. Dijkstra
Newsgroups: comp.std.c
From: rfg@netcom.com (Ronald F. Guilmette)
Subject: Compatability of enum types and integer types
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Mon, 21 Dec 1992 22:56:04 GMT

The ANSI C standard says (in 3.5.2.2):

	"Each enumerated type shall be compatible with an integer type;
	the choice of type is implementation-defined."

I am having a polite disagreement with one implementor regarding the
proper interpretation of this statement.

I interpret it to mean that there *must* exist some integer type `T'
such that:

		enum E { red, green, blue };

		enum E object;
		T object;

		enum E *ptr;
		T *ptr;

... is a valid translation unit.

The person on the other side of this discussion seems to be claiming that
indeed the standard requires the existence of such an integer type, but
that the implementation may "put the fix in" so that no matter what type
you try to use for `T', the implementation will say "Sorry.  You guessed
wrong.  I'm using a different integer type as the `compatible' type for
that particular enum type."

Does this sound like dirty pool or what?

-- 

// Ron ("Loose Cannon") Guilmette    uucp: ...uunet!lupine!segfault!rfg
//
//      "On the one hand I knew that programs could have a compelling
//       and deep logical beauty, on the other hand I was forced to
//       admit that most programs are presented in a way fit for
//       mechanical execution, but even if of any beauty at all,
//       totally unfit for human appreciation."
//                                              -- Edsger W. Dijkstra
From: rfg@netcom.com (Ronald F. Guilmette)
Subject: OOPS!  Make that 15 GCC 2.3.3 bugs!
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Wed, 30 Dec 1992 09:24:40 GMT

It has been brought to my attention that 5 of the 20 bugs I reported for
the recent 2.3.3 release of GCC were in fact non-bugs.

Specifically, #1, #16, and #17 all involve undefined behavior, and thus,
diagnostics are not strictly required in those cases.

Separately, items #14 and #15 were simply bogus.  I claimed that GCC was
failing to issue errors for erroneous code when in fact the code given
in the examples for those items was perfectly legitimate ANSI C code.

I sincerly apologize for any confusion these mistakes might have caused.

To the best of my knowledge, all of the other 15 items do in fact repre-
sent deviations (on GCC's part) from the letter of the ANSI C standard.

(This is both one of the benefits and one of the hazards of posting to
the comp.std.c newsgroup... i.e. you find out almost immediately if
anything you have said is wrong! :-)


// Ron ("Loose Cannon") Guilmette    uucp: ...uunet!lupine!segfault!rfg
//
//      "On the one hand I knew that programs could have a compelling
//       and deep logical beauty, on the other hand I was forced to
//       admit that most programs are presented in a way fit for
//       mechanical execution, but even if of any beauty at all,
//       totally unfit for human appreciation."
//                                              -- Edsger W. Dijkstra
-- 

// Ron ("Loose Cannon") Guilmette    uucp: ...uunet!lupine!segfault!rfg
//
//      "On the one hand I knew that programs could have a compelling
//       and deep logical beauty, on the other hand I was forced to
//       admit that most programs are presented in a way fit for
//       mechanical execution, but even if of any beauty at all,
//       totally unfit for human appreciation."
//                                              -- Edsger W. Dijkstra
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.std.c
Subject: Re: pointer comparison
Date: 23 Dec 92 16:56:36 GMT
Organization: McGill Research Centre for Intelligent Machines

Well, it's been a couple of days, and I'm about to leave, and *nobody*
has replied (as far as our news server knows), so I'll stick my neck
out in public again....

In article <18221@autodesk.COM>, larsn@Autodesk.COM (Lars Nyman) writes:

> I *think* there is language in the standard that says something to
> the effect that comparisons of pointers to two objects that are NOT
> members of the same aggregate or union object is undefined (with one
> exception - one or both pointers pointing past the last object of an
> array).

The actual situation is close.  For the time being, let us consider
pointers pointing one element past the end of an array as actually
pointing into that array.  With that proviso, pointer comparison using
<, <=, >, or >= is undefined when the two pointers don't point into the
same object.

Pointer comparison using == or != is always well-defined, and the
pointers compare equal exactly when they point to the same thing (and
!= is the complement of ==).

> So, if I have two different objects of same type, and they are not in
> the same array or aggregate, the result of comparing pointers to them
> is undefined !!???

Yes, except with == or !=.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: jss@lucid.com (Jerry Schwarz)
Subject: Re: Maximum depth of #if preprocessing directives
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Thu, 31 Dec 92 02:33:41 GMT

Jss:
|> >Just to put my cards on the table.  X3J16/SC22 (C++ standards
|> >committee) is sharply divided on whether to have a section on
|> >limits.  Some of us, including myself, argue that without such
|> >a section any limit is a bug. With such a section arbitrary limits
|> >are somehow condoned as suggested by Norman's comment, and we
|> >don't want to condone any limits.
|> 

Gordon Burditt
|> How can you possibly avoid some kind of limit?  Even an implementation
|> that uses arbitrary-precision arithmetic for something such as
|> #if nesting level is going to have SOME limit, like 
|> 2^(MAXLONG*sizeof(unsigned long)*CHAR_BIT) (where ^ is an exponentiation
|> operator), even if it's outrageously large.  
|> 

Jss:
Of course I'll run out of some resource eventually, but chances
are it will not translate directly into any of the numbers in
the standard, and it may vary from run to run.  Why should
the particular limits in the standard be singled out for special
treatment? 

My contention is that these limits are a quality of implementation
issue rather than a conformance issue. And as such don't belong in
the standard proper.

Most of the actual limits in the C standard are ridiculously low. 
If I tried to promulgate a compiler that enforced these limits on a 
UNIX workstation (which is the market Lucid sells into) I doubt that I 
would get a single customer.   

  -- Jerry Schwarz

Newsgroups: comp.std.c
From: diamond@jit533.jit.dec.com (Norman Diamond)
Subject: Re: definition of strNcpy
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Tue, 22 Dec 1992 01:20:35 GMT

In article <BzMGp3.Hwr@math.uwaterloo.ca> rbutterw@math.uwaterloo.ca (Ray Butterworth [MFCF]) writes:
>As an aside, does anyone ever actually use strncat?
>If the "N" were the total length of the data including what is already
>in the string, it might be useful.

Remember, a language with gets() and other such niceties is intended for
hacking, not for security.  The "N" is intended to bring over a known portion
of the source string, not to protect other stuff near the target.  Now this
raises the question of why memcpy() was invented, and I don't know the answer.

On a more serious note, people actually do use gets().  I'd worry about this
kind of dangerous stuff long before caring about silly things like strncat().
--
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: jet@boxer.nas.nasa.gov (J. Eric Townsend)
Subject: Re: Maximum depth of #if preprocessing directives
	<1992Dec29.001933.25655@lucid.com>
Organization: Numerical Aerodynamic Simulation, NASA Ames
Date: 28 Dec 92 17:40:30

"jss" == Jerry Schwarz <jss@lucid.com> writes:
jss> If a compiler can imposes arbitrary limits, is there any
jss> constraint on the nature of such limits? For example, could I
jss> impose a limit on the number of identifiers containing the
jss> sequence "xyyzz".  If not why not?

My real complaint is twofold:
 - there is no documentation of the maximum depth for the compiler in
question.
 - the producer of the compiler tends to hide behind ANSI whenever I
complain, so I was looking for *some* sort of guidlines on
restrictions.

I read 2.2.4.1 footnote 8 as meaning "if ansi doesn't have a
translation limit, then please, please, please don't build one into
your compiler".




--
             J. Eric Townsend --  jet@nas.nasa.gov -- 415.604.4311
              '92 R100R, DoD# 0378, BMWMOA, AMA, ACLU, EFF, CPSR
Newsgroups: comp.std.c