HDTenEightyP/NetNews huggingface dataset:
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Zero-length structures and pointer comparisons
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Wed, 23 Dec 1992 17:46:53 GMT

In article <1992Dec20.201212.8974@lth.se> dag@bellman.control.lth.se (Dag Bruck) writes:
>I think we're sliding away from the original discussion.
>
>The goal was to write data structures that use the ordering of
>pointers to improve search time.  What I need is mechanism that
>compares the pointers -- what they actually point to is not relevant.

	Of course it is. You want < to be compatible with ==,
and the ARM says a==b if a and b point to the same object.

	Without this requirement, a<b==0 for all a,b is a perfectly
legal total order.

>
>I would finally like to return to a claim I made earlier, but nobody
>has commented on (as far as I know).  I belive that even if you
>imposed a total ordering on pointers in a segmented architecture
>(e.g., Inte 8086 family), compilers would be able to handle the
>follwing common case efficiently:

	Now hang on there. The 8086 in my view does not have a segmented
address space, it has a linear address space. The 286 and 386 have
real segmented address spaces.

	Doing < on the 8086 would be just about the same overhead
as == plus a bit (comparisons for equality are slightly simpler
than less). Just guessing that these operations would be about 
5-20 times slower than a single register to register comparison.
I.e., significant but not insummountable.

	On the 386, if there was no aliasing, a slight mess
converting 32 bit pointer to 48 bit ones before a 48 bit
compare. 
>
>	void zap(int* a, unsigned n)
>	{
>		for (int* p = a; p < a+n; p++)
>			*p = 0;
>	}
>
>and produce the same code as today (without the total ordering).
>After all, the assignment "p = a" says that "p" must point to the same
>segment as "a".  Any comments?

	True. Sometimes the comparisons could be optimised.
(On the 386. On the 8086, if n>32K, you would not be able to
fit the array in one segment)

	So there remains the conformance issue. Existing
code will be broken. Note: actually it WONT be broken,
vendors simply wont implement this requirement of the standard
in some memory models. (Or they'll provided the dreaded compatibility
switch)



-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.std.c++
From: cmchan@dcs.warwick.ac.uk (C M Chan)
Subject: Array in class
Organization: Department of Computer Science, Warwick University, England
Date: Wed, 30 Dec 1992 17:18:46 GMT


Hi out there,

I am sorry if this is faq for this newsgroup.   Here is my question:

How can I simulate "pointer to char" by an array in a class whose size will be delayed to be
defined at run time?

For example,


          class X {

          private:
                   char string[      ];    /* not define size of the array */
                              ^^^^^^^^       
          public:
                   X(int);

                   ...............
          };


          X::X(int size) {
                 string[size];          /*  define size of string array now  */
                 strcpy(string, "Hello");
          }

Any pointer to this problem will be greatly appreciated.   Thanks in advance.





-- 
C M CHAN         cmchan@dcs.warwick.ac.uk


Newsgroups: comp.std.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Compiler should generate virtual destructors
Organization: Computer Science, University of Melbourne, Australia
Date: Sat, 2 Jan 1993 14:03:43 GMT

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

>I would like to propose that if a class has virtual functions,
>then any destructor generated by the compiler will be virtual
>by default.
>
>Advantages: much safer, ensures correct deletion of objects
>by default.  Removes a source of bugs. Removes the reminder
>that its wise to do this from the FAQ.
>
>Disadvantage: might slow down destruction a little. Can be
>fixed by the programmer explicitly declaring a non-virtual
>destructor.

I think that this situation should cause a compiler warning, rather
than adding another arbitrary rule in the language for programmers to
remember. Bugs would still occur if a programmer accidentally forgot to
make the destructor virtual. A good compiler will generate a warning
in this situation anyway (eg. g++ does, I believe).

Mind you, I do believe that there is a place in the standard for
required warnings. Claims that these are a "quality of implementation"
issue ignore the social effect of standards. There are never *any*
genuinely 100% conformant compilers, no matter what it says on the
box you bought it in. (Read the fine print on the license inside :-( ). 
The truth is that standards provide a strong incentive for compiler
vendors to ship products with certain characteristics. Provided (as
with all other aspects of a standard) that they don't require an
excessive difficulty of implementation, I don't see any good reason
not to include particular required warnings as part of a standard.

[Off the topic, another situation that should have a required warning
is the (void *) to (T *) conversion. It is definitely a hole in the
type system, but making such conversion *illegal* breaks many C programs.
It broke ALL of my C programs (well, ok, except for the hello world ones :-).
A warning would have closed the hole in the type system just as well -
after all, programmers can always achieve the same effect with a cast,
so it doesn't actually "close" the hole anyway - the error message is
just like a warning, except that you have to actually modify the
program text to get it to compile.]

-- 
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!
Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Pointer comparisons
Date: 24 Dec 92 01:12:54 GMT
Organization: Microsoft Corporation

In article <1992Dec18.181029.1061@taumet.com> steve@taumet.com (Steve Clamage) writes:
|Right.  In the C Standard, it is stated explicitly that two pointers
|of the same type which compare equal point to the same object or
|function.  There is no such statment for C++ in the ARM or in the
|current C++ Committee working draft.

What needs to be made clear includes what is meant by "point to the
same object."  As in my example the pointers *do* point to the same object,
and they do compare equal.  It's just that one pointer refers to an
enclosing object, and one pointer the enclosed object.  Same object,
just not identically the same object.  

Also needs to be clarified all the different implications.  If two
pointers which compare equal point to the same object, do two pointers
to 'the same object' compare equal?  Do two pointers not comparing 
equal not point to the same object?  Do two pointers not to the same
object not compare equal?  These issues are much more obvious in C
than in C++.

Ultimately, I do not believe worrying about these pointer "details" 
is very important unless one first decides what properties of object
identity C++ objects must have and why.  The current permission of
C++ compilers to create temporaries at will kind of blows object identity
out of the water.  Why worry about pointer equality, then?

One thing you might want to consider is dividing C++ objects into two categories
-- those with and without virtual functions or virtual bases.  Then 
just require "C" rules on those without virtualness.  But require some
reasonable "object oriented" rules of object identity for those with 
virtualness.

Alternately, just leave it implementation defined ;-)
Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: pointer comparisons
Date: 30 Dec 92 18:46:14 GMT
Organization: Microsoft Corporation

In article <1992Dec27.050118.1628@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
|The desired feature is:
|Two pointers to the same type, which point to distinct objects
|of that type, compare not equal.

Can you define your terms for us?

"Two pointers" means what?

"to the same type" means what?

"distinct objects" means what?

"of that type" means what?

"compare not equal" means what?

I'm sure each of these things seems clear to you, yet they are not.
Newsgroups: comp.std.c++
From: swf@tools3teradata.com (Stan Friesen)
Newsgroups: comp.std.c++
Subject: Re: Zero-length structures and pointer comparisons
Date: 22 Dec 92 21:48:33 GMT
Distribution: world
Organization: NCR Teradata Database Business Unit

In article <1992Dec16.150144.6004@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|> 	In that case it is implementable on all systems
|> 	where (opinion follows, please correct errors)
|> 
|> 	a) void* is big enough to hold all pointer types

This assumption, as written, is violated by compact and medium model on Intel
chips.  I suggest rewording this to:
	a) void* is big enough to hold all object pointer types
					   ^^^^^^
[function pointers are *not* guarenteed to be convertable to void *, and,
in C++, neither are member 'pointers'].

|> 	b) conversions always pad systematically
|> 	c) bitwise comparison is done 
|> 	d) the bits of a pointer cannot be magically changed by the system
|> 	e) a pointer is implemented as an object in contiguous storage
|> ...
|> 
|> 	Certainly, (e) might cause problems on the 80x86 where part of the
|> pointer is implicit and not physically stored. Does it *actually*
|> cause this problem?

In 'small data' models, YES!  There is simply no reason for void* to contain
the segment when all data is in the same segment.

Of course, in paractice, the limitations on the 'small data' models make this lack
of little *practical* concern for ptrcmp() - that is since all data are in the
same segment a segmentless comparison will always work (as long as you use the
*stronger* form of (a) I mention above).

-- 
sarima@teradata.com			(formerly tdatirv!sarima)
  or
Stanley.Friesen@ElSegundoCA.ncr.com
Newsgroups: comp.std.c++
From: pkt@lpi.liant.com (Scott Turner)
Subject: Re: pointer comparisons
Organization: Liant Software Corporation
Date: Thu, 31 Dec 1992 17:02:23 GMT

In article <1992Dec30.184614.5551@microsoft.com> (Jim Adcock) writes:
> Can you define your terms for us?

> "distinct objects" means what?
It means the objects are not identical.  

I was going to say that the standard for C++ needs to spell out what it
means for object to be identical in a better way than just by
     1. An object is a region of storage.
     2. A definition or a new expression reserves the storage
        needed by the object.
These two rules leave things much more loose than necessary when objects
require no storage.  But note that section 1.3 of the working paper 
(The C++ Memory Model) says:

	The constructs in a C++ program create, refer to, access, and
	manipulate objects in memory.  Each object (except bit-fields)
	occupies one or more contiguous bytes.

I missed this a while back when enumerating the features of the ARM and
working paper which supported
> The desired feature is:
>     Two pointers to the same type, which point to distinct objects
>     of that type, compare not equal.
This excerpt from 1.3 gives the general rule I was seeking, because
objects can be distinguished by the storage reserved for them.

The excerpt may raise a few questions.

	How much freedom does it leave a compiler to optimize away
	an object's bytes (by application of the "as if" rule, etc.)?
	I think a good deal of freedom, because the working paper
	doesn't define the results if a program attempts to refer to
	or manipulate the bytes of an object.

	Does it govern base class subobjects?  As I understand it,
	base class subobjects are objects, and hence are covered.

	Does it belong in the C++ standard?  I'd say yes, given that
	compilers will for many practical purposes be able to 
	optimize away unneeded bytes.

--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com
	
Newsgroups: comp.std.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Pointer comparisons
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Mon, 28 Dec 1992 04:37:19 GMT

In article <1992Dec22.174327.8903@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
>Moreover, such padding is in the C++ tradition.  The ARM requires padding 
>in two places, where the principal intent is to support
>
>            p and q point to different objects implies p!=q
>
>    1. 5.3.2 "The size of any class object is larger than zero."
>
>    2. 5.3.3 "This implies that an operator new() can be called with an
>       argument zero.  In this case, a pointer to an object is returned.
>       Repeated such calls return pointers to different objects."
>       [An example follows to demonstrate that the intent is that
>       distinguishable pointers values be returned.]

IF this intent is to be fully supported, additional words would be
required to ensure base subobjects and included member objects
were also padded?

IF these words are not added, then the intent is not supported
fully, and the clauses above might as well be dropped?

I.E. I am asking if there is any point retaining the status
quo, or any other position where full pointer identity
is not supported yet padding is required.


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.std.c
From: mjs@hubcap.clemson.edu (M. J. Saltzman)
Subject: Struct hack one last time
Summary: ...with types other than char
Organization: Clemson University, Clemson SC
Date: Thu, 24 Dec 1992 00:24:38 GMT

I'm sorry if I'm beating a dead horse, but in all the discussion of the 
infamous "struct hack", was it ever resolved if it was legal if the 
truncated array had type other than char?

E.g.

	struct vector {
		int length;
		double value[1];
	} *v;

	...

	v = malloc(sizeof(struct vector) + (n - 1) * sizeof(double));
	/* ignore possible malloc failure at my own peril 8^) */

	v->length = n;

	for ( i = 0;  i < v->length;  i++ )
		v->value[i] = 0.0;

	...

I can't think of a reason why it shouldn't be, but...

If not legal, what was the reasoning, and is there a way around the problem?

Thanks very much.


-- 
		Matthew Saltzman
		Clemson University Math Sciences
		mjs@clemson.edu
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: comp.std.c
Subject: Banning the use of `gets' (was Re: definition of strNcpy)
Date: 24 Dec 92 12:04:58 GMT
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Organization: MIKROS Systemware, Darmstadt/W-Germany

In article <BzMzqC.n0u@jrd.dec.com> diamond@jit.dec.com (Norman Diamond) writes:
>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().

I think Norman made a very good point here.  If in your C-library `gets'
is a single module (I just checked and at least in UNIX SysV.R3 it seems
to be so) you have a choice:  Pull this module out of the library and
into a new one (say, "/lib/libdangerous.l").  So programs using gets
will have an `unresolvable external'.  This should help to alert people
that they should change their programs.  (And if they are desperate they
can still link the programs by adding "-ldangerous" to the cc command line.)
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
Newsgroups: comp.std.c
From: dat@thinkage.on.ca (David Adrien Tanguay)
Subject: Re: Maximum depth of #if preprocessing directives
Organization: Thinkage, Ltd.
Date: Tue, 29 Dec 1992 20:33:55 GMT

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?

Doesn't "8 nesting levels of conditional inclusion" cover it?
(old ANSI 2.2.4.1 page 14 line 3, the second limit)
-- 
David Tanguay       dat@Thinkage.on.ca  dat@Thinkage.com  uunet!thinkage!dat
Thinkage, Ltd.           Kitchener, Ontario, Canada          [43.40N 80.47W]
Newsgroups: comp.std.c
From: khcheng@unix.amherst.edu (KIM HONG CHENG)
Subject: MS C/C++ 7.0 & SDK 3.0 sale
Organization: Amherst College
X-Newsreader: TIN [version 1.1 PL7]
Date: Sun, 3 Jan 1993 21:34:38 GMT

MS C/C++ 7.0 + SDK 3.0
* still in plastic wrap (never been used)
* registration card included
* 45 lb of manuals (all manuals never been used)
* $200 +shipping
(I think this is more than $600)

Hong Cheng
327 Lincoln Ave.
Amherst, MA 01002

413-542-8084 (day)
413-549-4690 (eve & weekend)   

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: Wed, 30 Dec 1992 08:22:47 GMT

In article <1992Dec29.203355.7317@thinkage.on.ca> dat@thinkage.on.ca (David Adrien Tanguay) writes:
>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.

>Doesn't "8 nesting levels of conditional inclusion" cover it?
>(old ANSI 2.2.4.1 page 14 line 3, the second limit)

Yup.  Fooled me too.  In fact, now I find a whole raft of preprocessor
limits limits scattered around 2.2.4.1:
line  3, nesting of #if's;
line  8, length of macro name;
line 12, number of macro names;
lines 15 to 16, numbers of macro parameters and arguments (which seems
           redundant, since arguments must always match parameters);
line 20, nesting of #included files.
I'd say this table represents an example of spaghetti code :-)
--
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: brown@NCoast.ORG (Stan Brown)
Subject: Re: pointer comparisons
Organization: Oak Road Systems, Cleveland Ohio USA
Date: Thu, 31 Dec 1992 13:30:35 GMT

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

Comparing pointers that point to different objects leads to an undefined
result.  See ANSI section 3.3.8 (ISO 6.3.8, I believe).
-- 
Stan Brown, Oak Road Systems                      brown@Ncoast.ORG
Cleveland, Ohio, USA

What's a question that contains the word 'cantaloupe' for no apparent reason?
Newsgroups: comp.std.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: Struct hack one last time (one last time)
Organization: TauMetric Corporation
Date: Fri, 1 Jan 1993 17:38:52 GMT

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.

>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 don't see that the type of the array makes any difference.

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

Steve Clamage, TauMetric Corp, steve@taumet.com
From: diamond@jit533.jit.dec.com (Norman Diamond)
Subject: Re: Compatability of enum types and integer types
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Tue, 22 Dec 1992 01:29:40 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 interpret it to mean that there *must* exist some integer type `T' such that
>		enum E { red, green, blue } object;
>		enum E object;
>		T object;
>... is a valid translation unit.
>The person on the other side of this discussion seems to be claiming 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

Being implementation-defined means that it must be documented.  Regarding
some other implementation-defined matters (e.g. which of two possible results
is obtained from the % operator) most of the regulars in this newsgroup seem
to feel that the implementation must define a result that is identical over
all usages.  This kind of opinion suggests that the documentation must tell
you which type you can use for `T'.

My opinion is that the documentation can tell you that the implementation
plays dirty pool.  However, I seem to be a minority of 1.

Surely an interpretation ruling would carry more weight than any of the above.
--
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."