HDTenEightyP/NetNews huggingface dataset:
From: msb@sq.sq.com (Mark Brader)
Subject: Re: Struct hack one last time (one last time)
Organization: SoftQuad Inc., Toronto, Canada
Date: Mon, 4 Jan 93 05:45:02 GMT

[See the earlier articles for the various declarations and definitions.]

> > 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];
>   }
> 
> ... Thus, the legitimacy of the struct hack [for non-chars] is restored.

I take my rhetorical hat off to the ingenuity of this suggestion, but
I don't believe it forms a valid argument.  In order to invoke 3.3.6/6.3.6
on the array member v of the type struct vec2, I believe it would be
necessary to actually use a pointer of type struct vec2 *.  In other
words, the array reference vec->v[1] would have to be changed to
((struct vec2 *) vec)->v[1].  And of course this destroys the usefulness
of the hack, since the real point is that you want to refer to v[j] for
a value of j that isn't known in advance.

In addition, I don't think that anything constrains the types double[1]
and double[2] to have the same alignment requirements as each other,
and so, offsetof(struct vec, v) and offsetof(struct vec2, v) need not
be the same.

In addition, note that "array of n doubles" is a different type from
double, and may the implementation may impose alignment requirements on
it for some reason, and that requirements may be different for different
values of n since those create different types also.  The upshot is that
offsetof(struct vec, v) and offsetof(struct vec2, v) may be different,
and so the argument fails on these grounds as well.

(I can't think of a practical reason why an implementation *would* impose
alignment requirements on "array of n doubles" stricter than those on
double, or requirements varying according to n, but the standard seems
to allow it.  Similarly, although I showed in my previous message why
I think the struct hack for non-char types is illegal, I can't think of
a reason why it would fail, other than on implementations with strict
array bounds checking.  This is, however, not the point.)
-- 
Mark Brader, SoftQuad Inc., Toronto	     "Don't get clever at 5PM Friday."
utzoo!sq!msb, msb@sq.com				    -- Tony Van Vleck

This article is in the public domain.
Newsgroups: comp.std.c,comp.std.internat,comp.lang.c
From: obaid@sdf.lonestar.org (Obaid Alvi)
Subject: Re: Need ANSI / POSIX spec for C
Keywords: ansi posix iso/iec9899 iso/iec9945
Organization: sdf public access Unix, Dallas -- 214-436-3281
Date: Thu, 7 Jan 1993 02:03:47 GMT


One source is: STANDARD C by Plauger & Brodi; Microsoft Press.
ISBN 1556151586.  Covers ANSI and ISO.

signed amjad;
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: Struct hack one last time (one last time)
Date: 10 Jan 93 17:09:32 EST

martin@mwtech.UUCP (Martin Weitzel) writes:
>Which directly brings up the question if (or if not) for
>any modifiable lvalue `x' and some `y' of the same type an
>assignment
>			x = y;
>may behave differently
>as a bitwise copy
>			memcpy(&x, &y, sizeof x);

>(For the pedantics: Assume the appropriate header is included
>and the two objects do not overlap.)

>To put it into the language of the standard: May some (otherwise
>strictly conforming) program change its behavior if the above
>two were switched.

This has a definite answer:  a conforming implementation may have
	x = y;
behave differently from
	memcpy(&x, &y, sizeof(x));

If x and y are structure types, it is already settled (via a Request For
Interpretation, I believe) that holes in a structure need not be copied
by assignment; this could be exposed in an otherwise conforming program
by
	memcmp(&x, &y, sizeof(x))

Another example (which is what I started with, until I remembered this
clear example) would be pointers; I believe that there is no requirement
that a pointer to an object have a unique representation, only that all
pointers to the same object shall *compare* equal.  In particular, segmentation
and alignment concerns could cause there to be a preferred representation
for a pointer (which could be enforced at assignment) but several possible
ways to represent the same pointer (which might get calculated differently
for different expressions, depending on the compiler's expedience).
From: barrett@daisy.ee.und.ac.za (Alan P Barrett)
Newsgroups: comp.std.c
Subject: Sequence space arithmetic
Date: 6 Jan 93 23:13:29 GMT
Article-I.D.: daisy.1ifb0pINN7qq
Organization: Dept. Elec. Eng., Univ. Natal, Durban, S. Africa
NNTP-Posting-Host: daisy.ee.und.ac.za

I would appreciate comments on the following macro, which is intended
to determine whether (a > b) in 32-bit sequence space arithmetic.
This might be used for comparing SOA serial numbers in a DNS nameserver,
as described in RFC 1034 and RFC 1035.

#include <limits.h>
/* how to check if (a >= b) in 32-bit sequence space arithmetic. */
#if (UINT_MAX == 0xffffffff)            /* int is exactly 32 bits */
#        define SEQ_GT(a,b) ((int)((unsigned int)(a)-(b)) > 0)
#else
#  if (ULONG_MAX == 0xffffffff)         /* long is exactly 32 bits */
#        define SEQ_GT(a,b) ((long)((unsigned long)(a)-(b)) > 0)
#  else
#    if (ULONG_MAX > 0xffffffff)        /* long is wider than 32 bits */
#      if 1 /* if you insist on evaluating a and b exactly once each */
#        define SEQ_GT(a,b) \
                ((((unsigned long)(a)-(b)) & 0xffffffff)-1 < 0x7fffffff)
#      else /* this is more intuitively obvious */
#        define SEQ_GT(a,b) \
                (((a)!=(b)) && ((((unsigned long)(a)-(b)) & 0x80000000) == 0))
#      endif
#    else                               /* long is narrower than 32 bits */
       #error "ULONG_MAX is less than 32 bits.  Get a real compiler."
#    endif
#  endif
#endif

Are both methods for handling longs wider than 32 bits guaranteed to work?
Will they also work with longs of exactly 32 bits? 
Which is likely to be handled better by existing compilers?

I believe that casting unsigned values into signed types is implementation
defined, and that this affects the parts that handle int or long of
exactly 32 bits.  Is that the case?

If we assume that the implementation does the obvious thing with
casts (just interprets the bits differently), will that code work?
How reasonable is it to make such an assumption, given that the code is
intended to run on a Unix system?

Would it be reasonable to omit all the #if tests, leaving just the part
that deals with longs wider than 32 bits, and trust the compiler to make
the relevant optimisations if a 32-bit type is available?

Would it be reasonable to omit all the #if tests, leaving just the part
that deals with longs of exactly 32 bits, and hope that the code never
runs on a system that has wider longs?

I realise that several of these questions are not directly related to
standards, but I would appreciate hearing opinions on them anyway.

Thanks,
--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: barrett@ee.und.ac.za                    Bang: m2xenix!undeed!barrett
Newsgroups: comp.std.c
From: rjf@lincroftnj.ncr.com (51351[efw]-Robert Feddeler(MT4799)T343)
Subject: Re: understanding FLT_DIG
Organization: AT&T/NCR, Lincroft, NJ, USA
Distribution: na
Date: Thu, 7 Jan 1993 21:51:14 GMT

In article <steve.726275211@unidata.ucar.edu> steve@unidata.ucar.edu (Steve Emmerson) writes:
>Hi,
>
>I'm having trouble understanding FLT_DIG, which is defined in <float.h>,
>According to section 2.2.4.2.2 of the ANSI standard, FLT_DIG is given by
>the following on base-2 machines:
>
>	FLT_DIG = (int)((p-1)*log10(2))
>
>where `p' is the precision (the number of base-2 digits in the
>significand).
>
>On a hypothetical base-2 machine with 4 bits of precision, the above yields
>0 for FLT_DIG.  Yet, those 4 bits can represent the integral values 1
>through 9 exactly.  Thus, shouldn't FLT_DIG be 1?
>

Note the 'p-1'.  The '-1' leaves room for a sign bit.
You're left with only 3 bits or 0-7.


bob.				| Heap bit trouble in the land of plenty.
Were these more than just my opinions, they would have cost a bit more.
Newsgroups: comp.std.c
From: blume@kastle.Princeton.EDU (Matthias Blume)
Subject: Re: Struct hack one last time (one last time)
Reply-To: blume@kastle.Princeton.EDU (Matthias Blume)
Organization: Dept. of Computer Science, Princeton University
Date: Thu, 7 Jan 1993 21:09:24 GMT

In article <1993Jan7.200813.10289@leland.Stanford.EDU>,
dkeisen@leland.Stanford.EDU (Dave Eisen) writes:
|> In article <1993Jan7.145117.8220@jarvis.csri.toronto.edu>
flaps@dgp.toronto.edu (Alan J Rosenthal) writes:
|> >steve@taumet.com (Steve Clamage) writes:
|> >>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.
|> >
|> >Can't do that... what happens when you malloc one of them?
|> >
|> >	struct whatever *p = (struct whatever *)malloc(sizeof(struct whatever));
|> >
|> >Immediately after the malloc, if p is not null you can start using
the struct,
|> >but it won't have that run-time-error-checking information, so it
will fault.
|> 
|> I don't know whether or not implementations are allowed to
|> do what Steve is suggesting here, but I don't think this
|> is a reason why it couldn't. Couldn't the compiler, as part
|> of the code it emits to convert the (void *) returned by
|> malloc also emit instructions to set up the information that
|> Steve is postulating here? Or is there language in the the
|> standard that forbids a conversion from one pointer type to
|> another to affect the block of memory to which this pointer 
|> points?

How should the poor compiler know WHERE to insert that information.  For malloc
there might be special handling in the compiler, but consider a library
memory-allocation routine of my own that returns void * and which does not
impose a simple relationship between arguments and the size of the
chunk of memory allocated!

-Matthias
Newsgroups: comp.std.c
From: ttobler@unislc.uucp (Trent Tobler)
Subject: Re: Struct hack one last time (one last time)
X-Newsreader: Tin 1.1 PL5
Organization: Unisys Corporation SLC
Date: Fri, 8 Jan 1993 22:04:22 GMT

Steve Clamage (steve@taumet.com) wrote:
: msb@sq.sq.com (Mark Brader) writes:
: 
: >In particular, it could not modify padding at the end of a struct,
: >precisely *because* it would break the struct hack.
: 
: We seem to have some circular reasoning here.
: 
: I proposed an implemention which I claimed was conforming on which
: the struct hack would not work; therefore the struct hack is illegal.

 ...

: For example, if the struct hack is strictly conforming, what about this:
: 
: 	struct S {
: 	    double a[2];
: 	    double b;
: 	} s;
: 	s.a[2] = 1.0;
: 
: The array reference exceeds the declared bounds of s.a, but not the
: bounds of object s, because sizeof(s) can't be smaller than
: sizeof(a)+sizeof(b).  If a compiler can't add padding to the end of
: the struct for other than alignment, then surely it can't add padding
: between a and b, because it can't be required for alignment.  Therefore
: s.a[2] must be the same as s.b.

First off, the compiler is free to add padding for whatever reasons it
wants.. but it must not depend on the value of this padding information.
Second, in your example, a[2] would be equal to 1.0.  It says nothing 
about the value of b.  Because the contents of b may or may not be changed,
it's value is not definite.

--
  Trent Tobler
Newsgroups: comp.emacs
From: weaver@nexus.astro.psu.edu (George M. Weaver)
Subject: Cursor keys on Sun Type-5 Unix Keyboard?
Reply-To: weaver@nexus.astro.psu.edu
Organization: Penn State Astronomy and Astrophysics
Date: Tue, 12 Jan 1993 23:34:56 GMT

I suspect this has been covered before, but ...

What hath Sun wrought such that emacs run on an SS-10 in
raw console mode doesn't recognize either set of cursor
keys on my Type-5 Unix keyboard?  It works fine in an
xterm or epoch window.

    -George Weaver
     Computing Facilities Manager
     Department of Astronomy and Astrophysics
     The Pennsylvania State University
From: hardy@golem.ps.uci.edu (Meinhard E. Mayer (Hardy))
Subject: Re: EMACS ON HP-UX 8.0
In-reply-to: lad@remus.rutgers.edu's message of 9 Jan 93 16:41:52 GMT
Newsgroups: comp.emacs
Organization: Department of Physics, UC Irvine, CA 92717-4575, USA
Date: 13 Jan 93 04:39:38 GMT
Followup-To: comp.emacs

In article <Jan.9.11.41.51.1993.6885@remus.rutgers.edu> lad@remus.rutgers.edu (Kamlesh) writes:


???   Will the GNU version of emacs work on a HP 9000 running HP-UX 8.0 ?
You can get sources and configuration files for HP-UX off the
HP-archive at ftp.csc.liv.ac.uk, as well as from the Interworks
library. 18.59 compiles fine under HP-UX, but without the "HUGE"
enhancements (function keys, highlighted copy/paste, etc).

--
Hardy 
-----
Meinhard E. Mayer,  Department of Physics, UC Irvine 
e-mail: hardy@golem.ps.uci.edu (preferred) or MMAYER@UCI.BITNET
!!!! NO NEXTMAIL TO THESE ADDRESSES, PLEASE !!!!!
Newsgroups: comp.emacs
From: simon@lia.di.epfl.ch (Simon Leinen)
Newsgroups: comp.emacs
Subject: Re: EMACS ON HP-UX 8.0
Date: 10 Jan 93 13:48:17 GMT
Followup-To: comp.emacs
Organization: Ecole Polytechnique Federale de Lausanne
In-reply-to: lad@remus.rutgers.edu's message of 9 Jan 93 16:41:52 GMT
X-Md4-Signature: e11719e5f383a723f871061e02f063d3

In article <Jan.9.11.41.51.1993.6885@remus.rutgers.edu>
lad@remus.rutgers.edu (Kamlesh) writes:

   Will the GNU version of emacs work on a HP 9000 running HP-UX 8.0 ?

Yes.

The current release of GNU Emacs (18.59) supports HP-UX 8.0.  The
HP-UX 8.0 configuration files also work under HP-UX 9.0.
-- 
Simon.
From: franl@centerline.com (Fran Litterio)
Newsgroups: comp.emacs
Subject: Re: EMACS ON HP-UX 8.0
Date: 10 Jan 93 16:39:06 GMT
Followup-To: comp.emacs
Organization: CenterLine Software, Inc.
NNTP-Posting-Host: 140.239.3.116
In-reply-to: lad@remus.rutgers.edu's message of 9 Jan 93 16:41:52 GMT

lad@remus.rutgers.edu (Kamlesh) writes:

> Will the GNU version of emacs work on a HP 9000 running HP-UX 8.0 ?

Yes.  There is an HP-internal version of Gnu Emacs called HUGE that
has been ported to many (if not all) current versions of HP-UX.  But
version 18.59 can be built on a Series 400 running 8.0 by changing
src/config.h (which you create by "cp config.h-dist config.h") to
#include these two files:

	m-hp9000s300.h
	s-hpux8.h

instead of

	m-vax.h
	s-bsd4-2.h

which are the default.
--
franl@centerline.com         "So what we've decided to do is set you up in
uunet!centerline!franl        Cicely, situated in an area that we Alaskans
617-498-3255 (USA)            refer to as The Alaskan Riviera."
PGP 2.0 public key available.
From: sbobadbh@w204zrz.zrz.tu-berlin.de (Shashi-Shakher Mishra)
Newsgroups: comp.emacs
Subject: Need Help file for GNUS News reader
Date: 8 Jan 1993 11:32:10 GMT
Organization: ZRZ der TU-Berlin
Distribution: world
NNTP-Posting-Host: w204zrz.zrz.tu-berlin.de
Keywords: Hi ! could someone send me the above at sharma@math.tu-berlin.de

Thanks Rohit Sharma



Newsgroups: comp.emacs,gnu.emacs.help
Newsgroups: comp.emacs,gnu.emacs.bugs,gnu.emacs.help

Lutz Pressler writes:

+----------------
+ I'm using ange-ftp (ange-ftp.el,v 4.20 92/08/14 17:04:34) with
+ GNU-Emacs 18.57.2 or 18.58.1 on DECstations (Ultrix 4.2A or 4.3 with
+ DECs X11R4). It is possible to run ange-ftp (e.g. copying a remote
+ file) in the background and edit another buffer etc. One has to
+ press Ctrl-G before maybe, but I don't think it's neccessary. 
+----------------

ange-ftp 4.20, the latest release, will copy files asynchronously using either
M-x copy-file or "tree" dired's "c" command if called interactively.  However,
"tree" dired MUST be byte-compiled using Jamie Zawinski's excellent
byte-compiler and not the standard v18 byte-compiler.

I'd recommend NOT using C-g with ange-ftp as it may be left in an
"interesting" state... at least for that ftp transaction.

+----------------
+ .. normally I work under X11 (at least if I'm at university and not at
+ home...) and Emacs won't accept any keyboard event (any event?) while
+ copying a file etc... That's not the way I like to see... Is this a
+ bug in our configuration (I don't think so), a bug in ange-ftp or
+ tree-dired (sorry, forgot about tree-dired, using that, too (rev.
+ 5.239), or generally impossible?
+----------------

If ange-ftp is tightly monitoring the output from an ftp process (which
happens if you don't use it asynchronously) then it is possible that when I
call accept-process-output with an argument of the ftp process incoming X11
events may be blocked until the ftp transaction has completed.

This doesn't happen when ange-ftp is happily copying files asynchronously.

+----------------
+ Any help will be appreciated, also any hint how to change ange-ftp or
+ dired, if changes are neccesary. (I'm quite capable of doing
+ elisp-programming.)
+----------------

I hope the above helps.

Questions related to ange-ftp can also be posted to the ange-ftp-lovers
mailing list where I'm much more likely to spot them.  See the comments in
ange-ftp.el for how to subscribe.
					-- ange -- <><

					ange@hplb.hpl.hp.com
From: milt@lax.pe-nelson.com (Milt Ratcliff)
Newsgroups: comp.emacs
Subject: demacs and execution problems
Summary: delete key & execution in a dos shell window
Keywords: demacs
Date: 11 Jan 93 22:20:22 GMT
Organization: PE-Nelson


Alas, yet another poor soul trying to run demacs under DOS.  Actually
I am trying to run demacs in a DOS shell(4DOS) under windows.

Two problems.


1. In a DOS shell, under windows, I get the error...

CPU must be in REAL mode (not V86 mode) to run this program.

... Is there a fix for this?

2. In DOS when I run demacs, I have NO delete key.  Neither the backspace
nor the delete key works.  How do I get the backspace key to delete 
characters?

Thanks,
-- 
Milt Ratcliff                                            milt@PE-Nelson.COM
PE-Nelson                                                +1.408.725.1107
10040 Bubb Road
Cupertino, CA  95014
Newsgroups: mot.general,comp.emacs,gnu.emacs.gnu
From: davew@sol.rtsg.mot.com (Dave Weigand)
Subject: Re: A good emacs X-window mouse package
Reply-To: davew@jdc.gss.mot.com
Organization: Motorola Digital Cellular
Date: Tue, 12 Jan 1993 22:02:22 GMT

In article <1993Jan11.122723.7527@lmpsbbs.comm.mot.com>, francois@mot.com (Andre Francois) writes:
|> I had a really nice mouse package for emacs that gave me the ability to
|> cut and paste into the X-buffer and resize and create windows and also
|> had some help menus in X.  I lost it.  Could someone send me a copy or
|> tell me EXACTLY where I can get one.
|> Andre Francois
|> Internet mail: eaf003@email.comm.mot.com


Sounds like you may be referring to Epoch.  It provides a GUI (mouse-driven)
X-interface to EMACS.  It is available via anonymous ftp from cs.uiuc.edu.


-Dave

--
+-------------------------------------------------------------------------+
| Dave Weigand                       | Internet:  davew@mot.com           |
| Senior Electrical Engineer         |         or davew@jdc.gss.mot.com   |
| Japan Digital Cellular             |    if you really must ...          |
| General Systems Sector             | UUCP:      uunet!motcid!weigand    |
| Motorola, Inc.                     | Voice:     (708) 632-2248          |
|-------------------------------------------------------------------------|
| #include  <std_disclaimer>                                              |
|   It's only a real computer if it runs Epoch ... everything else is     |
|   simply a peripherial!!   -me                                          |
+-------------------------------------------------------------------------+
Newsgroups: comp.emacs
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: emacs filesize limitations
Organization: Los Alamos National Laboratory
Date: Wed, 6 Jan 1993 19:47:46 GMT

There seems to be a filesize limitation in emacs of 2^23 bytes.
The editor does not detect files which violate this limit nor
is the limitation documented (as far as I've yet determined).
The editor merely starts to behave unreliably for such large
files.  Is there a document which describes this limitation.
Are there any plans to correct it?  (Note: *whatever* is done
will most likely leave some sort of limitation, so the way
to correct the problem is to detect violations and not just
increase the limit.)  What is the appropriate procedure for
reporting such problems and/or getting current information 
on new releases and fixes?  Is anyone actually doing bugfix
work on the tool at all?

Thanks in advance.

-- 
J. Giles
Newsgroups: comp.emacs
From: aarond@xibm.StorTek.com (Aaron Dailey)
Subject: minimum files to run gnu emacs
Organization: StorageTek
Date: Thu, 7 Jan 1993 22:58:20 GMT

We're setting up a portable sparc system to run standalone for trips
in the field.  Unfortunately, we only have a 200 MB hard drive, and
need to put several tools on it.  I want to put emacs on it, but I
need to minimize the space it takes.  Although I've used emacs for
over a year, I'm realizing I don't really understand entirely what
happens when you type emacs and the editor appears magically.

So, what do I need?  Of course, I need the executable.  How 'bout the
elisp files - some of them seem to be loaded dynamically (the
rectangle functions come to mind), but most are already in the
executable?  If I need the elisp files, do I just need the .elc files,
not the .el files.  None of the .c or .o files, I assume, and nothing
from the ./etc directory, except the executables.

Thanks,

--
Aaron Dailey Internet: Aaron_Dailey@stortek.com
StorageTek Corporation   Voice: (303) 673-4989, FAX: (303) 673-2570
Mail:  MS0242, 2270 South 88th Street, Louisville, C0 80028
From: hancu@crim.ca (Marius Hancu)
Newsgroups: comp.emacs
Subject: Sending mail while the file ~/outfold is visited
Date: 8 Jan 93 20:20:56 GMT
Organization: Centre de Recherche Informatique de Montreal

My outgoing mail is saved in the ~/outfold file. However, I seemes
troubles are generated when I try C-c C-s or C-c C-c while this file
has been previously been visited and the corresponding buffer is open.
Emacs tells me the buffer is read-only.

I found this in the emacs FAQ:
 

 WARNING: If you are visiting the file ~/outgoing at the time you send
     the mail, this can cause a variety of horrible problems.  Jamie
     Zawinski has written a solution for this.

I wonder if you have this solution or if you have Jamie's Zawinski
email address. 

Thank you.

-- 
Marius Hancu, Parallel Architectures Group 
Centre de Recherche Informatique de Montreal (CRIM)
3744, Jean-Brillant, Bureau 500, Montreal, Quebec H3T 1P1, Canada 
phone: (514) 340-5907, fax: 514-340-5777, email: hancu@crim.ca
Newsgroups: comp.emacs,gnu.emacs.help