HDTenEightyP/NetNews huggingface dataset:
From: tal@Warren.MENTORG.COM (Tom Limoncelli)
Newsgroups: comp.std.internat,news.admin.misc,comp.protocols.iso.x400
Subject: Re: X.400 as SMTP replacement (Re: 8-bit news)
Date: 11 Dec 1992 16:15:02 -0500
Organization: Mentor Graphics -- IC Group
Distribution: inet
NNTP-Posting-Host: milk.warren.mentorg.com
Keywords: ISO8859 ISO10646 8bit SMTP X.400 Internet

In <1ga650EINNl1b@uni-erlangen.de> unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn) writes:

>group MHS-DS based on the X.500 directory. It will be implemented in the
>next ISODE/PP releases and other systems and might even be a candidate for
>an ISO standard. X.400 isn't a finished complete standard at the moment.
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

It isn't finished????  How DARE you say that!  Just ask *ANY* *MARKETING*
*PERSON* (especially those here on the net) if the X.400 spec is
finished and they'll tell you that it isn't only finished, it's stable,
in production, and a large improvement over sliced bread.   (ha ha,
only serious)

How long has it been since they started?  How long is it taking to
finish the spec?  I think ISO should develop a standing rule to
automatically reject any draft after its 8th year of writing.  A new
committee will be formed to create the spec but it can not include
anyone that has read the previous spec.  (ha ha, only serious)

How long as X.400 been "the protocol to replace SMTP"?  5 years?  8?

Tom

ObX.400Joke:  How do two X.400 users communicate?  (answer: by telephone)

-- 
Tom Limoncelli -- tal@warren.mentorg.com (work) -- tal@plts.uucp (play)
Reality is stranger than fiction #943247:  The IRS granted
ANS approval as a 501c3 "charity" on September 14, 1992.
From: plate@ruc.dk (John Plate)
Newsgroups: comp.std.internat
Subject: Re: Week Numbering
Date: 20 Dec 92 19:32:34 GMT
Organization: Datalogi, Roskilde Universitetscenter

In Europe (?) the first week of a year is the week that has more than 
3 days in it. Weeks goes from monday to sunday.

If a year starts with a week with less than 4 days, it is week 53 of
the previous year.

-- 

:::::::::::::: John Plate, Roskilde University, Denmark :::::::::::::::
:::::::::::::::::::: Internet: <plate@dat.ruc.dk> :::::::::::::::::::::
:::::::::: Fax: (+45) 31 16 16 07 - Phone: (+45) 31 16 80 80 ::::::::::
Newsgroups: comp.std.internat
From: Quinn <quinn@cs.uwa.edu.au>
Subject: Re: ANSI/MIL-STD-1815A (Ref Manual for Ada PL)
X-Xxdate: Thu, 17 Dec 92 02: 18:21 GMT
Organization: The University of Western Australia
X-Useragent: Nuntius v1.1.1d13
Date: Thu, 17 Dec 1992 02:21:50 GMT

Ed Dorsey, dorsey@gofish.NoSubdomain.NoDomain asks:
>Does anyone know where I can get a copy of ANSI/MIL-STD-1815A, a.k.a.
>Reference Manual for the Ada Programming Language?  Hard-copy,
soft-copy...
>any kind of copy (tho' an ftp site is preferred).  

Host: ajpo.sei.cmu.edu (128.237.2.253)
User: anonymous
Pass: your email address
File: /public/lrm/lrm.tar.Z

Share and Enjoy.

Quinn "The Eskimo!"      <quinn@cs.uwa.edu.au>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia
  -- LRM = Language Reference Manual
Xref: sparky comp.std.internat:900 news.admin.misc:835
From: rap@news (Ross Paterson)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 8-bit representation, plus an X problem
Date: 18 Dec 1992 11:00:20 GMT
Organization: Dept. of Computing, Imperial College, University of London, UK.
Reply-To: rap@doc.ic.ac.uk
NNTP-Posting-Host: peaberry.doc.ic.ac.uk

From article <24433@alice.att.com>, by andrew@alice.att.com (Andrew Hume):
|	UTF-1 does #00-#9f in one byte, #a0-#4015 in two bytes, and
| #4106-#ffff in three bytes. FSS-UTF does #00-#7f in one byte, #80-#7ff
| in two bytes and #800-#ffff in three bytes. [...]
|
|	certainly, the characters between #800 and #4015 will take
| 50% more space in FSS-UTF than UTF-1. from our file command (which
| guesses at languages), this would seem to include Devanagari, Bengali,
| Gurmukhi, Gujarati, Oriya, Tamil, Telugu, Kannada, Malayalam, Thai, Lao,
| Tibetan, Georgian, Japanese (hiragana etc), chinese (some) and korean.
| (with the exceptions of the CJK scripts and perhaps georgian, there
| is no measureable email traffic in these scripts.)

Yes, UTF-1 gets the ALPHABET and SYMBOL zones, and the important part of
the CJK AUXILIARY zone, in 2 bytes.  FSS-UTF goes up to 3 bytes just before
it gets to the alphabets of Asia beyond the Middle East.  For this you get
synchronization, but is it worth it?

|	and even for these scripts, i would guess connectivity (in the
| sense of being able to send/receive messages at all) matters more
| to those folks than the increase in space (how much of your disk is
| mail?) or decrease in bandwidth (in most messages i see, headers are
| 30-50% of the message).

They can get their connectivity by specifying an existing 7-bit standard
in a MIME header.

How much of a Plan 9 disk is text?
Newsgroups: comp.std.internat,news.admin.misc
From: davecb@nexus.yorku.ca (David Collier-Brown)
Subject: Re: 8-bit news
Organization: York University
Date: Fri, 18 Dec 1992 13:31:07 GMT



In article <CKD.92Dec15215407@loiosh.eff.org> ckd@eff.org (Christopher Davis) writes:
|>And it breaks old code.  And it only works with cooperating sites, but has
|>no way to tell whether the site it's talking to is cooperating or not.  And
|>it can silently lose information by talking to an uncooperative (but
|>standards-conforming) site that clips bits.

   Actually it breaks some old code that misparses headers.  Sendmail
on Suns (since 3.4) and DECs (all) strip the high bits befor parsing.
I suspect the number of broken sednmails is diminishingly small!

avg@rodan.UU.NET (Vadim Antonov) writes:
|As for receiving 8-bit information with MSB trimmed off - it still
|will be readable. FYI (if you didn't know that before) the old ISO
|standard 8-bit codes were designed to have exactly this property.

  I read significant parts of the 8-bit newsgroups bet stripping bits, why
not mail?
  What I **don't** have is 16-bit mail.  That takes mime.

--dave (off to make sure ssmtp/rsmtp are 8-bit-clean) c-b
-- 
David Collier-Brown,  | davecb@CCS.YorkU.CA | lethe!dave
72 Abitibi Ave.,      | 
Willowdale, Ontario,  | York Postmaster and
CANADA. 416-223-8968  | occasional sendfail(8) consultant.
Xref: sparky comp.std.internat:875 news.admin.misc:792
From: chrisg@coop.com (Chris Garrigues)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 8-bit news
Keywords: ISO8859 ISO10646 8bit
Date: 16 Dec 92 17:04:07 GMT
Organization: Cooperative Computing, Inc.

In article <BzBJIA.3AM@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
>  The systems are mostly orphans.  In some cases, the vendor doesn't
>even exist anymore.  The software effectively cannot be changed.  Such
>systems are a large part of the reason that the DDN has had an awful
>time trying to convert to the Domain Name System.  Heck some of the
>older systems from still existing vendors used 6-bit characters rather
>than 7-bit ASCII.  Ever programmed on a Cyber ?  Mayhaps not.  However
>many such systems won't go away or be replaced soon for financial and
>other reasons.

Is it or is it not a fair assumption that such systems will be leaf
nodes?  I think it's a useful distinction to consider this question
because it isn't really important for these purposes if leaf nodes
aren't up to snuff as long as nodes that the data may be routed
through between two State Of The Art (tm) are capable of transferring
the data cleanly.  

(BTW, I have programmed on a Cyber.  I ^L^O^V^E 6/12 ^S^P^L^I^T-ASCII.
Xref: sparky comp.std.internat:885 news.admin.misc:809
From: andrew@alice.att.com (Andrew Hume)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 8-bit news
Summary: not really
Date: 17 Dec 92 05:08:44 GMT
Article-I.D.: alice.24425
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <1glkdeINNqfr@tik.vtt.fi>, Markku.Savela@tel.vtt.fi (Markku Savela) writes:
> In article <89RsVB3w165w@blues.kk.sub.org> kosta@blues.kk.sub.org (Kosta Kostis) writes:
> 
> Actually we already have one ultimate character encoding system, sort
> of. And that is ISO 2022 + registered character sets. Implementing
> that is about the same complexity as ISO 10646, it's just different
> encoding for the same information.


	even with a half-smiley, this is just plain bonkers. and
juts plain untrue. i have seen a draft of a standard where a character
set was defined by a table of 10646 values -- no one has or will
apply for a character set escape sequence name.

	the bottom line is that 2022 was a barely manageable system
that was so baroque that no one implemented save those who had to
(mainly europeans). in the context of 7-bit transmission, it was
a plausible technique. nowadays, it is simply bogus. let it die a
natural death.
Newsgroups: comp.std.internat
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: ISO Latin 1 text presentation with 7-bit ASCII
Organization: University of Jyvaskyla, Finland
Date: Sun, 13 Dec 1992 18:23:16 GMT

In article <TML.92Dec8144926@tiuhti.tik.vtt.fi> tml@tik.vtt.fi (Tor Lillqvist) writes:
>   ...
>   >>       Similarly, o-diaeresis can be rendered as "oe" in German 
>   >>       or Swedish but not in English ("co<o-diaeresis>peration").
>   ...
>No, definitely not. If a swedish-speaking person in general (ie, not
>one accustomed to the German way of using "oe") would face the task of
>writing a word containing odiaeresis on a keyboard without it, she
>would probably use "o", and then only because of the similar look of
>the glyph.  The pronunciation is quite different, of course, and
>odiaeresis is in no way mentally pictured as an "o" with dots any more
>than "E" is thought to be a "F" with a lower bar...

It's even worse for Finnish, because 'ae', 'oe', and 'ue' are very
common vowel combinations.  So, even if a Finnish-speaking person
were familiar with the German custom, it would be extremely tedious
always to disambiguate between the two alternatives.

BTW, a wonderful case of double transcription was seen at the
Barcelona Olympics:  There was an ethnic Finn from Russia (Carelia)
whose surname was Ha"ma"la"inen (yet another way to show umlauts).
The name was shown as Khiamialiainen, because:
- Finnish 'h' is transcribed to the Russian letter which denotes
  a stronger 'h' and is transcribed back to 'kh' in many European
  languages ('ch' in German).
- Finnish a-umlaut is transcribed to the Russian 'ja' (or 'ya'
  for the English and French), because that gives the nearest
  equivalent vowel.

Similarly, the surname of the famous Estonian computer scientist
Enn Tyugu is actually To~ugu (o with tilde):  the Russian letter
whose pronunciation is closest to this special Estonian vowel
is usually transcribed as 'y' in the Latin alphabet.

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------
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:32:42 GMT

In article <KANZE.92Dec10165804@slsvdnt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
>|> alternative is of course to dismiss the idea as not worth the trouble.
>
>I favor the latter case.  

	I think that MANY collections will be collections of pointers.
MANY of these types of collections will rely on there existing some
total ordering. SOME of these will also require some that

	p==q <==> ptrcmpeq(p,q)==0

where I used ptrcmpeq to denote the version of ptrcmp that supports
the above identity, whereas plain ptrcmp need not, and might
always return 0.

(A third version, ptrcmppo might also preserve partial ordering of <.)

Therefore I think it is worth persuing the issue,
especially as the 'ptrcmp' idea is an extension to the library,
and thus might be acceptable to the committee, whereas changing
the status of < might not.

	In fact I believe the status of == must be downgraded,
even at the expense of C compataibility, and that will be a tough
enough battle as it is.

-- 
;----------------------------------------------------------------------
        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: sjm@bcrki65.bnr.ca (Stuart MacMartin)
Subject: Re: Zero-length structures and pointer comparisons
Organization: Bell-Northern Research Ltd., Ottawa, Canada
Date: Wed, 16 Dec 1992 20:27:11 GMT

In article <BzCG7K.2sG@frumious.uucp> pat@frumious.uucp (Patrick Smith) writes:
>
>jss@lucid.com (Jerry Schwarz) writes:
>|And
>|
>|       if p < q is defined,  ptrcmp(p,q) < 0   <=>  p < q
>
>
>This strikes me as nice to have, but not essential.
>
>On the other hand, this might be fairly cheap, given that
>we're already insisting on
>
>   p == q   =>   ptrcmp(p,q) == 0
>

It makes me nervous to disagree with you, but haven't we already 
hammered to death the concept that p < q might be defined (but 
not generate a total ordering) if some ps and qs are not in the
same segment?  Or do the PC compilers only permit p < q for ps
and qs in the same array?

Suppose we have a compiler that uses segment offset to determine
if p < q but memory address to determine if p == q.

If p1 < q1 are near the end of segment 1,
   p2 < q2 are near the beginning of segment 2
and q1 == p2 (because they refer to the same memory location),

then
   
   p2 < q2 < p1 < q1   (because the segment is being ignored)
but
   p2 == q1   and   p2 != q2.

Stuart
--
: Stuart MacMartin                                    email: sjm@bnr.ca      :
: Bell-Northern Research                              phone: (613) 763-5625  :
: PO Box 3511, Stn C, Ottawa, K1Y-4H7, CANADA    Standard disclaimers apply. :
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.std.c++
Subject: Re: Pointer comparisons and templates
Date: 16 Dec 92 16:35:41 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: TIN [version 1.1 + PL8]

Dag Bruck (dag@bellman.control.lth.se) wrote:
: In <comp.std.c++> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
: >	You could always write the progam in terms of cmp(T,T),
: >not <. The it would work for pointers too, you would just
: >have to define cmp(T,T) for each type, including pointers,

: I think that would be a serious effort, considering how many different
: types of pointers you have in an application.

: >	template<class T> int cmp(T a1, T a2){return a1<a2;}
: >	int cmp(void* a1, void* a2){return ptrcmp(a1,a2)<0;}

: I don't think this one flies.  For example,

I suggested a similar template in a previous response.  Jerry Schwarz
pointed out in private mail that it doesn't work.  Only _exact_ type
matches on functions are preferred over function templates, so all
pointers except void* would end up calling the template.

: 	int* p;
: 	int* q;
: 	cmp(p, q);

: probably causes a template overloading ambiguity.

Well, no.  Since there is no trivial conversion from int* to void*,
the template is preferred.  The _standard_ conversion int* --> void*
is not considered.

: You have to
: explicitly define a cmp() for every type of pointer you have, I think.

So it seems.  And in practice it would be too error-prone to do that.

Jerry also said (I hope he doesn't mind me posting it):
> 
> You could write
> 
> 	template<class T> inline int isless(T* a, T* b) {
>  	    return ptrcmp(a,b) ;
>         }
> 
> but then you have duplicate definitions of isless(int*,int*),
> which isn't allowed.

So this is a general limitation for C++ templates then:
Using templates you can handle one unbounded set of types, but never
two unbounded sets, at least not with the same template name.

Dag's orignal claim that it is impossible to create templates
that use "<" for all objects and ptrcmp() for all pointers seems
to be valid.

Using a bit of trickery, it is possible to create a template that
works for pointers (ptrcmp) and objects (<), _except_ for classes
that define automatic conversion to pointers (Dag found that one).
I tested this, but won't describe the details here.  Mail me if
you are interested.

: >	The real problem cannot be solved at all, namely, for
: >a user define < or cmp, ensuring it is a total order.

This is a good point (IMHO).

-- 
--------------------------------------------------------------------------
| 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: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Nested functions (was: Re: Zero-length structures and pointer comparisons)
Organization: Computer Science, University of Melbourne, Australia
Date: Tue, 15 Dec 1992 08:05:24 GMT

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

>maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
>> Do you personally favour nested functions?
>
>In general, yes.  For C++, I'm not sure.
>
>> If not, why not?
>
>The main argument against it is that C doesn't have them, which means
>that having them in C++ would make C interoperability more difficult.
>It would also be more difficult to interface C++ programs with
>low-level assembly-language things like on-board controllers.  I don't
>care about that personally, but I know that other people do.

I don't see why this is a good counter-argument. After all, C doesn't
have classes, constructors, exceptions, templates, etc., etc., but
we still manage. Why are nested functions so hard? I think that 
Gnu C's implementation of nested functions shows that it does not
cause any particularly difficult implementation problems.

-- 
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: daniel@cse.ucsc.edu (Daniel R. Edelson)
Newsgroups: comp.std.c++
Subject: Re: Zero-length structures and pointer comparisons
Date: 18 Dec 92 20:17:52 GMT
Organization: University of California, Santa Cruz (CE/CIS Boards)
NNTP-Posting-Host: oak.ucsc.edu

In article <1992Dec18.193554.18588@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>In article <1992Dec16.201044.2968@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:

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

I think this is a requirement on implementations, rather than
a requirement on programs. 

>	Or have I got this wrong?

You might have it backwards.

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

Neither the C standard nor the C++ standard discusses any OS.
(As far as I recall.)

A call to the operating system should be viewed as
a call to an extension supplied by the language provider. 
A program that uses an extension can be conforming but
not strictly conforming, as per the X3J16 definitions. 

Thus, I think a better rule is:
	``In a strictly conforming program, two pointers
	to the same object compare equal.''
Thus, this property need not be true in any program that
calls the operating system.

I think actually that ramifications of multiple inheritance 
and multiple object-addresses should be explicitly addressed
in the rule, such as by saying that a pointer to a base-class
subobject is not a pointer to the same object as a pointer
to the most-derived class object.

>        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au

Daniel Edelson
daniel@cse.ucsc.edu
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.std.c++
Subject: Re: Zero-length structures and pointer comparisons
Date: 12 Dec 92 19:56:40 GMT
Article-I.D.: alice.24398
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <1992Dec12.162211.5076@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

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

> 	Are you saying that if I have a recursive function with a nested
> function in it, and store the address of the nested function in scope
> at the time of entering the n'th recursion into an array in slot n,
> then executing the j'th slot will access the n'th activation record
> and not the j'th one? (I.e. all the functions in the array
> access the most recent activation record?)

No, that's just the opposite of that I said.

I said `the context that WAS current.'

Perhaps an example will make it clearer:

	void (*p)(void);
	void f(int n)
	{
		void g() { printf("%d\n", n); }
		if (n == 3)
			p = &g;
		if (n == 5)
			(*p)();
		else f(n+1);
	}

I am claiming that calling f(0) should print 3, not 5, because the
address stored in p should correspond to the stack frame in which
n is 3.  Indeed, that is just what gcc does.  It is also what every
other language I know does that supports such functions at all.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.std.c++
From: robertd@kauri.vuw.ac.nz (Robert Davies)
Subject: Borland, Microsoft and operator=()
Organization: Victoria University of Wellington
Date: Wed, 16 Dec 1992 11:18:10 GMT

/*
The following program displays "Borland" when run under Borland C++
and "Microsoft" when run under Microsoft C++. The reason is that
Borland uses the user defined version of operator= whereas Microsoft
uses the default =. I presume the AT&T compiler and G++ will follow
Borland.

I can't find a revelant statement in the ARM or C++ reference manual.
So who is right, or is this a matter for the standards committee?

(Apologies if this has already been discussed to death)

Robert
*/



#include <iostream.h>

char* borland = "Borland";
char* microsoft = "Microsoft";

class Base
{
public:
   char* c;
   Base() { c = microsoft; }
};

class Derived : public Base
{
public:
   void operator=(const Base&) { c = borland; }
   Derived() {}
};

main()
{
   Derived d,e;
   e = d;                          // Borland uses operator= whereas
                                   // Microsoft uses the default =
   cout << e.c;
   return 0;
}

Newsgroups: comp.std.c++