HDTenEightyP/NetNews huggingface dataset:
From: mjn@pseudo.uucp (Murray Nesbitt)
Subject: Re: scrcpy implementation question
Organization: Private system in Toronto, ON
Date: Thu, 27 Aug 1992 06:52:09 GMT


diamond@jit081.enet.dec.com (Norman Diamond) writes:

>extension would begin with two underscores.  The standard reserves to the
>implementation all identifiers that begin with scr, so it is also permitted

I think Norman meant to write "begin with ``str''".

To pick nits, it should actually read "begin with ``str'', followed by
a character from the set [a-z]."

-- 
Murray
From: dmm@vnet.ibm.com (dave)
Date: Wed, 26 Aug 92 15:33:47 EDT
Newsgroups: comp.std.c
Subject: Re: space optimization involving enum
Organization: IBM Canada Lab
News-Software: UReply 3.0
X-X-From: dmm@vnet.ibm.com (Dave Mooney)

            <1992Aug26.184220.8236@taumet.com>

In <1992Aug26.184220.8236@taumet.com> Steve Clamage writes:
>                                                If enums are smaller
> than ints, avoid those too.

That means that given

  enum c { red, green, blue };
  int f( x ) enum c x; { }

there is no strictly-conforming way to write a parameter-list prototype
for the function f.

  int f( int );

would be right if  enum c  were of short or char size.  If  enum c  were
of int or long size, then

  int f( enum c );

would be the prototype, right?

dave

-------------------------------------------------------------------------
Dave Mooney                                              dmm@vnet.ibm.com
 C Set/2 Development, IBM Canada Lab, 844 Don Mills Rd, Toronto, Ontario
            "If you've got a blacklist, I want to be on it"
From: diamond@jit081.enet.dec.com (04-Sep-1992 1639)
Newsgroups: comp.std.c
Subject: Re: struct hack, was Re: strcpy implementation question
Date: 4 Sep 92 07:41:41 GMT

In article <1992Sep4.015335.3612@thinkage.on.ca> dat@thinkage.on.ca (David Adrien Tanguay) writes:
>diamond@jit081.enet.dec.com (03-Sep-1992 1325) writes:
>>In article <PINKAS.92Sep2173635@skywalker.intel.com> pinkas@skywalker.intel.com (Israel Pinkas) writes:
>>>The variable length struct is a hack.  There is nothing in the language that
>>>prevents the compiler from performing bounds checking on accesses to name.

>>Uh, nothing except the standard's definitions of [], unary *, and binary +
>>operators.  :-R rhetoric.
>>Bounds checking is not allowed to affect output of a valid but ugly program.

>I had the impression that the last time it came up here the conclusion was
>that this trick was not sanctioned[...]  3.3.6 "Additive Operators"
>says that you aren't guaranteed to go past the end of an array object,

No (though it was the conclusion of some others) and yes, respectively.
You can't go past the end of an array object.  But if malloc() or some other
variable has defined the end of the actual array object, then the + operator
can get you that far, regardless of the declared type that some other array
variable had before getting flattened to a pointer.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.std.c
Subject: Re: How is struct assignment defined (idle query)?
Date: 3 Sep 92 20:13:58 GMT

In article <715547606snx@grendel.demon.co.uk>, jes@grendel.demon.co.uk (Jim Segrave) writes:
> Does ANSI say that structure assignment is done by member-wise copy or
> by bit-wise copying?

No.  ;-)
The details are left unspecified -- member-wise copy is all that's
required but bit-wise copy is acceptable and is undoubtedly the
most common implementation (with the possible exception of not
copying trailing padding).
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
Domain: lawrence.jones@sdrc.com               IBMMAIL: USSDR7DR at IBMMAIL
See if we can sell Mom and Dad into slavery for a star cruiser. -- Calvin
Newsgroups: comp.std.c
From: bill@twwells.com (T. William Wells)
Subject: void expressions and volatile types
Organization: None, Mt. Laurel, NJ
Date: Thu, 27 Aug 1992 16:36:04 GMT

Certain contexts, the left operand of the comma operator,
expression statements, and the first and third expressions of a
for statement, are designated as void expressions. (I'd assume
that the operand of a cast to void is also.) A void expression is
defined as one where the value of the expression is discarded. The
key is the word "discarded". This implies that the value is
computed but then ignored.

The problem is then what to do with statements like a; and a=b;
when a is a volatile object. The first expression accesses a but
then discards the value, which is fine. The other does NOT do
what you'd expect, though. The reason is that the assignment has a
value which is the value of a after the assignment, which can only
be obtained by accessing a. Thus a=b results in a sequence like:

	load b
	store a
	load a

rather than the intended load and store.

I personally would prefer the other interpretation, in which a
void expression is, as the standard _also_ says, evaluated only
for its side effects. Otherwise, one would have serious problems
using volatile for device registers. (This would have the effect
that a; doesn't actually reference a because no value is computed
but I think that that is a legitimate action. (int)a; would force
the access anyway.)

---
Bill                            { uunet | decwrl | telesci }!twwells!bill
bill@twwells.com
Newsgroups: comp.std.c
From: kleung@esk.compserv.utas.edu.au (Kam  Leung)
Subject: Implementation of semaphores in "c" 
Organization: University of Tasmania at Launceston
Date: Thu, 27 Aug 92 11:44:20 GMT


Dear guys,
      I have a difficulty in enforcing the mutual exclusion between
5 philosophers because I couldn't effectively change the global 
variables such as the major semaphore (me), and the private semaphore
(s[i]).  Could anybody suggest an answer for me or comment on my logic
below.  Your kind attention is much appreciated.  Thanks...

  kleung@esk.compserv.utas.edu.au

#include <stdio.h>
#include <sys/types.h>
#define N              6
int  s[N], me;
enum status {nthinking,vhungry,neating} ;
enum status p[N];
main()
{
  int i, ;
  void  PHILOSOPHER(), 
        think(), eat(), hungry();

  me = 1;    /* initial open state of main semaphore */

  for (i=1;i<N;i++) /*initialise 1-5 philosophers to thinking*/
      { s[i] = 0; p[i] = nthinking;}  /* private semaphore s[i]=0,close*/

  for (i=1; i<N; i++){
	if (fork() == 0) PHILOSOPHER(i);
  }
        ..
        ..
  kill(0,9);
}
void PHILOSOPHER(i)
int i;
{
		think(i);
      -----------waitfor(me); 
      !     /* see whether the sem. is open(me=1) or close(me=0)
      !        if me=1, pass thru, and set the me back to 0   */ 
      !		hungry(i);
      !         philosopher i = hungry
      !         printf("\nphil %d has gone into c.s.",i);
      !         check if the lefthand and righthand philosopher 'not eating'  
      !         if it is so,  set itself = eating, release private sem.
      !         of itself : signalto(p[i]) -- supposed to set p[i] = 1
      !         but didn't...... 
      ---------	signalto(me);
		waitfor(s[i]);
		eat(i);
      --------	waitfor(me);
      !           ..
      !           ..
      !         activate the neigbouring philosophers (ready to eat)
      !           ..
      !           .. 
      ----------signalto(me);
                printf("phil %d has finished eating and asking other to eat" );

waitfor(i)
int i;
{
	if (i >= 1)   {  i--; }
	else
	  {  waitfor(i); } 
	return i;
}
signalto(i)
int i;
	{return i++;}
From: diamond@jit081.enet.dec.com (28-Aug-1992 1129)
Newsgroups: comp.std.c
Subject: Re: Implementation of semaphores in "c"
Date: 28 Aug 92 02:33:55 GMT

NOTICE TO NEW STUDENTS:  Newsgroup comp.std.c is for discussions of
standardization issues (e.g. ISO/ANSI C standard, maybe POSIX C standard,
whether various implementations conform, whether various programs are
strictly conforming, etc.).

In article <1992Aug27.114420.20501@cam.compserv.utas.edu.au> kleung@esk.compserv.utas.edu.au (Kam  Leung) writes:
>#include <stdio.h>
>#include <sys/types.h>

ISO C doesn't have <sys/types.h>

>#define N              6
>int  s[N], me;
>enum status {nthinking,vhungry,neating} ;
>enum status p[N];
>main()
>{
>  int i, ;

ISO C doesn't allow an empty declarator (after your comma).

>  void  PHILOSOPHER(),
>        think(), eat(), hungry();
>  me = 1;    /* initial open state of main semaphore */
>  for (i=1;i<N;i++) /*initialise 1-5 philosophers to thinking*/
>      { s[i] = 0; p[i] = nthinking;}  /* private semaphore s[i]=0,close*/
>  for (i=1; i<N; i++){
>       if (fork() == 0) PHILOSOPHER(i);

ISO C doesn't have fork().

>  }
>        ..
>        ..
>  kill(0,9);

ISO C doesn't have kill().

>}

If the above answers don't help you, then perhaps you need to ask the
tutors for your course.  If they can't help you, then perhaps you need
to post in a newsgroup concerning the UNIX operating system, to learn
why separate processes have separate data spaces.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
Newsgroups: comp.std.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: space optimization involving enum
Organization: TauMetric Corporation
Date: Wed, 26 Aug 1992 18:42:20 GMT

barmar@think.com (Barry Margolin) writes:

>Actually, doesn't the standard require that function
>declarations/prototypes and definitions be consistent with each other?  If
>the function is defined with an ANSI parameter list, the caller must have a
>prototype in scope.  If the function is defined with a K&R1 parameter list,
>the caller can use an old-style declaration (or no declaration at all,
>letting it default, if the function returns int).

Not quite.  You are allowed to mix prototype and non-prototype
declarations and definition of the same function, provided the
promotions implied by the non-prototype declaration/definition
do not result in any changes.  In practice, this means not using
any parameters of type char, short, or float.  If enums are smaller
than ints, avoid those too.

Conforming examples:

int foo(int, long, double); /* prototype */

foo(i, l, d) /* implicit int return and int type for 'i' */
long l;
double d;
{ ... }

int bar();	/* declaration */

int bar(int i, long l, double d) /* prototyped header */
{ ... }
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: diamond@jit081.enet.dec.com (28-Aug-1992 1244)
Newsgroups: comp.std.c
Subject: Re: <limits.h> and MB_LEN_MAX
Date: 28 Aug 92 03:47:31 GMT

In article <1992Aug27.165044.4781@ready.eng.ready.com> glenn@ready.com (Glenn Kasten) writes:
><limits.h> is supposed to define MB_LEN_MAX.  Is it permissible for a
>conforming implementation to define MB_LEN_MAX in terms of another
>type, where that other type is not declared in <limits.h>?  In other
>words, do header files have to be complete in themselves, or can they
>require other header files to also be included, in order to be usable?

Any program that has #include <limits.h> must get a definition of MB_LEN_MAX.
If the implementation makes <limits.h> a file, and if that file causes
inclusion of another file, and the result defines MB_LEN_MAX (and everything
else that it has to define), and the result does not intrude on the
application's namespace (e.g. not forcing a definition of stdin on a
program that didn't #include <stdio.h>, and not forcing other stuff on a
program), then there is no problem.

If it is possible to construct a valid program that has #include <limits.h>
and uses MB_LEN_MAX but doesn't get correct behavior out of the
implementation, then the implementation is not conforming.  If the
implementation does something like nesting #include <stdio.h> and defines
stuff that <limits.h> isn't supposed to, then it is not conforming.

As for what I mean by a "valid program," that essentially means that the
program conforms to every possible conforming implementation.  It might not
be strictly conforming because it might print out the value of MB_LEN_MAX,
but it is still entitled to obtain correct behavior.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."
Newsgroups: comp.std.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: How is struct assignment defined (idle query)?
Organization: SoftQuad Inc., Toronto, Canada
Date: Fri, 4 Sep 92 08:32:55 GMT

> Does ANSI say that structure assignment is done by member-wise copy or
> by bit-wise copying?

I think the standard is actually ambiguous.  There's no direct
discussion of this unless I've forgotten something, so we have to
see what it says about the meaning of structs.

Well, section 3.1.2.5 (ANSI numbering; 6.1.2.5 in ISO) says that a
struct is a "sequentially allocated nonempty set of member objects".
This should mean that its value is the ordered set of the values of
the members, and therefore that a member-wise copy is sufficient.

On the other hand, section 3.5.2.1 (6.5.2.1) says that "there may...
be unnamed padding within a structure object..."; *this* seems to
mean that the padding, as well as the members, is part of the struct
and has to be copied -- in other words, mandating bit-wise copying.

I see no reason to prefer one reading or the other.
-- 
Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, msb@sq.com
	"I'm a little worried about the bug-eater," she said.  "We're embedded
	in bugs, have you noticed?"		-- Niven, "The Integral Trees"

This article is in the public domain.
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.std.c
Subject: Re: Operations on Files
Keywords: ANSI C, files
Date: 3 Sep 92 12:10:40 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <robertl.4.715452734@county.lmt.mn.org>, robertl@county.lmt.mn.org (ROBERT LAUMEYER) writes:
> 
> 	The ANSI C standard seems to have a rather odd mix of file 
> operations.  Why didn't they add (over K&R) some other useful file 
> operations such as fileexist, getfirst, getnext, etc?  It seems that 
> these could not be much more dependent on the underlying file system than 
> rename or remove.

What are getfirst and getnext?  If they are the MS-DOS functions, don't
forget that
(a) wild-cards are very OS-dependent.  (Indeed, not all UNIX shells offer
    the same set of wild-cards.)
(b) When multiple threads may modify the file system (e.g. a multi-user
    system, or a file server accessed by many PCs), it is not altogether
    clear what getnext should do when the file system has _changed_ since
    the original call to getfirst.
(c) there are _other_ file system interfaces, such as the ftw() function,
    with at least as good a claim to standardisation.

Basically, if we had waited for a really good set of file system operations
we'd _still_ be waiting.

As for fileexist, what does that _mean_?  Does a file "exist" for you
if you are not permitted to inspect the directory containing its name?
Even if a file exists, if you are about to run out of file descriptors
or stream buffers you may not be able to open it.

A reasonably good workaround is

	int file_exists(const char *file_name)
	    {
		FILE *stream;
		stream = fopen(file_name, "rb");
		if (stream != NULL) fclose(stream);
		return stream != NULL;
	    }

This at least answers a useful question:  "would I be able to open this file?"
-- 
You can lie with statistics ... but not to a statistician.
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: int const * p;
Date: 2 Sep 92 15:09:25 EDT

linden@positive.Eng.Sun.COM (Peter van der Linden) writes:
>John omitted only the reference to the manual, namely 
>section 3.5.3 "Type Qualifiers".   It's not clear why a
>meaningful construct, like a constant pointer to a constant value
>is precluded.  

That construct isn't precluded;

	const int * const a;

is OK.  That declaration has two separate qualifier lists: one associated with
the type (int *) and one associated with the variable, essentially separated
by the *.
From: karl@ima.isc.com (Karl Heuer)
Newsgroups: comp.std.c
Subject: Re: How is struct assignment defined (idle query)?
Date: 3 Sep 92 20:45:38 GMT
Organization: Interactive Systems, Cambridge, MA 02138-5302

In article <715547606snx@grendel.demon.co.uk> jes@grendel.demon.co.uk (Jim Segrave) writes:
>Does ANSI say that structure assignment is done by member-wise copy or
>by bit-wise copying?

It's unspecified.  Either approach may be used by a conforming implementation;
a user cannot make any valid assumptions about the contents of "holes" after a
struct copy.

Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
Newsgroups: comp.std.c
From: mandayrv@ucunix.san.uc.edu (The Karate Kid)
Subject: FREOPEN/FOPEN
Followup-To: ramanand@pumpkin.ece.uc.edu
Keywords: Lex/Yacc, parsing multiple files.
Organization: University of Cincinnati
Distribution: usa
Date: Sat, 29 Aug 92 05:21:41 GMT

Hi folks,

I am not sure if this topic should come  in this newsgroup or in the
comp.compilers newsgroup. But this one looks more appropriate. So here goes.
Thanks to all the folks who respond.


I am trying to parse two different files using the lex/bison combo. I have
two different parsers created by two different parser specifications to
bison. Suppose I want the first parser to read from file A and the second
parser to read from file B.

I reassing stdin to file A by the command:
	
	freopen("A", "r", stdin);


The parser processes the file A and returns to the calling program. My
problems start after this. I am not able to figure out how to make the
second parser read from file B. The lexical analyzer is the same. I tried
the following command but it did not work:

	freopen("B", "r", stdin);


I even tried storing the return value of the first freopen call in a 
FILE pointer and passed it as the third argument to the second freopen call.
In both the cases, the lexical analyzer returns an EOF character as the next
read token.

Am I doing something fundamentally wrong (which is quite possible since I am
not at all comfortabl dealing with streams, specially figuring out the
difference between a STREAM and a FILE);


Thanks in advance


ramanand@pumpkin.ece.uc.edu

-- 
  mandayrv@ucunix.san.uc.edu
From: diamond@jit081.enet.dec.com (03-Sep-1992 1325)
Newsgroups: comp.std.c
Subject: Re: strcpy implementation question
Date: 3 Sep 92 04:26:37 GMT

In article <PINKAS.92Sep2173635@skywalker.intel.com> pinkas@skywalker.intel.com (Israel Pinkas) writes:
>My understanding is that a routine is only allowed to have undocumented
>side effects if they will have no effect on the execution of the program.

Sounds fair to me.

>In my book, if evaluating 1+2 launches missles, it would be OK as long as
>(1) the missles did not destroy the currently executing computer, and (2)
>the lack of a missle in the launch bay did not cause the program to abort:)

(1) isn't allowed to affect any other output of the program either  :-)

>The question still boils down to this:
>Can the compiler consider the memory past the destination of a copy as
>scratch memory, or does strcpy GUARANTEE only to modify the memory that is
>necessary for copying the string?

How many times do you have to be told?  John Levine posted an example where
the proposed side effect would cause an illegal difference.

For another example, the expression x+y is supposed to add two variables
(if they have addable types) and is not supposed to zero out every other
variable in the program.

If you would like an interpretation ruling to say "Operations that are
defined by the standard shall not have other arbitrary side effects"
then write to the committee requesting one.  If your employer decides to
make the request as an official corporate concern, then it will probably
even get the ruling (I personally think) rather than being laughed off.

[Regarding someone's faulty example of a variable length structure hack]
>I don't know of a single compiler that guarantees to place two static
>variables which are declared in the same file next to each other.

Yeah, that example was faulty.  I think you know how to construct a good one.

>The variable length struct is a hack.  There is nothing in the language
>that prevents the compiler from performing bounds checking on accesses to
>name.

Uh, nothing except the standard's definitions of [], unary *, and binary +
operators.  :-R rhetoric.
Bounds checking is not allowed to affect output of a valid but ugly program.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."
From: diamond@jit081.enet.dec.com (31-Aug-1992 1441)
Newsgroups: comp.std.c
Subject: Re: void expressions and volatile types
Date: 31 Aug 92 05:42:23 GMT

In article <BtnI48.D9I@twwells.com> bill@twwells.com (T. William Wells) writes:
>The problem is then what to do with statements like a; and a=b;
>when a is a volatile object. The first expression accesses a but
>then discards the value, which is fine.

What constitutes an access is implementation-defined.  A legal but ugly
definition could allow STORING the value of a (redundantly) when the value
is known from some other recent access.

>The other does NOT do what you'd expect, though.

Who's "you"?  I'd read the implementation's definition in order to see what
to expect.  If I don't like it, I wouldn't buy it.  If I do like it, but
the actual behavior doesn't match the documentation, I'd demand a refund.

>The reason is that the assignment has a
>value which is the value of a after the assignment, which can only
>be obtained by accessing a. Thus a=b results in a sequence like:
>       load b
>       store a
>       load a
>rather than the intended load and store.

Legal, but (in my personal opinion) ugly.  What does the documentation say?
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."
From: hendrik@vedge.UUCP (Hendrik Boom)
Newsgroups: comp.std.c
Subject: Re: <limits.h> and MB_LEN_MAX
Date: 28 Aug 92 16:14:24 GMT
Organization: Visual Edge Software, St. Laurent, Quebec

glenn@ready.com (Glenn Kasten) writes:

: <limits.h> is supposed to define MB_LEN_MAX.  Is it permissible for a
: conforming implementation to define MB_LEN_MAX in terms of another
: type, where that other type is not declared in <limits.h>?  In other
: words, do header files have to be complete in themselves, or can they
: require other header files to also be included, in order to be
: usable?

It doesn't matter whether the include files even exist, as long as
the compiler understands

	#include <limits.h>

to define the proper symbols, without any further effort being
required of the programmer.  So you cannot require him to
include anything else.  It is perfectly OK for the limits.h file
(assuming the compiler doen't have it built in, and actually does
read an actual file of C code), to contain its own #includes to include
whatever it needs.

	hendrik
From: msb@sq.sq.com (Mark Brader)
Newsgroups: comp.std.c
Subject: Re: space optimization involving enum
Date: 29 Aug 92 23:21:55 GMT
Organization: SoftQuad Inc., Toronto, Canada

> > ... The representation of [decimal] 10000 has to use the bit
> > sequence 10011100010000.  
> 
> As I read it, wrong.  Nothing I see prevents use of 2's complement, 
> 1's complement, or excess-2**(n-1) (the sign bit being reversed from
> 2's complement).

These systems are indeed all permissible.  But they also all use the
bit sequence 10011100010000 in the representation of decimal 10000.
-- 
Mark Brader		"Wise wives welcome spring by moving the UNIX"
utzoo!sq!msb, msb@sq.com

This article is in the public domain.