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: Fri, 18 Dec 1992 19:35:54 GMT

In article <1992Dec16.201044.2968@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>In article <1992Dec15.162202.11231@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>|But Jim, it is not implementation defined, it is required that 
>|pointers to the same object compare equal. It is therefore
>|legal to have a function:
>|
>|	f(X* a, X*b) {
>|	if(a==b) { /* special case, copy b object */ ... }
>|	else *a+=*b;
>|	}
>|
>However, if a strictly conforming implementation is presented with a 
>non-strictly conforming program, such as a program that calls OS
>virtual memory mapping adjustment routines, or programs that send
>pointers off the ends of arrays, or programs who don't properly point
>at objects that correspond to the types of objects they pretend to point
>at .... in all such cases all bets are off.  
>
	I know what you are saying but dont see it.
ARM p74:"two pointers to the same object compare equal".
Any program for which this is not true cannot be conforming,
neither strictly nor non-strictly, it is non-conforming, it is
not in fact a C++ program.

	Or have I got this wrong?

	For this reason I think the ARM requirement is unworkable,
and must be modified. The rule should state that pointers
derived from the same object directly in the program must
compare equal. Pointers obtained from the OS need not follow
this rule, in that case it is implementation defined.
This is the case for pointers way off the end of an array:
it is implementation defined.

	(When I say 'derived' from the same object, I 
am defering the exact definition :-)

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.std.c++
Subject: Re: Zero-length structures and pointer comparisons
Date: 12 Dec 92 16:49:30 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: TIN [version 1.1 + PL8]

Stuart MacMartin (sjm@bcrki65.bnr.ca) wrote:
: In article jbn@lulea.trab.se (Johan Bengtsson) writes:
: >Put differently: the database ID total order and the corresponding
: >transient pointer orders must be order-isomorphic (look it up, I did :-),
: >to ensure that the total pointer order for the addresses of
: >persistent objects mapped into transient memory is consistent between
: >different runs of the same program.

: Aren't we talking about a total ordering that is consistent for the
: duration of the process?

Yes, primarily.

: The OODBMS objects can have an ordering that
: is persistent, but obviously the transient objects won't have a persistent
: ordering.  Do we care if the ordering of persistent objects is the same
: between different runs of the program?  Am I missing something?

A persistent structure that depends on total object ordering needs the
same ordering for all program runs.  As I think you pointed out in
another posting, the ordering need/should not be pointer based for OODBMSs
that use handle objects to refer to persistent objects.

Other OODBMSs that use straight pointers to refer to persistent
objects (e.g. ObjectStore,Texas) must provide a rather special
ptrcmp(void*,void*), or disallow use of ptrcmp() for persistent
objects (may be difficult to check).

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------
Newsgroups: comp.std.c++,comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: Question about sizeof in C/C++.
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Fri, 18 Dec 1992 02:16:10 GMT

In article <wwJXVB3w164w@amfent.Gwinnett.COM> amf@amfent.Gwinnett.COM (Andy Feibus) writes:
>jamesc@swapsdev.state.state.COM.AU (James Cribb) writes:
>> Given
>>     struct Something*  ps;
>>     unsigned  k;
>> do the C or C++ standards guarantee that
>>     &ps[k] == ((char*) ps) + k * sizeof(struct Something)
>Assuming that you [cm]alloc enough memory for ps to support accessing the
>k'th element of it, the answer is... no.

He was asking about the standards, for which (under the condition you state)
the answer is... yes.

>Different compilers see &ps[k] differently; use parentheses to clarify:
> &(ps[k]).

Even K&R-1 and Stroustrop-1 prohibited seeing this expression differently.
Parenthesization is nice for human readers so that we don't have to look it
up all the time, but not necessary for C or C++ compilers.
--
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: jimad@microsoft.com (Jim Adcock)
Subject: Re: Pointer comparisons and templates
Date: 15 Dec 92 20:01:12 GMT
Organization: Microsoft Corporation

In article <1992Dec14.075853.3399@lth.se> dag@bellman.control.lth.se (Dag Bruck) writes:
|		if (element < root->element)
|			return InsertElement(root->left, element);
|		if (root->element < element)
|			return InsertElement(root->right, element);
|		return root->element;
|	}
|
|Note that a copy of the element argument is inserted into the tree,
|and that InsertElement() always returns a reference to this copy.
|
|Now, here's the problem: this implementation works fine for all
|element types that have an "operator < ()" including plain built-in
|types and many user-defined types.  However, it is not guaranteed to
|work with pointer elements for reasons we have discussed before.

I disagree.  Consider an implementation that fully implements a "strict"
interpretation of IEEE doubles.  Such an implementation fails to "work"
for exactly the same reason as the pointer implementations in question.
Namely your implementation assumes "<" always returns an ordering, 
but neither IEEE doubles, PC pointers, nor user implemented classes
may interpret "<" in such a manner.  In the case of PC pointers all
pointers must be to the same array for your code to work.  In the
case of a strict implementation of IEEE numbers there better not be
any NANs presented to this code.  In the case of user implemented
classes, god only knows what "<" might mean -- I/O an element up
the wazoo, for all we know!

This is not an issue of "<" at all, rather it is an issue of templates.
Templates in C++ are the equivalent to "accidental reuse" in Smalltalk.
If the syntax fits, you've got a template class, no matter that the
semantics don't work.  No matter how slow you make pointers, you still
are left with this template "accidental reuse" problem.

======

"Trust the programmer."

"Make it fast, even if it is not guaranteed to be portable."

-- The ANSI-C Rationale
From: ahumphr@micrognosis.co.uk (Aidan Humphreys)
Newsgroups: comp.std.c++
Subject: Exception Handling
Keywords: Exceptions
Date: 17 Dec 92 13:53:00 GMT
Organization: Micrognosis, London, UK.


Can anyone provide some pointers to information re: exeption handling in 
C++. My specific interest is real time software portable between UNIX and
VMS platforms. Which currently available compilers support it? How
does one integrate application exceptions with system signals? Are 
current implementations trustworthy and stable?
From: mr@delfin.com (Mark Rosenberg)
Subject: Name-scope semantic differences between 2.1 and 3.0
Reply-To: mark@delfin.com
Organization: Delfin Systems, Sunnyvale CA
Date: Fri, 11 Dec 1992 18:17:44 GMT

How are CFRONT 2.1 name-scoping semantics different from CFRONT 3.0
name-scoping semantics? We are developing a product that needs to be
supported on several different platforms (currently RS-6000 and Sparc).
This product relies upon Objectstore. According to their support
people, their compiler has templates but 2.1 name-scope semantics.

Apparently 2.1 name-scope semantics are not a subset of 3.0 name-scope
semantics. What are the implications of these semantic differences?
What should one do or not do to maximize compatibility?


-- 
Mark Rosenberg
internet:mark@delfin.com
phone: (408) 562-1126	fax: (408) 748-1140
snail: Delfin Systems, 3000 Patrick Henry Drive, Santa Clara, CA 95054-1814
Newsgroups: comp.std.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Nested functions and trampolines
Organization: Computer Science, University of Melbourne, Australia
Date: Sat, 12 Dec 1992 18:12:29 GMT

ark@alice.att.com (Andrew Koenig) writes:

>jimad@microsoft.com (Jim Adcock) writes:
>
>> So that taking the address of a nested function in different scopes
>> causes differing trampolines to be created, and differing pointers returned?

Yes.

>It shouldn't need to do that.  At most one trampoline is ever necessary
>for a given nested function during its lifetime, namely the one that
>binds the lexically surrounding context that was current when the
>block containing the definition of that function was entered.

But that block may be entered multiple times, recursively, in which case
you need more than one trampoline for a single nested function.

(Jim's article still hasn't arrived here yet, so perhaps I am missing some
important context?)

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: dag@bellman.control.lth.se (Dag Bruck)
Newsgroups: comp.std.c++
Subject: Re: Zero-length structures and pointer comparisons
Date: 20 Dec 92 20:12:12 GMT
Organization: Department of Automatic Control, Lund, Sweden

In <comp.std.c++> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>>>
>>>In fact, p==q iff objects equal is unimplementable on some machines.
>>>That is, even the existing ARM requirement is unworkable.
>
>Perhaps we can conceive two types of pointers, type 1 
>provides no comparisons at all, type 2 allows equality test.

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.

Let me try to put it differently: the element type is "pointer to X",
not "X" itself.

C and C++ has some notion of equality between pointers.  You can
clobber the semantics of this equality with memory mapping and what
not, but that is in my view an issue beyond the language.

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:

	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?

		-- Dag

		
Newsgroups: comp.std.c++
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: Sat, 19 Dec 1992 20:20:43 GMT

In article <1992Dec18.204337.3084@lth.se> dag@bellman.control.lth.se (Dag Bruck) writes:
>In <comp.std.c++> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>>
>>In fact, p==q iff objects equal is unimplementable on some machines.
>>That is, even the existing ARM requirement is unworkable.
>
>No, some machines are unworkable :-).

I wont disagree with your sentiments.

However, lets consider that Unix file names are 'pointers' to files,
and that links are allowed.

Then the average program cant tell if two file names point to
the same file or not, since computing the inode number is the only
way to do that, and only super users can do this calculation.
(Imagine I'm right even if this isnt the case. Is it the case?)

Would this make such a system 'unworkable'?

The issue is whether pointers must provide any more functionality
than the ability to access an object, that is, whether object
identity can be established by pointer comparisons.
(A related issue is whether two pointers point INTO the same object,
or one points into an object the other points to)

I suggest that whole classes of software can be written that 
do not rely on the ability to test if two pointers refer
to the same object or not, other types of software require
this information.

Perhaps we can conceive two types of pointers, type 1 
provides no comparisons at all, type 2 allows equality test.

Most of the code I've written uses type 1, and most uses
of type 2 could be rewritten as type 1.

In those cases where type 2 pointers are desirable, it
seems reasonable to restrict them to pointers
to objects created directly by me, and not the operating
system.

Thus I would like to see the ARM == rewritten so the
results of == on externally derived or otherwise mangled
pointers are implementation defined.

Thus, if you write non-strictly conforming programs for
a linear address machine, I have no complaint 
when your hacks dont work on my segmented machine because
you are using 'implementation defined' features of C++.

-- 
;----------------------------------------------------------------------
        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: jimad@microsoft.com (Jim Adcock)
Subject: Re: Zero-length structures and pointer comparisons
Date: 16 Dec 92 20:10:44 GMT
Organization: Microsoft Corporation

In article <1992Dec15.162202.11231@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|But Jim, it is not implementation defined, it is required that 
|pointers to the same object compare equal. It is therefore
|legal to have a function:
|
|	f(X* a, X*b) {
|	if(a==b) { /* special case, copy b object */ ... }
|	else *a+=*b;
|	}
|
|where the += operation is destructive and wont work if a and b point
|to the same object. The above code is guarranteed in C++, but
|will fail on a suitably organised system. It is therefore not
|allowed to do this sort of memory mapping in C++ behind the scenes,
|which is what I'm concerned with...we actually want to.

If a strictly conforming implementation is presented with a strictly
conforming program, then the above works subject to some additional 
constraints, such as a and b refering to disjoint objects.

However, if a strictly conforming implementation is presented with a 
non-strictly conforming program, such as a program that calls OS
virtual memory mapping adjustment routines, or programs that send
pointers off the ends of arrays, or programs who don't properly point
at objects that correspond to the types of objects they pretend to point
at .... in all such cases all bets are off.  

Newsgroups: comp.std.c++
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.std.c++
Subject: Re: Must derived class reserve space for an empty base class?
Date: 12 Dec 92 17:23:39 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: TIN [version 1.1 + PL8]

Jim Adcock (jimad@microsoft.com) wrote:
: jbn@lulea.trab.se (Johan Bengtsson) writes:
: |Jim Adcock (jimad@microsoft.com) wrote:
: |: steve@taumet.com (Steve Clamage) writes:
: |: |jimad@microsoft.com (Jim Adcock) writes:
: |: ||In "C" common implementation would make &g and &g.e identical,
: |: ||contradicting your assumptions.
: |: |
: |: |I don't this can happen in C, since you can't define a zero-sized object
: |: |or type.
[...]
: |: |On that basis, C compatibility would not seem to be an issue.
: |
: |: But the struct need not be empty for &g and &g.e to be identical.
: |
: |But it must, at least to produce two pointers of the same type that
: |compare equal.  Also, "g" and "g.e" must share a common superclass
: |for this to happen (within the type system).

: Below find legal C and C++ programs with non-empty structs where "g" and
: "g.e" compare equal.

Jim, we have obviously not been clear enough (me and Steve).  Yes,
the address of an object and its first member _cast to void*_ may
compare equal, so code handling void pointers must not assume
this kind of pointer distinctness.  However, neither "&g" nor "&g.e"
is of type void*.

[ Questionable C example involving compiler-generated conversion
  to void* deleted ]

The fact that applying the adress operator (&) to a reference yields
a pointer to the referred-to object is irrelevant, since a reference
is just an alias for the referred-to object.  You cannot obtain
a pointer to a reference (as you already know).  This should not cause
any trouble.

[ C++ example involving a reference data member that refers to *this deleted ]

Perhaps with this clarification you can finally agree with us?

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------
Newsgroups: comp.std.c
From: gordon@delfin.com (Gordon Hua)
Subject: Re: (long) x and (long) floor(x)
Reply-To: gordon@delfin.com
Organization: Delfin Systems, Sunnyvale CA
Date: Wed, 16 Dec 1992 21:34:28 GMT

In article <1ghtanINNcf9@cs.tut.fi> pjh@cs.tut.fi (Haavisto Petri) writes:

>I don't have the standard, but it seems clear to me that given an
>expression of type double with a positive value, the following
>should always be true:
>
>		(long) (expression) == (long) floor(expression)

I also don't have the standard, but I have observed that the above will
fail for cases where the expression is negative.  Both (long) and (int) 
round toward zero, not negative infinity.  I wrote the following test
program and tried it on both a SUN SparkStation and an IBM RS/6000 and 
got the same results:

#include <math.h>
#include <stdio.h>

main(argc, argv)
int argc;
char **argv;
{
    double x;

    if (argc > 1) {
        x = atof(argv[1]);

        printf ("the number is %lf, (long) of it is %d, floor of it is %d\n", x, (long)x, (long) floor(x));
        if ((long) x == (long) floor (x))
            printf ("they are equal\n");
        else
            printf ("they are not equal\n");
    }
    else {
        printf ("usage:  %s n\nwhere n is a (double) number\n", argv[0]);
    }

    exit (0);
}

Gordon
Newsgroups: comp.std.c
From: eggert@twinsun.com (Paul Eggert)
Subject: Re: <iso646.h>
Keywords: Standard C international header implementation
Organization: Twin Sun, Inc
Date: Thu, 17 Dec 1992 14:21:43 GMT

Are the alternate spellings (`%:' for `#', `%:%:' for `##') active even
if <iso646.h> is not included?  If so, some strictly conforming ANSI C
programs will not conform to the proposed new standard.  As a trivial
example, the program

	#define x %:
	int main() { return 0; }

is strictly conforming ANSI C, but it would not conform to the proposed
new standard.  Surely it is important that existing conforming programs
not change in meaning because of the proposed revisions.
Newsgroups: comp.std.c
From: lipson@dms.agames.com (Pete Lipson)
Subject: Re: definition of strNcpy
Organization: Atari Games Corporation
X-Newsreader: TIN [version 1.1 PL6]
Date: Fri, 18 Dec 1992 18:03:58 GMT

Pete Lipson (lipson@dms.agames.com) wrote:
: i was just badly bitten by my interpretation of how strncpy works.
                            ... of course i meant strnCAT ^^^

:   The MAN page for it IMPLIES that it works this way; is the standard this
: ambiguous too?
: 
:   if you say:   strnCAT(dst,"abcdef",4)
: 
:  does the standard really say you get five characters appended to the
: dst (the chars 'a' 'b' 'c' 'd' AND the '\0') ???
:   the man-page says it moves AT MOST the count (4 in this case) characters
: but it ALSO says it returns a pointer to a NULL-TERMINATED result.
: 
:   I would have assumed in that case that you would have to move at most
: 3 non-null characters!
: -- 
:   /V\
: -/@-*\- Peter Lipson <-- lipson@agames.com   or   netcom!dms!lipson
:  \_o_/  Milpitas, CA <-- Atari Games
:    U
-- 
  /V\
-/@-*\- Peter Lipson <-- lipson@agames.com   or   netcom!dms!lipson
 \_o_/  Milpitas, CA <-- Atari Games
   U
Newsgroups: comp.std.c
From: diamond@jit533.jit.dec.com (Norman Diamond)
Subject: Re: ANSI-C document
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Mon, 14 Dec 1992 01:05:37 GMT

In article <1992Dec12.010456.2132@cdf.toronto.edu> a1001032@cdf.toronto.edu (Fiona Wong) writes:
>	Does anyone know any ansi-C document available via anonymous ftp?

There is none.  Part of the method by which standards organizations cover
their expenses is by SELLING hard copies of such documents.  (I vote again
to see the comp.lang.c faq cross-posted to comp.std.c ...)

Look up Canadian Standards Association in your phone book.  They're in
the northwest corner of Toronto or else Brampton.
--
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."
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.std.c
Subject: Re: Is INT_MAX<<1 defined?
Date: 13 Dec 92 00:29:50 GMT
Organization: CWI, Amsterdam

Norman Diamond discusses with volpe@ausable.crd.ge.com about mathematical
bits, implementation bits, operations on values and operations on
representations.

What it comes down to is that << is not a mathematical operation, there
is nothing in mathematics that tells us that 16384 << 1 equals 32768.
So what is the meaning of:
1.  Operation on value in this case?  Where in the standard does it tell
    us that for signed (16 bit) int 16384, 16384 << 1 is 32768?  Is an
    implementation not allowed to define it as -32768?  Or whatever?
    But in all there is no definition in *mathematics* for this operation.
2.  Mathematical bits?  What's that?  Where in mathematics are bits
    defined (except in coding theory, where they are used in a completely
    different context where shifts are unheard of)?
The bottom-line is that shifting is not a mathematical concept, shifting
is a "computer science" concept.  So it makes no sense to talk about
mathematical operation on values or about mathematical bits.  When you
have shifted something the concept of a *value* is lost (except perhaps
in a computer science sense, which is not my field) and you need other
means to determine whether or not trapping is allowed.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
From: lipson@dms.agames.com (Pete Lipson)
Newsgroups: comp.std.c
Subject: definition of strNcpy
Date: 18 Dec 92 01:52:28 GMT
Organization: Atari Games Corporation
X-Newsreader: TIN [version 1.1 PL6]

i was just badly bitten by my interpretation of how strncpy works.
  The MAN page for it IMPLIES that it works this way; is the standard this
ambiguous too?

  if you say:   strncpy(dst,"abcdef",4)

 does the standard really say you get five characters appended to the
dst (the chars 'a' 'b' 'c' 'd' AND the '\0') ???
  the man-page says it moves AT MOST the count (4 in this case) characters
but it ALSO says it returns a pointer to a NULL-TERMINATED result.

  I would have assumed in that case that you would have to move at most
3 non-null characters!
-- 
  /V\
-/@-*\- Peter Lipson <-- lipson@agames.com   or   netcom!dms!lipson
 \_o_/  Milpitas, CA <-- Atari Games
   U