HDTenEightyP/NetNews huggingface dataset:
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.std.c
Subject: Re: Macro replacement
Date: 25 Jan 93 23:48:43 GMT

In article <1993Jan22.121437.10384@csqx.cs.rhbnc.ac.uk>, andreww@cscx.cs.rhbnc.ac.uk (Andrew Waters) writes:
> The example given in the standard (section 3.8.3.5) makes use of an ambiguity
> pointed out in the rational.

No, it doesn't.

> #define x	2
> #define f(a)	f(x * (a))
> #define g	f
> #define	t(a)	a
> 
> t(t(g)(0))
> 
> 1.  Examine the string and find the outermost macro name "t"
> 2.  Search for the argument "t(g)(0)"
> 3.  Expand the arguments - finding the inner macro name "t"
> 4.  Search for the argument "g"
> 5.  Expand the arguments - finding the macro name "g" which expands to "f"
> 6.  Rescan the replacement list of "g"  i.e. rescan "f".  There is a macro f
>     but it requires an open parenthesis which we do not have therefore we cannot
>     expand any further.

Correct so far, but note that f is *not* a nested instance of a macro
being replaced, so it is *not* marked as unavailable for further expansion.

> 7.  Rescan the replacement list of innermost "t" i.e. rescan "f".  This has
>     already been expanded fully.
> 8.  Rescan the replacement list of outermost "t" i.e. rescan "f(0)".  Now what
>     happens.  Clearly there is a macro call however "f" is a macro name which
>     has not been replaced and therefore is not available for further replacement.

But, as I noted above, it has not been marked unavailable, so it *is*
expanded, leading to the "f(2 * (0))" result shown in the example in
the standard.  The example given in the Rationale is quite different:

#define f(a)  a * g
#define g(a)  f(a)

f(2)(9)

1.  Examine the string and find the macro name "f" followed by "("
2.  Identify the argument "2"
3.  Expand the arguments - nothing to do
4.  Substitute arguments into replacement list "2 * g"
5.  Rescan the replacement list with the rest of the source file
6.  Find the macro name "g" followed by "("
7.  Identify the argument "9"
8.  Expand the arguments - again, nothing to do
9.  Substitute arguments into replacement list "f(9)"
10. Rescan the replacement list with the rest of the source file
11. Find the macro name "f" followed by "("

This is the ambiguity: is "f" at this point a nested replacement?

Since this "f" came from the expansion of "g" which in turn came from
the expansion of "f", you can certainly argue that it is and thus it
should not be replaced and it should be marked unavailable for further
replacement.  On the other hand, you can argue that as soon as you went
past the end of "g"'s expansion into the rest of the source file you are
no longer expanding "g" or "f" and thus this "f" is *not* a nested
replacement and should be replaced normally.  The Standard does not take
sides in this argument; either result is acceptable.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com
I always send Grandma a thank-you note right away.  ...Ever since she
sent me that empty box with the sarcastic note saying she was just
checking to see if the Postal Service was still working. -- Calvin
From: uttamchandan@sask.usask.ca
Newsgroups: comp.std.c
Subject: TMS320C25 AND C
Date: 26 Jan 93 22:53:28 GMT
Organization: University of Saskatchewan
NNTP-Posting-Host: sask.usask.ca

I NEED HELP WITH READING AND WRITTING FROM/TO MEMORY.

I WNAT TO READ DATA FROM A FILE AND WRITE TO MEMORY ADDRESS SAY 
BASE_IN=7000.. THEN READ IT .. PROCESS IT... THEN WRITE TO MEMEORY
AT BASE_OUT=10000... I WOULD NEED POINTERS.. 
SO SOME ONE PLEASE LET ME KNOW..

PC BASED TMS320C25 DSP CHIP..    CROSS COMPLING WITH C AND ASM LANG.
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: offsetof in case labels
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Mon, 25 Jan 1993 02:24:44 GMT

In article <542@heimdall.sdrc.com> scjones@thor.sdrc.com (Larry Jones) writes:
>[...] an otherwise strictly conforming program that uses
>offsetof in a strictly conforming fashion is still strictly conforming
>reguardless of the expansion of the macro.  The RFI, suspecting this to
>be the committee's response, goes on to point out that this *requires*
>an implementation to implement an extension of some sort in order to
>implement offsetof and argues that this is inappropriate.  While this is
>the most common method of implementing offsetof (generally by extending
>the implementation's definition of constant expression, which the
>standard allows, or by adding a new keyword), it is not, strictly
>speaking, necessary.  All that is required is an omniscient preprocessor
>that can expand offsetof to the correct integer constant -- not a
>difficult task if the preprocessor is an integral part of the compiler
>with access to the symbol table.

!

That is true, but suggests a previously unexposed bit of hypocrisy.
The reason why sizeof isn't an operator at preprocessing time, and the
reason why limits on integral expressions at preprocessing time do not
have to match limits at later phases (including execution on the target
machine) is that it is supposed to be possible to write non-omniscient,
non-integrated generic preprocessors, right?  I think that everyone who
can read (who can read the standard) will agree that implementations have
a burden to meet the definition of offsetof.  However, there no longer
appears to be any rationale for the decisions on sizeof and limits.

>Those who care should obtain the collected Requests
>for Interpretation and Responses which ANSI should be publishing as a
>Technical Information Bulletin real soon now.)

Ah!  Please post ordering instructions when that becomes available.

>[...] it's actually quite readable for a language standard;

True, but...

>a bit more difficult than K&R Appendix A, perhaps, but not significantly so.

A bit less ambiguous than K&R Appendix A, perhaps, but not significantly so.
--
Norman Diamond                diamond@jit.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
Pardon me?  Or do I have to commit a crime first?
From: volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe)
Newsgroups: comp.std.c
Subject: Re: Libraries specified in source?
Date: 25 Jan 93 15:24:32 GMT
Reply-To: volpe@ausable.crd.ge.com
Organization: GE Corporate Research & Development

In article <1993Jan23.194202.20332@druid.uucp>, darcy@druid.uucp (D'Arcy J.M. Cain) writes:
|> ray@astro.ocis.temple.edu (Ray Lauff) writes:
|> >line of the compiler call.  Of course, using make files can
|> >simplify the process, but why not just have a line in the 
|> >main program such as
|> >
|> >#library "/lib/libc.a"

I like the idea, though I wouldn't include path names for standard stuff.
Rather, I would mimic the semantics for #include directives.

For example, we don't say 
  #include "/usr/include/math.h"
but rather
  #include <math.h>

Similarly, I would prefer to see something like:
  #include <libm.a>

to get the math library.

|> 
|> Two problems I can think of right off.  How do you know that the
|> function you want is in that library on every system and how do
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That's kind of like asking, in reference to <math.h>, "How do you know
that the prototype for cos() is in that header file on every system?".
The answer is you ammend the Standard with information about what libraries
things are in. And in doing so for standard libraries, you open the doors
for things like:
  #library "userlib.a"

|> you know that the libraries reside in that directory?
                                      ^^^^^^^^^^^^^^^^^
Agreed, which is why I suggested nuking the pathname for would-be
"standard" libraries, the same way as is done for standard header files.

-Chris

-- 
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
From: mikey@ontek.com (euphausia superba)
Newsgroups: comp.std.c
Subject: Re: Libraries specified in source?
Date: 26 Jan 93 18:50:57 GMT
Organization: Ontek Corporation -- Laguna Hills, California

In comp.std.c, ray@astro.ocis.temple.edu (Ray Lauff) writes:
| 
| #library "/lib/libc.a"

Upon seeing

  #include <math.h>

in the program the compiler has enough information to realize that it
might be a good idea to add -lm to the link phase.  Failing that, it
should be simple to use makedepend(1) to get a list of all include
files your program uses and look up in a database what libraries are
needed.  Add a bit more info to the database to establish the ordering
of libraries on the command line and there ya go.  I agree, it would be
a nifty feature to have built into a compiler, but I see no need to add
another preprocessor directive to accomplish the task.

Another approach: the machine I use has about 40 or so libraries all in
all; I could simply mention all of them on the command line and the linker 
would "do the right thing," slowly though.

      the krill
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.std.c
Subject: Re: Is this allowed in C?
Date: 25 Jan 93 15:29:16 GMT

In article <1993Jan25.020122.22998@nntpd.lkg.dec.com>, diamond@jit345.bad.jit.dec.com (Norman Diamond) writes:
> The C standard guarantees that whenever malloc() succeeds, the value will
> point to storage suitably aligned for everything, ....

...that is no larger than the amount of space allocated.  Strictly
speaking, if you only allocate 1 byte, the returned pointer need not
be suitably aligned for types that are larger than 1 byte (e.g. int
or double), since you can't store them there.  Some implementations
may take advantage of this to minimize the amount of wasted space,
but most do not.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com
This game lends itself to certain abuses. -- Calvin
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: Structure walking
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Wed, 27 Jan 1993 01:32:05 GMT

In article <C1GHJy.GJp@x.co.uk> clive@x.co.uk (Clive Feather) writes:
>In article <1993Jan26.013634.20451@nntpd.lkg.dec.com> diamond@jit.dec.com (Norman Diamond) writes:
>>In article <1993Jan25.213543.25499@pony.Ingres.COM> mikes@Ingres.COM (Mike Schilling) writes:
>>>(a) Each scalar type has an unambiguous alignment requirement.

>>For all existing C compilers?  Probably.  For all hypothetical standard
>>conforming compilers?  Uncertain.  Actually it is imaginable, for a
>>hypothetical but really meaningful compiler, if space is virtually free
>>but speed is extremely expensive, one might want to align a 4-byte integer
>>in the second half of an 8-byte cache line in order to save time by only
>>filling half of a cache line.  I don't know if you'd call this unambiguous.

>ISO 3.1 defines alignment as the requirement for objects of a given type
>to have addresses that are multiples of some number.

You're right!  So does ANSI Classic 1.6.  There goes that possible
optimization.

>There are no
>requirements for alignment that I can find, except that 6.5.2.1 requires
>the alignment of structure members to be defined by the implementation.

That is indeed the (mostly) relevant section, since the original question
was asking about structure members.  The implementation can choose an
arbitrarily obscure alignment technique, as long as it documents it.
However, I don't know if that makes it "unambiguous".
--
Norman Diamond                diamond@jit.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
Pardon me?  Or do I have to commit a crime first?
Newsgroups: comp.std.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: binary data with stdin/stdout
Organization: TauMetric Corporation
Date: Thu, 28 Jan 1993 18:57:05 GMT

ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes:

>Does the standard have anything to say about wether stdin and stdout
>are opened to a file stream opened in binary mode?

Yes.  In section 4.9.3 it says that the predefined standard streams
are text streams.

I suppose an implementation could provide an option where the files
were opened in binary mode.  Code which depended on this would not
be portable.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.std.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: Structure walking
Organization: SoftQuad Inc., Toronto, Canada
Date: Thu, 28 Jan 93 02:59:39 GMT

> > (d) The offset of the (n+1)th member of a structure is the offset of
> >     the nth member of the structure, plus the size of the nth member,
> >     rounded up to the alignment requirement of the type of the (n+1)th
> >     member.
 
> False.  ANSI 3.5.2.1 (emphasis mine):
> 	Each non-bit-field member of a structure or union object is aligned
> 	in an implementation-defined manner *appropriate* to its type.
>
> Note that it says "appropriate to", not "required by".  An
> implementation has a great deal of latitude in how it aligns members.

I disagree with "False".  I think this one is "Unknown, until there is an
interpretation ruling".  3.5.2.1 also says:

	There may ... be unnamed padding within a structure object ...
	as *necessary* to achieve the appropriate alignment.

It isn't clear to be whether this means the alleged implementation-defined
alignment referred to in the last quoted message, or simply the alignment
requirement appropriate to the type of the member.  If it is the latter
case, then the other passage is merely a complicated way of saying "in
the manner appropriate to its type, which (as you know) is implementation-
defined".  And the answer to (d) hinges on this point.

Of course, if it's critical, prudence requires you to assume False.


> > (e) The alignment required by the structure is equal to the most
> >     restrictive alignment of any of its members.
> 
> True, but see (a).

I say False!  It's at least as restrictive, but it could be more restrictive.
If you believe otherwise, please cite chapter and verse.


> > (f) The size of the structure is the offset of the last member of the
> >     structure, plus the size of the last member, rounded up to alignment
> >     required by the structure.
> 
> False.  ANSI 3.5.2.1 again:
> 	There may also be unnamed padding at the end of a structure or
> 	union, as necessary to achieve the *appropriate* alignment were
> 	the structure or union to be an element of an array.
> Again, it says "appropriate", not "required".

But that padding yields the "alignment required by the structure"!  So this
is True, unless I'm misunderstanding the question.


> It is generally reguarded as true that the Standard contains sufficient
> requirements scattered about its various sections to require that all
> structure pointers have the same representation.

I have no reason to disbelieve this, but I've never seen the proof outlined,
and it would be interesting to see it.  It would also be interesting to see
if someone disbelieves the proof when it *is* presented -- just as there are
people who disbelieve the standard proof that the struct hack is strictly
conforming, which also draws on "requirements scattered about ... various
sections" of the standard.

-- 
Mark Brader		 "Sir, your composure baffles me.  A single counter-
SoftQuad Inc.		  example refutes a conjecture as effectively as ten.
Toronto			  ... Hands up!  You have to surrender."
utzoo!sq!msb, msb@sq.com				 -- Imre Lakatos

This article is in the public domain.
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: const qualifier
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Thu, 28 Jan 1993 11:36:56 GMT

In article <1993Jan28.073947.6951@g2syd.genasys.com.au> andrewc@g2syd.genasys.com.au (Andrew Congdon) writes:
>I have a function which takes a parameter that is a 2 dimensional array
>which it will never modify.  [...]  Except for [one] ANSI C compiler, all
>the ANSI C compilers here complain about the following:
>	extern void fn(const float colours[][3]);
>	static float colours[][3] = { { 1.0, 0.0, 0.0 } };
>	fn2(void) {
>		fn(colours);
>	}
>The complaint is the parameter in the call to fn() does not match the
>prototype.

3.7.1, page 83 lines 23 to 24:  "A declaration of a parameter as 'array of
type' shall be adjusted to 'pointer to type', [...]".

The parameter declaration says array (unknown size) of array (size 3) of
const float.  It is adjusted to be pointer to array (size 3) of const float.

3.3.2.2, page 41 lines 21 to 23 (a Constraint):  "Each argument shall have
a type such that its value may be assigned to an object with the unqualified
version of the type of its corresponding parameter."  Now the unqualified
version of a type only deletes the top level of qualification (if the top
level was qualified).  For example, the unqualified version of const pointer
to const is still pointer to const.

Thus the unqualified version of the parameter is still pointer to array
(size 3) of const float.

The identifier in the argument in the call has type array (size 1) of array
(size 3) of float, and gets converted to be pointer to array (size 3) of float.

3.3.16.1, pages 53 to 54, specifies what may be assigned to what.  This
assignment is not permitted.  The closest possibility would be pointers
to qualified or unqualified versions of compatible types (with a further
condition that is moot here), but array of const is not compatible with
array of non-const.

Thus the constraint in 3.3.2.2 is violated.

This proves that one of your purported ANSI C implementations is not a
genuine ANSI C implementation (if you invoked it as directed by the vendor).

>The compilers seem much happier if the call is changed to:
>		fn((const float (*)[3])colours);

The cast specification says pointer to array (size 3) of const float.
This type matches the parameter's type.

>[Another implementation's] complaint is at least amusing:
>const.c:9:  error:  In this statement, the referenced type of the
>pointer value "colours" is "array [3] of float", which is not compatible
>with "array [3] of float".

The standard requires a diagnostic for the program, but not that the
diagnostic be accurate or meaningful.  Only market forces can do that.
--
Norman Diamond                diamond@jit.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
Pardon me?  Or do I have to commit a crime first?
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: Structure walking
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Wed, 27 Jan 1993 01:46:43 GMT

In article <565@heimdall.sdrc.com> scjones@thor.sdrc.com (Larry Jones) writes:
>In article <1993Jan25.213543.25499@pony.Ingres.COM>, mikes@Ingres.COM (Mike Schilling) writes:
>> (e) The alignment required by the structure is equal to the most restrictive
>>     alignment of any of its members.

>True, but see (a).

Well Mr. Jones, you and I seem to be the only people who feel this way.
Most of the regulars in this group felt that even a structure like this:
   struct mychar { char x; }
might be given an alignment requirement of 32 by some compiler, even if
char only requires an alignment of 1 under the same compiler.  Of course,
I only saw this on Usenet; you've seen the committee's deliberations.

>> (f) The size of the structure is the offset of the last member of the structure,
>>     plus the size of the last member, rounded up to alignment required
>>     by the structure.

>False.  ANSI 3.5.2.1 again:
>	There may also be unnamed padding at the end of a structure or
>	union, as necessary to achieve the *appropriate* alignment were
>	the structure or union to be an element of an array.
>Again, it says "appropriate", not "required".

Now I don't understand.  Strictly speaking, the alignment of each member
was already a matter of appropriateness rather than requirement, because
no alignment is really required.  It is always possible to bit-align a
float but do lots of byte moves and integral shifts to move the float into
a temporary location properly aligned for a hardware operation.

So, an appropriate alignment for a structure is equal to the most
restrictive appropriate alignment of any of its members, right?
Then, how can the unnamed padding at the end, as NECESSARY to achieve
appropriate alignment were it an array member, be any different from
Mr. Schilling's computation?

I think that the answer to (f) cannot differ from the answer to (e).
--
Norman Diamond                diamond@jit.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
Pardon me?  Or do I have to commit a crime first?
From: smclewin@ultrix.ramapo.edu (Scott M McLewin)
Newsgroups: comp.std.c
Subject: WANTED: info on automated testing tools
Date: 26 Jan 93 05:08:10 GMT
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu


 
 
 
I am looking for infomation on automated software testing tools and would like 
advice on what tools are available and their relative merits.  I am running on 
an MS-DOS platform.
         
I am looking for a program which will excercise the user interface, capture 
and compare screen output, etc.  Presently, we are looking for something 
similar to Ghost from Vermont Creative Software.
 
Please mail any replies, as I cannot keep up with the news as often
as I would like to.   :(
 
 
Scott M McLewin
smclewin@ultrix.ramapo.edu
Newsgroups: comp.std.c
From: dsb@duke.cs.duke.edu (D. Scott Bigham)
Newsgroups: comp.std.c
Subject: sizeof(size_t) == sizeof(ptrdiff_t) required?
Date: 29 Jan 93 03:47:51 GMT
Organization: n. Arrangement in an orderly or logical fashion.  See "miracle".

A friend of mine maintains a freeware C compiler -- non-conforming,
unfortunately.  In a recent discussion, he commented that one of the
ways in which his compiler is non-conforming is that sizeof(size_t)
does not equal sizeof(ptrdiff_t) (in particular, sizeof(size_t)=2 and
sizeof(ptrdiff_t)=4).

Now, I haven't a copy of the Standard, but I can find no wording in K&R2
to this effect.  I can argue convincingly that sizeof(ptrdiff_t) must be
at least as large as sizeof(size_t); the declaration:

char a[N];

is legal for any N in the range of a size_t, and the value &a[N]-&a[0]
must be representable for all such N.  I cannot, however, come up with
a plausible reason why sizeof(ptrdiff_t) could not be greater than
sizeof(size_t).  Given:

char *a, *b;

if the value (b-a) is not in the representable range of a size_t, then
by definition a and b do not point into the same object; the compiler is
not obliged to do anything sensible in this case, but it may certainly
choose to do so.

Opinions?  Does the Standard specify this?

						-sbigham
-- 
Scott Bigham                   | The opinions expressed above are
dsb@romeo.cs.duke.edu          | (c) 1993 Hacker Ltd. and cannot be
bigham@hercules.acpub.duke.edu | copied or distributed without a
    (but not for long)         | Darn Good Reason(tm).
From: hawkeye@glia.biostr.washington.edu (Ken Keys - TF Dude)
Newsgroups: comp.std.c
Subject: Re: Libraries specified in source?
Date: 25 Jan 93 20:39:02 GMT
Article-I.D.: glia.hawkeye.727994342
Organization: University of Washington
NNTP-Posting-Host: glia.biostr.washington.edu

In <1993Jan25.152432.7022@crd.ge.com> volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe) writes:

>|> ray@astro.ocis.temple.edu (Ray Lauff) writes:
>|> >simplify the process, but why not just have a line in the 
>|> >main program such as
>|> >
>|> >#library "/lib/libc.a"

>I like the idea, though I wouldn't include path names for standard stuff.
>Rather, I would mimic the semantics for #include directives.

>Similarly, I would prefer to see something like:
>  #include <libm.a>

>to get the math library.

Even better, math.h could contain the line

  #library <libm.a>

That way, a program conforming to the current standard would work with
this new compiler without modification.  New programs wouldn't have to
use the new #library directive, so they'll work just fine under current
compilers (with the -l switch, of course).

--
Ken Keys, aka Hawkeye
Master of the Fugue
kkeys@ucsd.edu or hawkeye@ucsd.edu
-- 
--
Ken Keys, aka Hawkeye
Master of the Fugue
kkeys@ucsd.edu or hawkeye@ucsd.edu