HDTenEightyP/NetNews huggingface dataset:
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: strcmp() on a non-nil-terminated string
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Tue, 17 Nov 1992 00:30:44 GMT

In article <1992Nov16.162313.3334@Urmel.Informatik.RWTH-Aachen.DE> berg@physik.tu-muenchen.de (Stephen R. van den Berg) writes:
>#include <string.h>
>char first[]="first";
>char second[]={'s','e','c','o','n','d'};
[...]
>strcmp(first,second);
>
>Is this program allowed to behave undefined?

ANSI section 4.11.4, page 165 lines 5 to 7, say that the result depends on
the sign of the difference between the first pair of characters that differ.
This doesn't exactly say if the function can continue inspecting irrelevant
characters up to the end of each string.

Section 4.11.4.2 implies that it might inspect each entire string.  But the
implication is suspect -- because section 4.11.4.1 (memcmp) has similar
language for the "Returns" paragraph in lines 16 to 17, forgetting the
length limit in the "Description" paragraph in lines 13 to 14.

It might be wise to request an interpretation ruling.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"It's been a lovely recession."
Newsgroups: comp.std.c
From: kevin@traffic.den.mmc.com (Kevin Rodgers)
Subject: expression & discipline (was: Re: Casting const ...)
Organization: Martin Marietta Western Internal Systems, Technical Operations
Date: Wed, 18 Nov 1992 17:09:17 GMT

In article <18867@ksr.com> jfw@ksr.com (John F. Woods) writes:
>C doesn't have a means to express what you want.  You'll just have to
>discipline yourself instead of asking the compiler to do it for you.

This is the central tenet of C.
-- 
Kevin Rodgers				kevin@traffic.den.mmc.com
Martin Marietta MS A16401		(303) 790-3971
116 Inverness Dr. East
Englewood CO 80112 USA			GO BUFFS!
Newsgroups: comp.std.c
From: snm@cc.gatech.edu (Sathis Menon)
Subject: Where to get ANSI C standard
Reply-To: snm@cc.gatech.edu (Sathis Menon)
Organization: The Clouds Project, Georgia Tech
Date: Wed, 18 Nov 1992 17:34:35 GMT

Hi,


Is the ANSI C standard description available online (from an
ftp site somewhere)? If this is not in public domain, where can one
purchase a copy of the standard?

Thanks for any info -

Sathis Menon
--------
College of Computing, Georgia Institute of Technology, Atlanta Georgia, 30332
Internet: snm@cc.gatech.edu
~

Newsgroups: comp.std.c,comp.unix.questions
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Subject: Re: Idle Questions about ANSI C
Followup-To: comp.unix.questions
Keywords: password
Organization: McGill Research Centre for Intelligent Machines
Date: Wed, 18 Nov 92 10:49:56 GMT

In article <1992Nov17.234608.25085@guinness.idbsu.edu>, dstienek@gozer.idbsu.edu (Dan Stieneke) writes:

> How do I pipe stdout of one file to stdin of another file AFTER I
> have already exec'd the program and entered data from the keyb?

This is an operating-system question, not a C question, and most
certainly not a C standard question.

Under the assumption the OS in question is some variant of UNIX, I'm
cross-posting to comp.unix.questions and pointing followups there.

> specifically:  I want to be able to "data | ftp".  Everything works,
> except that passwords are not entered in the same way as everything
> else.  All commands go thru except for the password.

It's not clear to me that the question you first asked bears any
relation what you "specifically" want to do.  What your question sounds
as though you want to do is precisely what you describe your attempted
pipeline as doing, so I don't see the problem.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
Newsgroups: comp.std.c
From: lwv26@cas.org (Larry W. Virden)
Subject: Looking for softcopy reference for where one should expect to find prototypes of OS
Reply-To: lvirden@cas.org (Larry W. Virden)
Organization: Nedriv Software and Shoe Shiners, Uninc.
Date: Tue, 24 Nov 1992 03:34:06 GMT


I am working on cleaning up some C code.  I am adding unistd.h and stdlib.h
includes where necessary, etc.  But there are still a number of OS system
calls and functions which are not appearing in the headers on either Ultrix
4.2 , SunOS 4.1.2 or gcc 2.2.2.  I assume they are SUPPOSED to be somewhere - 
but just where I haven't determined.

For instance, the system() function or the tolower() function.  Or the creat()
system call.  These are just some of the examples I have encountered.
-- 
Larry W. Virden                 UUCP: osu-cis!chemabs!lvirden
Same Mbox: BITNET: lvirden@cas  INET: lvirden@cas.org
Personal: 674 Falls Place,   Reynoldsburg, OH 43068-1614
Newsgroups: comp.std.c
From: jss@lucid.com (Jerry Schwarz)
Subject: malloc(0)
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Sat, 21 Nov 92 00:52:07 GMT

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).  However I have just been talking to
some people who insist it means that the same pointer is returned
on each call of malloc(0).

Comments?

  -- Jerry Schwarz


	
Newsgroups: comp.std.c
From: berg@physik.tu-muenchen.de (Stephen R. van den Berg)
Subject: strcmp() on a non-nil-terminated string
Originator: berg@tabaqui
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
Date: Mon, 16 Nov 92 16:23:13 GMT

Suppose I have the following program:

--------------------------------------
#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?  If so, can anyone imagine
provide an example when this might happen?

You would expect a sane implementation to return with an exitcode of 1.
-- 
Sincerely,                                  berg@pool.informatik.rwth-aachen.de
           Stephen R. van den Berg (AKA BuGless).    berg@physik.tu-muenchen.de

"Be spontaneous!"
Newsgroups: comp.std.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: Casting const; Is this standard conforming?
Organization: TauMetric Corporation
Date: Tue, 17 Nov 1992 18:30:27 GMT

rhl@grendel.Princeton.EDU (Robert Lupton the Good) writes:


>   const int i = 0;
>
>   (int)i = 1;				/* Fails */
>   *(int *)&i = 1;			/* OK */
       
>Thinking about ROMs my guess is that gcc and the IBM xlc compilers are
>correct to reject the former assignment, and that their acceptance of
>the latter is permitted, but could anyone comment? 

The first assignment is illegal because a cast yields a value, not
an lvalue, and you may not assign to a value.  It has nothing to do
with const.

The second assignment assigns to an object via a modifiable lvalue, and
so violates no constraint.  Nonetheless, the results of assigning to an
object declared const via a non-const lvalue are undefined.  (ANSI 3.5.3)

You can't rely on any particular result.  The compiler is not obliged
to diagnose the problem, but may do so.  The resulting code might do
what you intended, but need not.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.std.c
Subject: Re: malloc(0)
Date: 21 Nov 92 16:20:34 GMT
Organization: AND Software BV Rotterdam

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).  However I have just been talking to
|some people who insist it means that the same pointer is returned
|on each call of malloc(0).
|
|Comments?

Quite an interesting question ... the answer all depends on the meaning
of the word `unique'. Consider the following snippet of code:

char *p, *q;

p= malloc(n);
q= malloc(n);

if (p == q) /* etc */

The condition always fails if malloc succeeds. If malloc(0) returns
a non NULL value (i.e. it doesn't fail) it should return a unique
pointer value every time it is invoked as malloc(0). On the other
hand, suppose malloc(0) returns NULL. The test would (obviously)
succeed. Because we don't want to break the code, when porting it
from a non-NULL returning implementation to a NULL returning imple-
mentation, this tends me to believe that malloc(0) should return the
same value over and over again, but that value must be different
from any other malloc(n) call, where n is non zero. But on the 
other hand, this would violate the constraint that the pointer
values `shall be unique.' The ISO standard doesn't have a rationale
included, so I can't say much more about this ...

kind regards,

Jos aka jos@and.nl
Newsgroups: comp.std.c
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Subject: Re: fwrite+fread of pointer
Organization: McGill Research Centre for Intelligent Machines
Date: Wed, 18 Nov 92 10:45:42 GMT

In article <15977@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> In article <1992Nov13.184421.11065@taumet.com>, steve@taumet.com (Steve Clamage) writes:

>> "Data read in from a binary stream shall compare equal to the data
>> that were earlier written out to the stream, [...]."
> That is exactly the kind of answer I hoped for when I posted to
> comp.std.c.  Thank you.  There remains, alas, one fine point of
> detail.  What does it _mean_ to say "COMPARE EQUAL to the data ..."?

Let's see if I can bring this into sharper relief by eliminating the
file.  Since I think we now agree that a block of bytes written out and
read back must produce a block of bytes with identical bits in them....

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.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: dbbergac@sanluis (Dave Bergacker)
Newsgroups: comp.std.c
Subject: Correction to Return value from....
Date: 24 Nov 1992 00:13:25 GMT
Organization: University of Colorado at Colorado Springs
NNTP-Posting-Host: sanluis.uccs.edu
X-Newsreader: TIN [version 1.1 PL6]


In the provious article, I had char *s1 = "mom", *s2 = "dad";
the interesting case is not this one but
char *s1 = "mom", *s2 = "mob", as the first case doesn't
generate a recursive call.  I probably also forgot a return
or exit at the end of main.  Sorry for not expressing the 
problem better the 1st time.
--
Thanks,
	Dave Bergacker
The opinions expressed are not those of UCCS, nor should they be.
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: Casting const; Is this standard conforming?
Date: 17 Nov 92 17:53:43 GMT
Article-I.D.: ksr.18867

rhl@grendel.Princeton.EDU (Robert Lupton the Good) writes:
>I've never used const modifiers, so I assumed that this would be OK,
>#include <stdio.h>
>int
>main()
>{
>   const int i = 0;
>   (int)i = 1;				/* Fails */

This is a syntax error.  "Lvalue casts" (a mistake so common they have a name)
have always been forbidden by the language (contrary to the opinion of some
compilers).

>   *(int *)&i = 1;			/* OK */
>	    
>   return(0);
>}
>	       
>Thinking about ROMs my guess is that gcc and the IBM xlc compilers are
>correct to reject the former assignment, and that their acceptance of
>the latter is permitted, but could anyone comment? 

The second is not a syntax error, nor does it violate a Constraint, so no
diagnostic is required.  The behavior, however, is explictly undefined
according to the Semantics section of 3.5.3 Type Qualifiers:  "If an attempt
is made to modify an object with a const-qualified type through the use of an
lvalue with non-const-qualified type, the behavior is undefined."

>What do you think about the portability of the cast?

If the hardware permitted it, the compiler would be perfectly at liberty to
use genuine read-only storage for that variable (perhaps it could allocate
a whole stack page for "i" and mark it as read-only in the MMU).

What you probably want is for the module that *defines* this variable to be in
a file by itself, with the declaration of the variable lacking the const
qualifier; every module that simply declares it with "extern" would include
the "const" qualifier.  Unfortunately, that ALSO is illegal, since the types
"const <type>" and "<type>" are not compatible types, and all declarations
referring to the same object must have compatible type.  However, this
particular transgression at least *sounds* sensible enough that you might be
able to sweet-talk your compiler vendor(s) into letting it work anyway.

C doesn't have a means to express what you want.  You'll just have to
discipline yourself instead of asking the compiler to do it for you.
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: idle query on strtok()
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Fri, 20 Nov 1992 01:28:56 GMT

In article <722063993snx@grendel.demon.co.uk> jes@grendel.demon.co.uk (Jim Segrave) writes:
>Is strtok()'s behaviour defined for tokens already taken from a string?

strtok() only steps on separators, so the tokens remain unchanged.

>    char zoe[] = "aaa bbb";
>    char *first, *second;
>    first = strtok (zoe, " "); 
>    second = strtok (NULL, " ");
>    printf ("%s\n%s\n", first, second);
>I expect the output:
>    aaa
>    bbb

Perfect example.

>Can I *portably* change the contents of a token returned by strtok
>without affecting the behaviour of subsequent calls?
>    strcpy (first, "!!!");		/* corrupt the first bit */
>    second = strtok (NULL, " ");
>    printf ("%s\n", second);

Yes.  strtok() is defined as keeping a pointer internally to the remaining
portion of the string, from which its next search will continue.  The
second result will still be bbb.

>What if I change the 'corrupt ...' line to
>    memset (first, 0, strlen (first) + 1);

No change.  The first call to strtok() already set *(first + strlen (first))
to 0, so you're just setting it to 0 again, as well as zeroing the token.

>Does strtok() promise that the tokens delivered will be untouched
>by subsequent calls to strtok()?

Not explicitly, but still yes.  Library functions are defined (ideally
anyway, since some aren't defined very clearly :-) to have certain effects
on valid arguments, and are not allowed to go stepping on other parts of
the program or have other random behavior unless you pass invalid arguments
or you have otherwise violated the conditions.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"It's been a lovely recession."
Newsgroups: comp.std.c
From: dstienek@gozer.idbsu.edu (Dan Stieneke)
Subject: Re: Idle Questions about ANSI C
Keywords: password 
Organization: Boise State University
Date: Tue, 17 Nov 1992 23:46:08 GMT


How do I pipe stdout of one file to stdin of another file AFTER
I have already exec'd the program and entered data from the keyb?

specifically:  I want to be able to "data | ftp".  Everything works, except
that passwords are not entered in the same way as everything else.  All 
commands go thru except for the password.  Would pipe() do it?  If so, how so?

thanks
dstienek@gozer.idbsu.edu

(please forgive me posting this as a follow-up article instead of a new one.  I
rarely post, and "?" and "h" don't show how to [I discovered "F" by accident])
Newsgroups: comp.std.c
From: drd@siia.mv.com (David Dick)
Subject: Re: POSIX means *Binary* Compatibility ! NOT !
Organization: Software Innovations, Inc.
Date: Sat, 21 Nov 92 17:15:30 GMT

In <rob.722278425@hp11> rob@hp11 (Rob Freyder) writes:

>8-)

>Hi,

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

Why is anyone paying this consultant?  When "experts" like this can
get customers to listen to them, it's no wonder the industry is so
confused.

David Dick
Software Innovations, Inc. 
[the Software Moving Company; converting software to UNIX for a decade]

Newsgroups: comp.std.c
From: richard@crowded-house.den.mmc.com (Richard Armstrong)
Subject: Memory Usage by C
Organization: Martin Marietta
Date: Thu, 19 Nov 1992 19:05:26 GMT

From news.den.mmc.com!crowded-house!richard Thu Nov 19 12:03:52 MST 1992
Article: 20542 of comp.lang.c
Newsgroups: comp.lang.c
From: richard@crowded-house.den.mmc.com (Richard Armstrong)
Subject: Re: Where are literals stored?
Organization: Martin Marietta
Date: Thu, 19 Nov 1992 18:57:12 GMT

In article <1992Nov18.233739.2335@den.mmc.com> richard@crowded-house.den.mmc.com (Richard Armstrong) writes:
>Are literals always stored in the same location in memory? (IBM-PC,Borland)
>
>For instance, is the string a stored in the same place in the following
>two declarations?:
>
>static char *a[]="ABC"
>funca()
>{
>}
>
>funca()
>{
>char *a[]="ABC";
>}
>

The lack of response on this issue has prompted me to supply more information.

We have an application that is running out of heap and stack space.  We are
trying to figure out if the above declarations store the literal strings in
the same place, and if that is the case, we will not bother changing the way
we declare these strings.  If anyone has any suggestions on moving memory
around so that heap and stack are not compromised, then please let me know.

The current environment is Borland C++ on PC's.  We can also use Microsoft C++
7.0.

Thanks in advance.



-- 
My company never said any of this... I didn't either.
Richard Armstrong, Software Engineer, Martin Marietta
Email->>>> richard@crowded-house.den.mmc.com <<<<-Email 



-- 
My company never said any of this... I didn't either.
Richard Armstrong, Software Engineer, Martin Marietta
Email->>>> richard@crowded-house.den.mmc.com <<<<-Email 

Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: Memory Usage by C
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Fri, 20 Nov 1992 02:09:50 GMT

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.
In some implementations they might go in the same location; in other
implementations they might not.  (It is not clear if partly identical string
literals that could meaningfully overlap are also allowed to do so or not.)

>(IBM-PC,Borland)

Ask Borland.  (The standard does not require them to answer; it doesn't
say that this decision is implementation-defined.  But you can always ask.)

>For instance, is the string a stored in the same place in the following
>two declarations?:
>static char *a[]="ABC";
>funca()
>{
>char *a[]="ABC";
>}

You cannot have two functions named funca() in the same source file, so
I deleted the first one (which had nothing between the braces).  I also
added a semicolon to the end of the first line.

In the first declaration, a is a static array.  When the declaration is
completed, the array size is determined to be 1.  a[0] is a pointer-to-char,
initially pointing to the first character in an array of 4 characters (A, B,
C, and null character).  This nameless array of 4 characters is static.

In the later declaration, a is an automatic array.  This a cannot go in the
same place as the first a, the static array.  This a[0] might initially
point to the same static array of 4 characters that the first a[0] pointed
to, or else to a different static array of 4 characters.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"It's been a lovely recession."
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: malloc(0)
Date: 23 Nov 92 11:19:21 EST

jos@and.nl (Jos Horsmeier) 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).  However I have just been talking to
>|some people who insist it means that the same pointer is returned
>|on each call of malloc(0).
>Quite an interesting question ... the answer all depends on the meaning
>of the word `unique'.

Two sentences earlier, the same paragraph says "Each such allocation shall
yield a pointer to an object disjoint from any other object."  malloc() et
al always returns an object; each call results in an object disjoint from
any other object; malloc(0) is therefore entitled to return either NULL
or "an object disjoint from any other object".  Therefore,  malloc(0) may
*not* keep returning pointers to the same dedicated zero-size "object"
(unless, of course, that malloc()ed pointer is freed immediately each time).

Sometimes, you have to read more than one sentence to understand the C
standard.
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.std.c
Subject: Re: malloc(0)
Date: 22 Nov 92 16:54:09 GMT

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?
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com  or  ...uunet!sdrc!larry.jones
It's no fun to play games with a poor sport. -- Calvin
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: malloc(0)
Date: 23 Nov 92 11:24:55 EST

jos@and.nl (Jos Horsmeier) writes:
>In article <2305@sdrc.COM> scjones@thor.sdrc.com (Larry Jones) writes:
>|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");

I would certainly hope it would brake code like that.  Putting a stop to
code like that is valuable.  :-)

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

Anyone who tests for whether or not malloc(0) returned NULL by testing
whether or not the new malloc(0) returned the same as a previous malloc(0)
deserves to have their programming career braked, too.

[For the non-native English speakers in the audience, in between the valid
technical points here I am having fun with Jos' misspelling of "break" (to
damage or destroy) as "brake" (to slow or stop).]