HDTenEightyP/NetNews huggingface dataset:
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:45:01 GMT
Reply-To: volpe@ausable.crd.ge.com
Organization: GE Corporate Research & Development

In article <1993Jan2.072908.21929@sq.sq.com>, msb@sq.sq.com (Mark Brader) writes:
|> > > [Is] the notorious "struct hack" was still conformant if the tail array
|> > > in the struct [is] of type other than char[?] ... My reading of the
|> > > earlier thread on this topic was that the hack was indeed legal, but
|> > > all the previous examples used an array of char in their examples.
|> > > Thus, is there any reason it would not be legal to declare:
|> > >	struct vector {
|> > >		int  size;
|> > >		double v[1];
|> > >	} *vec;
|> > > and then code (for example):
|> > >	vec = malloc(sizeof(struct vector) + (n - 1) * sizeof(double));
|> > >	vec->size = n;
|> > >	for ( i = 0;  i < vec->size;  i++ )  vec->v[i] = 0.0;
|> 
|> I previously believed that this code was indeed legal, but I have lately
|> come to the opposite opinion.  Return to the classic struct hack:
|> 
|> 	struct hack /* well, what else? */ {
|> 		int len;
|> 		char arr[1];
|> 	} *p;
|> 	p = malloc(sizeof(struct hack) + n-1);  /* where n > 1 */
|> 
|> In this, access to p->arr[1] is legal because p->arr decays to a
|> pointer which points to some element of the object returned by
|> malloc -- you can identify which one by using offsetof -- and
|> the pointer p->arr+1 also points to some element of this object,
|> thus meeting the requirement specified by 3.3.6/6.3.6.

Agreed.

|> In the other example using double, we still know that the pointer
|> obtained by decay of vec->v points to a double which is somewhere
|> within the object returned by the malloc(), but we do NOT know that it
|> points to a double that would be an element of that object if we viewed
|> it as an array of doubles.  And this distinction, I fear, is critical.

Ah! But is that necessary? I don't think so. As long as it points to a double
that would be an element of that object if we viewed it as an array
of SOMETHING. Suppose we viewed the malloced storage as an array of
the following structs:
  
  struct vec2 {
    int size;
    double v[2];
  }

The above struct has one more element in the "v" field than the one
in question. Thus, even though &vec->v[1] may not point to a double that
would be an element of the malloced storage if viewed as an array of
doubles, it *would* point to a double that would be a (component of) an
element of the malloced storage if viewed as an array of "struct vec2". 
Thus, the legitimacy of the struct hack is restored.

-Chris

-- 
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
Newsgroups: comp.std.c
From: diamond@jit533.jit.dec.com (Norman Diamond)
Subject: Re: Maximum depth of #if preprocessing directives
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Fri, 25 Dec 1992 01:27:02 GMT

In article <JET.92Dec24133237@boxer.nas.nasa.gov> jet@boxer.nas.nasa.gov (J. Eric Townsend) writes:
>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?

It looks like no such limit exists, so an implementation could set it at 1.
I'm not sure if an implementation could set it at 0.  Of course, any
reasonable implementation could get a limit of 32767 by using a few ints
(if the implementation is itself coded in C :-) so I think there "shouldn't"
be any practical problem.  But "shouldn't" != "can't", sigh....
--
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: leisner@wrc.xerox.com ( Marty Leisner)
Subject: generating prototypes automatically
Reply-To: leisner@eso.mc.xerox.com
Organization: Xerox
X-Newsreader: TIN [version 1.1 PL8]
Date: Mon, 28 Dec 1992 01:36:06 GMT

What tools are around to generate prototypes automatically (i.e. all functions which aren't static...)

It doesn't seem like something I should do by hand...

--
marty
leisner.henr801c@xerox.com  leisner@eso.mc.xerox.com
Member of the League for Programming Freedom
Newsgroups: comp.std.c
From: sja@snakemail.hut.fi (Sakari Jalovaara)
Subject: Re: <iso646.h>
Organization: Helsinki University of Technology, Finland
Distribution: comp
Date: 21 Dec 92 17:08:03 GMT


> On the other hand, if you are in an environment where some or all of
> the "national" characters have been redefined, making the standard
> ASCII graphics unavailable,

So far, there has been no proof that such an environment exists.
									++sja
From: erik@naggum.no (Erik Naggum)
Newsgroups: comp.std.c
Subject: Re: <iso646.h>
Date: 27 Dec 92 21:14:40 GMT
Reply-To: Erik Naggum <enag@ifi.uio.no>

[Sakari Jalovaara]
|
|   > On the other hand, if you are in an environment where some or all of
|   > the "national" characters have been redefined, making the standard
|   > ASCII graphics unavailable,
|
|   So far, there has been no proof that such an environment exists.

It exists, but programmers never experience it.  Good C programmers
never write natural language text in the source files, anyway, and so
have _no_ problems with the soi disant "national characters".  Bad and
mediocre C programmers who have a problem with national characters,
should load a new font or buy a new terminal, not impose trigraph and
digraph bullshit on the world.  Programmers and/or companies hiring them
who can't afford a new terminal with the proper character set should be
put on a black list published widely within the user communities.

Enough of this stupidity, already.

It turned out that there is _one_ Norwegian, in a little over 4,200,000,
who was sufficiently interested in the work in progress in JTC 1/SC 22
to want to establish a SC 22 "peer group" who could vote on SC 22 work,
and now we don't even have O (Observatory) status in SC 22.  If the same
is true for Denmark, and I have some reason to think it is, you should
direct your flames towards Keld Simonsen <keld@dkuug.dk>, and ask him to
buy a new terminal instead of harrassing the C community with his funny
proposals.

If he can't afford it, despite drawing massive funds from the Nordic
Council for his "7-bit character set backward compatibility" dinosaur,
we could all send $1 to Danish Standards and request that he get a new
terminal, or a new machine if enough people send money, as a belated
Christmas present from The Net.  He may not enjoy it, but I'm sure the
entire C community will, and for many, many years to come.

Happy New Year, C community!  Good grief.

Best regards,
</Erik>
--
Erik Naggum                 ISO  8879 SGML                    +47 295 0313
                            ISO 10744 HyTime
<erik@naggum.no>            ISO  9899 C                 Memento, terrigena
<SGML@ifi.uio.no>           ISO 10646 UCS             Memento, vita brevis
Newsgroups: comp.std.c
From: diamond@jit533.jit.dec.com (Norman Diamond)
Subject: Re: pointer comparisons
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Thu, 31 Dec 1992 03:35:35 GMT

In article <1hsdg8INN5jm@urmel.informatik.rwth-aachen.de> berg@physik.tu-muenchen.de (Stephen R. van den Berg) writes:
>#include <stdlib.h>
>void*a,*b;
>main()
>{ int i;
>  a=malloc(1); b=malloc(1);
>  i+=a>b;

[Irrelevant portions of the code deleted to save space.]
The comparison operators are defined under some conditions, always including
that they point into the same object (and/or one element past an array object).
Your a and b point to different objects, so the behavior is undefined.
--
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: jss@lucid.com (Jerry Schwarz)
Subject: Re: Maximum depth of #if preprocessing directives
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Tue, 29 Dec 92 00:19:33 GMT

In article <BzsK12.5Ky@jrd.dec.com>, diamond@jit533.jit.dec.com (Norman Diamond) writes:
|> In article <JET.92Dec24133237@boxer.nas.nasa.gov> jet@boxer.nas.nasa.gov (J. Eric Townsend) writes:
|> >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?
|> 
|> It looks like no such limit exists, so an implementation could set it at 1.

Please justify the claim that compilers can set arbitrary limits
for anything other than the features explicitly mentioned as limitable
by the standard.  On what basis can an implementation justify rejecting
a program that happens to exceed a limit of its devising such a limit.
What constraint or semantic requirement does it violate?

If a compiler can imposes arbitrary limits, is there any constraint
on the nature of such limits? For example, could I impose a limit on
the number of identifiers containing the sequence "xyyzz".   If not
why not?

  -- Jerry Schwarz

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.






Newsgroups: comp.std.c
From: jimlynch@netcom.com (Jim Lynch)
Subject: Re: pointer comparisons
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Fri, 1 Jan 1993 14:21:56 GMT

In article <C04LIz.3DG@NCoast.ORG> brown@NCoast.ORG (Stan Brown) writes:
>In article <1hsdg8INN5jm@urmel.informatik.rwth-aachen.de> berg@physik.tu-muenchen.de (Stephen R. van den Berg) writes:
>>What about the following program:     [of which I show only the salient parts]
>>void*a,*b;
>>
>>main()
>>{ int i;  /* initial assignment deleted */
>>  a=malloc(1); b=malloc(1);
>>  i+=a>b; 
>>  printf("%d\n",i);
>>  return i;
>>}
>>---------------------------------------
>>
>>Is this program *always* required to print or return "3"?
>
>I believe this program is not obligated to print or return _anything_,
>but may, in John Woods's happy phrase, "cause demons to fly out of your
>nose."

Aside from which 'i' has an undefined value...
From: larsn@Autodesk.COM (Lars Nyman)
Newsgroups: comp.std.c
Subject: pointer comparison
Date: 23 Dec 92 00:14:52 GMT


There is a thread in comp.std.c++ about comparisons of pointers
to objects that caused me to think about the situation in ANSI C.
I don't have the ANSI C standard and thus resort to ask here.

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).

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 !!???

Which would mean that in the following trivial code:

	typedef struct { int i; } foo;

	foo f1, f2;
	foo* pF1 = &f1;
	foo* pF2 = &f2;

	assert( pF1 != pF2 );

the value of 'pF1 != pF2' is undefined and the assertion may/can fail !!!

Can somebody, please, correct me and tell me what I am overlooking.
What in the standard guarantees that pointers to two different objects
are guaranteed to compare unequal ?

Lars Nyman

(*If* my reasoning is correct... wouldn't this also allow malloc(0) to
 return whatever it wants, including repeatedly the same value (except 
 maybe for NULL), since the result of a comparison between any two pointers 
 obtained by malloc() would be undefined).
Newsgroups: comp.std.c
From: mjs@hubcap.clemson.edu (M. J. Saltzman)
Subject: Struct hack one last time (one last time)
Organization: Clemson University, Clemson SC
Date: Thu, 31 Dec 1992 15:39:31 GMT

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.

My reading of the earlier thread on this topic was that the hack was
indeed legal, but all the previous examples used an array of char in
their examples.  Thus, is there any reason it would not be legal to 
declare:

	struct vector {
		int  size;
		double v[1];
	} *vec;

and then code (for example):

	vec = malloc(sizeof(struct vector) + (n - 1) * sizeof(double));
	vec->size = n;

	for ( i = 0;  i < vec->size;  i++ )  vec->v[i] = 0.0;

Thanks again for your time and assistance.
-- 
		Matthew Saltzman
		Clemson University Math Sciences
		mjs@clemson.edu
Newsgroups: comp.std.c
From: rbutterw@math.uwaterloo.ca (Ray Butterworth [MFCF])
Subject: Re: definition of strNcpy
Organization: Math Faculty Computing Facility, University of Waterloo
Date: Mon, 21 Dec 1992 18:29:26 GMT

In article <1992Dec18.180358.24428@dms.agames.com> lipson@dms.agames.com (Pete Lipson) writes:
>Pete Lipson (lipson@dms.agames.com) wrote:
>: i was just badly bitten by my interpretation of how strncpy works.
>                            ... of course i meant strnCAT ^^^

As an aside, does anyone ever actually use strncat?
i.e. what is its intended use?

If the "N" were the total length of the data including what is already
in the string, it might be useful.  But as it is, one has to do
something like:
   strncat(out, in, sizeof(out)-strlen(out)-1);
i.e. as long as one has to call strlen on the first argument,
what is the point of having strncat go through the trouble of
finding the end of the string again?
From: gordon@sneaky.lonestar.org (Gordon Burditt)
Subject: Re: Maximum depth of #if preprocessing directives
Organization: Gordon Burditt
Date: Wed, 30 Dec 1992 00:16:40 GMT

>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.

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.  

Is 32767 an unreasonable limit on the nesting level?  Well, it wouldn't
cost that much to put the counts in a 32-bit long.  Do I need to go to 
(about) 2^(2^37)?  (about 137 billion bits in the number)  Or is that 
too small?

					Gordon L. Burditt
					sneaky.lonestar.org!gordon
From: jss@lucid.com (Jerry Schwarz)
Subject: Re: Compatability of enum types and integer types
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Tue, 22 Dec 92 20:39:38 GMT

In article <1992Dec21.225604.18749@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
|> 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.

It requires more for

	enum E object ;
	int object ;

to be legal than that E and int be compatible. 3.1.2.6 
says that the "type of the identifier becomes the composite type".
It also gives the rules for determining a composite type and
says nothing about combining enums and integer types.  Granted,
this isn't a constraint section, but if there isn't a composite
type then I think the compiler is justified in treating the above
as an error.

[Maybe I'm stretching. I feel strongly that the above ought
to be an error and I went looking for a way to make it so. I'm
assuming that the original x3j11 committee didn't intend to force
us to accept code like the above, but I wasn't a member.]

    -- Jerry Schwarz





  -- Jerry Schwarz
Newsgroups: comp.std.c
From: diamond@jit533.jit.dec.com (Norman Diamond)
Subject: Re: Mixing prototype and non-prototype issues
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Fri, 25 Dec 1992 01:41:18 GMT

In article <1992Dec24.234622.29882@ll.mit.edu> tadams@ll.mit.edu ( Tony Adams) writes:
>an example of a function call which is not governed by a prototype, calling
>a (non-visible) function defined in prototype syntax.
>Would someone please report the section numbers of the standard that
>describe this programs combination of prototype and non-prototype usage.
>            float   f=1.0;
>            func(f); /* no declaration in prototype form is visible */
>    /* definition of func() is not visible  from main() */
>    func(float f) { printf("%f\n",f); }
>    c.c:11: warning: type mismatch with previous implicit declaration
>    c.c:6: warning: previous implicit declaration of `func'

ANSI Classic section 3.3.2.2, page 41 lines 28 to 32:  "If the expression
that precedes the parenthesized argument list in a function call consists
solely of an identifier, and if no declaration is visible for this identifier,
the identifier is implicitly declared exactly as if, in the innermost block
containing the function call, the declaration
    extern int identifier();
appeared."  Therefore your expression func(f) implies a declaration
    extern int func();

Your actual definition occurs later and has a parameter type list.

ANSI Classic section 3.5.4.3, page 69 lines 14 to 18:  "If one type has a
parameter type list and the other type is specified by a function declarator
that is not part of a function definition and that contains an empty
identifier list, the parameter list shall not have an ellipsis terminator
and the type of each parameter shall be compatible with the type that
results from the application of the default argument promotions."
This is in a Semantics section, so a diagnostic is not required, though it
is allowed, and any other undefined behavior is also allowed.
--
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: msb@sq.sq.com (Mark Brader)
Subject: Limits in standard (was: Maximum depth of #if preproc...)
Organization: SoftQuad Inc., Toronto, Canada
Date: Thu, 31 Dec 92 19:38:39 GMT

> > > 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
> > > a section any limit is a bug....  we don't want to condone any limits.
> > How can you possibly avoid some kind of limit?
> 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. ... My contention
> is that these limits are a quality of implementation issue rather
> than a conformance issue.

The C standard does condone limits, but the actual wording is:

#  The implementation shall be able to translate and execute at least
#  one program that contains at least one instance of every one of the
#  following limits.  [Footnote: Implementations should avoid imposing
#  fixed translation limits wherever possible.]

I believe that the intended thrust of these words in 2.2.4.1/5.2.4.1 is:
"We would really rather that you don't fix limits at all, but IF YOU MUST,
then those limits should be at least as large as the following."

Whether fixed limits are an insupportable evil or not is a religious issue,
on which there seem to be three points of view:

1. Fixed limits are so evil that an implementation should be forbidden
   from having them.

2. Fixed limits are so much a quality-of-implementation issue that a
   standard should not be allowed to mention them.

(This is the point of view quoted above.)

3. Fixed limits are a quality-of-implementation issue, but ridiculously
   small fixed limits could constrain the programmer so much that the
   standard should prohibit them.

(This is the point of view of the C standard, and mine.)

Discussion of what the C++ standard should do, of course, belongs in
comp.std.c++ and not here.
-- 
Mark Brader		    At any rate, C++ != C.  Actually, the value of the
SoftQuad Inc., Toronto	    expression "C++ != C" is implementation-defined.
utzoo!sq!msb, msb@sq.com				-- Peter da Silva
				[Actually, it's undefined.]
This article is in the public domain.
From: berg@physik.tu-muenchen.de (Stephen R. van den Berg)
Newsgroups: comp.std.c
Subject: pointer comparisons
Date: 30 Dec 1992 14:59:20 GMT
Organization: Rechnerbetrieb Informatik - RWTH Aachen
NNTP-Posting-Host: ikki.informatik.rwth-aachen.de
Originator: berg@ikki

What about the following program:
--------------------test.c--------------
#include <stdio.h>
#include <stdlib.h>

void*a,*b;

main()
{ int i;
  a=b=0;
  i=a==b; i+=a!=b;
  a=malloc(1); b=malloc(1);
  i+=a>b; i+=a>=b; i+=a<b; i+=a<=b;
  printf("%d\n",i);
  return i;
}
---------------------------------------

Is this program *always* required to print or return "3"?
-- 
Sincerely,                                  berg@pool.informatik.rwth-aachen.de
           Stephen R. van den Berg (AKA BuGless).    berg@physik.tu-muenchen.de

"Good moaning!"
Newsgroups: comp.std.c
From: bill@Celestial.COM (Bill Campbell)
Subject: Re: Maximum depth of #if preprocessing directives
Organization: Celestial Software, Mercer Island, WA
Date: Wed, 30 Dec 1992 18:11:24 GMT

In <1992Dec29.001933.25655@lucid.com> jss@lucid.com (Jerry Schwarz) writes:

.......
: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.

I'm in complete agreement with limits as bugs.  IMHO the hardware/OS 
should be the only limiting factor.  The Microsoft C compiler
that came with Tandy 16/6000 Xenix frequently bombed out because its
symbol table was a fixed size!

Bill
-- 
INTERNET:  bill@Celestial.COM   Bill Campbell; Celestial Software
UUCP:   ...!thebes!camco!bill   6641 East Mercer Way
             uunet!camco!bill   Mercer Island, WA 98040; (206) 947-5591
SPEED COSTS MONEY -- HOW FAST DO YOU WANT TO GO?
Newsgroups: comp.std.c
From: bill@twwells.com (T. William Wells)
Newsgroups: comp.std.c
Subject: Re: pointer comparisons
Date: 31 Dec 92 06:48:38 GMT
Organization: None, Mt. Laurel, NJ

In article <1hsdg8INN5jm@urmel.informatik.rwth-aachen.de> berg@physik.tu-muenchen.de (Stephen R. van den Berg) writes:
:   a=malloc(1); b=malloc(1);
:   i+=a>b; i+=a>=b; i+=a<b; i+=a<=b;
:
: Is this program *always* required to print or return "3"?

No. It may core dump or otherwise behave in undefined ways.
Relationals require that the pointers be into (or at the end of)
the same object.

---
Bill                            { rutgers | decwrl | telesci }!twwells!bill
bill@twwells.com
Newsgroups: comp.std.c