HDTenEightyP/NetNews huggingface dataset:
From: friedl@mtndew.Tustin.CA.US (Stephen Friedl)
Newsgroups: comp.std.c
Subject: Re: POSIX means *Binary* Compatibility !  NOT !
Date: 21 Nov 92 21:49:53 GMT
Organization: Steve's Personal machine / Tustin, CA

Rob Freyder writes:
> Just  had  a  conversation with a consultant regarding POSIX. According to
> this  consultant  if  I  compile a POSIX program with a POSIX compiler the
> resultant binary will run on any machine that supports the POSIX std. !

Time to change consultants!

     Stephen

-- 
Stephen J Friedl | Software Consultant | Tustin, CA |     +1 714 544-6561
3b2-kind-of-guy  | I speak for me ONLY |   KA8CMY   | uunet!mtndew!friedl
 
Attorneys are paranoid because they assume everybody else is dishonest too
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.std.c
Subject: Re: Must an object remain in place? (was: fwrite+fread of pointer)
Date: 20 Nov 92 00:44:00 GMT
Organization: CWI, Amsterdam

In article <1992Nov19.061601.13164@sq.sq.com> msb@sq.sq.com (Mark Brader) writes:
 > The desire to not break this code is a fairly strong argument that
 > objects should not be movable at all.  You might argue that maybe
 > it would be safe to allow movement only in special circumstances, like
 > when malloc() is called -- but when what if the comparison function
 > is not the simple pstrcmp() but something complicated that itself
 > calls malloc()?
 > 
 > But even if this argument is accepted, it only conveys intent.  As to
 > the actual wording of the standard requiring objects not to move, the
 > best I can come up with is the thing I already quoted: section 1.6/3.14,
 > where an object is defined as *a* region of data storage.  My inter-
 > pretation is that the singular wording implies one particular region
 > for the life of the object, not merely one at a time.

Well, examine the *as if* rule.  I think a run-time system is able to
move data under the proviso that it is able to identify all pointers
and update them accordingly; even if they are stored in non-pointer type
variables.  (I know of one Algol 68 garbage collector that did just that,
but it cheated.  On a tagged architecture it would certainly be possible.)
The questions answered are different from the question what happens if you
write a pointer to file and read it back in.  Let us rephrase:

	sometype *p = something;
	char save_p[sizeof(p)];

	(void)memcpy((void *)save_p, (void *)&p, sizeof(p));
	... many things happen here, except that all references to
	    something are still valid, whether something is moved or not
	(void)memcpy((void *)&p, (void *)save_p, sizeof(p));

Is it now guaranteed that 'p' still/again points to 'something'?
What is the answer if 'save_p' was modified and changed back in between?
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
Newsgroups: comp.std.c
From: sjc@borland.com (Steve Correll)
Subject: Re: Memory Usage by C
Originator: sjc@genghis.borland.com
Organization: Borland International
Date: Mon, 23 Nov 1992 05:56:11 GMT

In article <1992Nov20.020950.15516@nntpd.lkg.dec.com> diamond@jit.dec.com (Norman Diamond) writes:
>In article <1992Nov19.190526.26770@den.mmc.com> richard@crowded-house.den.mmc.com (Richard Armstrong) writes:
>>Are literals always stored in the same location in memory?
>
>The standard says that identical string literals need not be distinct...
>
>>(IBM-PC,Borland)
>
>Ask Borland...
>
>>For instance, is the string a stored in the same place in the following
>>two declarations?:
>>static char *a[]="ABC";
>>funca()
>>{
>>char *a[]="ABC";
>>}

Ask and ye shall receive: whether the Borland compiler overlays duplicate string
literals within this compilation depends on the "-d" flag (or, for the IDE, the
OPTIONS|COMPILER|CODEGENERATION menu). The compiler will complain about the
absence of {} around the string (perhaps you meant to say "char a[]" or "char
*a" rather than "char *a[]"?) due to section 3.5.7 of the standard.
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: Must an object remain in place? (was: fwrite+fread of pointer)
Date: 23 Nov 92 11:28:37 EST

msb@sq.sq.com (Mark Brader) writes:
>> Well, examine the *as if* rule.  I think a run-time system is able to
>> move data under the proviso that it is able to identify all pointers
>> and update them accordingly; even if they are stored in non-pointer type
>> variables.  (I know of one Algol 68 garbage collector that did just that,
>> but it cheated.  On a tagged architecture it would certainly be possible.)
>In theory maybe, but not in practice.   Consider that you can transform
>a pointer to a character string with "%p" in sprintf(), do arbitrarily
>complex operations on the characters which end up reproducing the same
>string, then use "%p" in sscanf() to reconstruct the pointer, and the
>result must compare equal to the original pointer.

That's a pretty strong requirement, I think, but still not quite enough to
(by itself) ensure that the contents of pointer variables may not change
during execution:

	printf("%p\n", ptr);

could yield something like "<The Object Named Fred-0007>", if the architecture
supported some other constant naming scheme for objects other than their
virtual bus addresses.
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.std.c
Subject: Re: malloc(0)
Date: 23 Nov 92 10:41:27 GMT
Organization: AND Software BV Rotterdam

In article <2305@sdrc.COM> scjones@thor.sdrc.com (Larry Jones) writes:
|In article <1992Nov21.005207.9741@lucid.com>, jss@lucid.com (Jerry Schwarz) writes:
|< The standard says  (refering to allocation routines)
|< 
|< 	If the size of the space requested is zero, the behavior
|< 	is implementation-defined; the value returned shall be
|< 	either a null pointer or a unique pointer.
|< 
|< I have always read "unique pointer" as meaning different from
|< previously allocated pointers including pointers previously
|< returned by malloc(0).
|
|That was indeed the committee's intent.  If every call for zero space
|returned the same pointer it wouldn't be very unique, would it?

No it wouldn't, but if it would return a unique pointer value,it would
brake code like this:

char *p= malloc(0);
char *q= malloc(0);

if (p == q)
	printf("malloc returned NULL or non-unique value"\n");
else
	printf("malloc returned two unique pointers\n");

when ported from a system where malloc(0) returns NULL to a system
where malloc would return a unique pointer every time it was 
called with a size of zero ...

regards,

Jos aka jos@and.nl

ps. Bill Mitchell (mitchell@mdd.comm.mot.com) quoted the rationale
    concerning this topic <1992Nov21.191712.1397@mdd.comm.mot.com>
    but the rationale doesn't say much about this (pathetic) little
    problem ...
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.std.c
Subject: Re: Casting const; Is this standard conforming?
Date: 17 Nov 92 14:44:02 GMT

In article <1992Nov16.200843.5565@Princeton.EDU>, rhl@grendel.Princeton.EDU (Robert Lupton the Good) writes:
>    const int i = 0;
>    
>    (int)i = 1;				/* Fails */

The result of a cast is not an l-value and thus cannot be assigned to.

>    *(int *)&i = 1;			/* OK */

This is acceptable syntax, but results in undefined behavior since i is
defined as a const variable.  The compiler is allowed to place it in
read-only memory, which would cause the assignment to fail.

> I want to set
> the variable once in a private place just after mallocing it, in case
> you wonder why I am trying to get around a const restriction, and
> don't see why I can't just initialise it

That's a different case than your example: the memory that malloc()
returns is *not* defined with the const qualifier, just the pointer that
you are using to access it.  In that case the second method is well
defined and portable.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com  or  ...uunet!sdrc!larry.jones
OK, what's the NEXT amendment say?  I know it's in here someplace. -- Calvin
Newsgroups: comp.std.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: strcmp() on a non-nil-terminated string
Organization: SoftQuad Inc., Toronto, Canada
Date: Mon, 16 Nov 92 22:47:26 GMT

> #include <string.h>
> char first[]="first";
> char second[]={'s','e','c','o','n','d'};
> main()
> { return!!strcmp(first,second); }
 
> Is this program allowed to behave undefined?

Yes.  Section 4.11.4.2 in the ANSI standard (7.11.4.2 in the ISO version)
specifies that the arguments of strcmp point to strings.  4.1.1 (7.1.1)
defines "string" (and what it means to point to one).  The array named
second does not contain a null character and therefore the pointer to
which it decays is not a valid argument to strcmp().  The result is
undefined behavior, as required by 4.1.6 (7.1.7).
 
> If so, can anyone imagine provide an example when this might happen?

Consider a hypothetical machine with a fast operation to compare blocks
of, say, 64 bytes, and another fast operation to scan forward up to a
certain number of bytes past a given address looking for a null byte.

Strcmp() might then be implemented like this:

	int strcmp (const char *s1, const char *s2)
	{
		for ( ; __no_nulls(s1, 64) && __no_nulls(s2, 64)
				&& __64_bytes_equal(s1, s2);
					s1 += 64, s2 += 64)
			;
		return __normal_strcmp(s1, s2);
	}

where __no_nulls() and __64_bytes_equal() each compile to a single
operation.  Then if the array named second is at the end of memory...
bang!

> You would expect a sane implementation to return with an exitcode of 1.

Well, I agree with this if the "sane implementation" is on what we would now
call a conventional computer.  However, I make no predictions as to what
sorts of computers will appear, let alone be conventional, in the future!
-- 
Mark Brader			"... one of the main causes of the fall of
SoftQuad Inc., Toronto		 the Roman Empire was that, lacking zero, they
utzoo!sq!msb			 had no way to indicate successful termination
msb@sq.com			 of their C programs."		-- Robert Firth

This article is in the public domain.
Xref: sparky comp.std.c:3060 comp.lang.c:17070
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: Struct hack (was: Re: Is this ANSI?)
Date: 23 Nov 92 22:51:33 GMT
Article-I.D.: alice.24274
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <9232902.26984@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
> ark@alice.att.com (Andrew Koenig) writes:

> >... to convince me
> >that it's legal, you'd have to find language in the standard that allows
> >it.

> Sure, but to convince me that it's illegal, you'd have to find language
> in the standard that disallows it :-)

And so on.

Mark Brader pointed out that there had already been a discussion of
this in comp.std.c, which I don't read, and which concluded that I
was mistaken about interpreting the Standard.

At the same time, more or less, I asked Tom Plum, who is a member of
the C committee, whether this issue had been discussed there.  His
response: it has, and he agrees with me, for exactly the reasons I
gave -- and I hadn't told him in advance what my opinion was.

So there you have it.  The net reaches one conclusion, the C committee
reaches a different one.  Mark and I both think it's a simple matter,
but reach opposite conclusions.

I guess it's not as simple as I thought, but I'm willing to defer to
the C committee on this one, since they evidently agree with me :-)
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.std.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: Idle Questions about ANSI C
Organization: SoftQuad Inc., Toronto, Canada
Date: Thu, 19 Nov 92 07:14:10 GMT

> > The wording of section 3.1.2.5/6.1.2.5 of the standard clearly implies
> > that the 9 "usual" integral types are the only ones.  They consist of
> > 4 signed integer types, 4 unsigned integer types, and char -- which
> > of course can be either signed or unsigned.  Since size_t and ptrdiff_t
> > are specified respectively as unsigned or signed *integral* types, not
> > *integer* types, then an implementation could actually use char for
> > one of them ...
> 
> To get nitpicky, section 3.3.3.4 states that size_t is an
> unsigned integral type.  Section 3.1.2.5 discusses the integral
> types.  As I read it, no matter what its implementation, char is 
> neither an unsigned integral type nor a signed integral type.  Thus,
> there are 4 possibilites for size_t and ptrdiff_t.

Well, I'll back off part way.

The standard defines the terms "signed integer type", "unsigned integer
type", and "integral type", but it does not define "signed", "unsigned",
"signed integral type", or "unsigned integral type".  Therefore these
terms mean what they look like, and an integral type that is signed
is a signed integral type.

Values of char can be "treated as either signed or nonnegative integers".
In the first case, char *is* therefore a signed integral type, and could
be the type of ptrdiff_t.  However, since the second case does not use
the word "unsigned", it might be argued *not* to imply that char is then
an unsigned type; in particular, it might not have the "cannot overflow"
semantics that unsigned integer types do.  (I think it would need an
Interpretation Ruling to settle this.)  So even in an implementation where
char is not signed and is big enough, it might not be legitimate for it
to be size_t.
-- 
Mark Brader, Toronto		"It's the almost correct solutions that
utzoo!sq!msb, msb@sq.com	 are the most dangerous..."  -- Dave Eisen

This article is in the public domain.
Newsgroups: comp.std.c
From: msb@sq.sq.com (Mark Brader)
Subject: Must an object remain in place? (was: fwrite+fread of pointer)
Organization: SoftQuad Inc., Toronto, Canada
Date: Thu, 19 Nov 92 06:16:01 GMT

> Let's see if I can bring this into sharper relief by eliminating the
> file ...
> 
> int *p; int dummy; char tmp[sizeof(int *)];
> p = &dummy; memcpy(&tmp[0],&p,sizeof(int *));
>	 /* insert other code here, not touching any
>	    of these three variables, if you feel like it */
> memcpy(&p,&tmp[0],sizeof(int *));
>
> At this point, must p == &dummy?  Must a reference to *p access the
> same object a similar reference to dummy would?  Note that the two
> questions do not ask quite the same thing, I think.

First, the two questions *do* ask the same thing.  In the standard,
sections 3.3.8/6.3.8 and 3.3.9/6.3.9 (ANSI/ISO numbering) specify in part:

#  If two pointers to object ... types both point to the same object,
#  ... they compare equal.  ... If two pointers to object ... types
#  compare equal, they both are null pointers, or both point to the
#  same object, or both point one past the last element of the same
#  array object.

Since &dummy points to an object, this means that p==&dummy if and only if
p points to the same object.

I'd like to point out that, while the above example code looks contrived,
things like that *do* happen in commonplace programs, and therefore it
would break working code if objects could be moved at arbitrary times.
Consider *this* code:

	#include <comp/lang/c/FAQ-list.h> /* :-) */   /* for pstrcmp() */

	char *list[N_ENTRIES];
		/* read n (<= N_ENTRIES) strings into list */
	qsort (list, sizeof (char *), n, pstrcmp);

What else could qsort() be using to rearrange the list entries but memcpy()
or some functional equivalent?

The desire to not break this code is a fairly strong argument that
objects should not be movable at all.  You might argue that maybe
it would be safe to allow movement only in special circumstances, like
when malloc() is called -- but when what if the comparison function
is not the simple pstrcmp() but something complicated that itself
calls malloc()?

But even if this argument is accepted, it only conveys intent.  As to
the actual wording of the standard requiring objects not to move, the
best I can come up with is the thing I already quoted: section 1.6/3.14,
where an object is defined as *a* region of data storage.  My inter-
pretation is that the singular wording implies one particular region
for the life of the object, not merely one at a time.
-- 
Mark Brader		   "Doing the wrong thing is worse than doing nothing."
SoftQuad Inc., Toronto     "Doing *anything* is worse than doing nothing!"
utzoo!sq!msb, msb@sq.com		     -- Lynn & Jay: YES, PRIME MINISTER

This article is in the public domain.
Newsgroups: comp.std.c,comp.std.misc
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: POSIX means *Binary* Compatibility ! NOT !
Followup-To: comp.std.misc
Organization: Computer Science, University of Melbourne, Australia
Date: Mon, 23 Nov 1992 03:25:40 GMT

rob@hp11 (Rob Freyder) writes:

>Just  had  a  conversation with a consultant regarding POSIX. According to
>this  consultant  if  I  compile a POSIX program with a POSIX compiler the
>resultant binary will run on any machine that supports the POSIX std. !
>
>I  found  this  very  amusing. For example if I compile on my SUN Sparc II
>the  binary  can  be  copied  unmodified  to  my  HP 730 Snake box and run
>unmodified !   Amazing story 31b !!!

Theoretically it's quite possible.
Programs could be compiled to a standard bytecode format which would then
be interpreted, or even compiled to machine code at load-time.
Such files would be ``binary'', although they would not be machine code.
So long as POSIX were to specify the standard format for these bytecode
files, probably starting with something like
	#!/bin/bytecode_int
so that programs could be invoked without having to explicitly specify that
they were to be interpreted, then things would work fine.

>Has anyone done this ?

I haven't done it with C programs, but I have done it with
programs in other languages. Using a standard bytecode format,
we achieved seamless portability from DOS to VAX to OS/2 to about a dozen
different unix-based systems. Indeed, the interpreter for the bytecode
was available for over 700 different machines. For a company with limited
staff resources, this sort of seamless portability was invaluable.

On the other hand, I have not heard that POSIX was to include such a
standard. Maybe you should double-check with your consultant? :-)

-- 
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: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: strcmp() on a non-nil-terminated string
Date: 17 Nov 92 17:38:22 GMT
Article-I.D.: ksr.18866

berg@physik.tu-muenchen.de (Stephen R. van den Berg) writes:
>char first[]="first";
>char second[]={'s','e','c','o','n','d'};
>main()
>{ return!!strcmp(first,second);
>}
>--------------------------------------
>Is this program allowed to behave undefined?

4.1.1 Definitions of Terms "A string is a contiguous sequence of characters
terminated by and including the first null character."
4.11.1 String Function Conventions "If an array is accessed beyond the end
of an object, the behavior is undefined."
4.11.4.2 The strcmp Function "The strcmp function compares the string pointed
                                                               ^^^^^^
to by s1 to the string pointed to by s2."	(emphasis added)
                ^^^^^^

>You would expect a sane implementation to return with an exitcode of 1.

*I* would expect a sane programmer to read and understand the manual before
plugging in the C compiler.
Newsgroups: comp.emacs
From: nrh@philabs.philips.com (Nikolaus R. Haus)
Subject: EMACS: It can cut and paste, but can it fold?
Originator: nrh@lion
Keywords: fold
Reply-To: nrh@philabs.philips.com (Nikolaus R. Haus)
Organization: Philips Laboratories, Briarcliff, NY 10510
Date: Mon, 23 Nov 1992 17:55:35 GMT


Hi all.
Quick question (I hope):
Does anyone know if anything has been written to make emacs behave like a
folding editor? This would be most useful to me- I am currently a sporadic-
at-best user of emacs (default keybindings are familiar from working with
PerfectWriter on a CP/M machine in the early 80's, if you can believe it),
so I'd also be interested in how one installs new 'modes' etc. into emacs.

If it matters, I'm using DEMACS 1.2.0 (GNU 18.55.120) on a 386DOS machine.
(unix too, but primarily DOS, unfortunately)
-- 
"... nights of heat and weirdness in which we alone are awake,
 humming with forbidden energy; nights into which we would not
 send our dogs - wild sea and wet forest and eyes and teeth ..."
Newsgroups: comp.emacs
From: smoore@nelson.tx.ncsu.edu (Sam Moore)
Subject: Get rid of indent on initial level of C Mode
Organization: North Carolina State University
X-Newsreader: TIN [version 1.1 PL6]
Date: Mon, 23 Nov 1992 16:16:50 GMT

Can someone tell me how to get rid of the initial indent in C language
mode in GNU Emacs? I like what it is doing for me, except the initial
indentation. I would like the data definitions and the first level
statements to start at column 0:

int foo(arG)
int	arG;
{
int	i;

if (....) {
	...
}

return(1);

}

Thanks

...Sam Moore...............................Computer Operations..............
...Mail:  Sam_Moore@ncsu.edu...............College of Textiles..............
...Phone: +1 (919) 515-6594................North Carolina State University..
...FAX:   +1 (919) 515-3057................BOX 8301, Raleigh, NC 27695......
From: steibel@venus.cs.umbc.edu (David M. Steibel)
Newsgroups: comp.emacs
Subject: Re: repetetive search with function keys
Date: 21 Nov 92 18:30:24 GMT
Distribution: usa
Organization: University of Maryland Baltimore Campus

sastr_a@ptah.cs.odu.edu (RAVI AYYALASOMAYAJULA) writes:

> My question is how do I make my fuction key search repetitively search
> for the search the same string?

You would want to bind it to isearch-forward, and isearch-backwards.
Note that isearch-forward is sometimes already bound to control-s,
except when control-s is used for flow control purposes.  Sometimes
isearch-forward is bound to control-backslash also.  Try both and see,
although if trying control-s freezes your screen, you will have to
type control-q to resume.  isearch-backwards is almost always bound to
control-r.

isearch works somewhat uniquely.  After typing the first character, it
will find the first string that matches the first character.  After
typing the second character, it will find the first string matching
the second character and so on until it can no longer find a match.
Typing a backspace will pull the cursor back to last match, and typing
backspace until the end of the buffer will leave you where you
started.  control-d ends the process, as does moving around with the
cursor keys.  Also, if you have finished your search string, and wish
to find the second occurance of your search string, press the isearch
key again.  If you wish to use the same search string after exiting
the isearch search editor line, press isearch twice and it will resume
with the last string you typed in.

That all is assuming you use the natural bindings for isearch.  I
never tryed binding isearch to a function key.  For more info, 
read the manual or use online help.

--
David M. Steibel;  Author of the Demacs FAQ;  Internet: steibel@cs.umbc.edu

The greatness of a nation and its moral progress can be measured by the way 
in which its animals are treated. - Mahatma Gandhi.
Newsgroups: comp.emacs