HDTenEightyP/NetNews huggingface dataset:
From: kevin@traffic.den.mmc.com (Kevin Rodgers)
Subject: Re: Libraries specified in source?
Organization: Martin Marietta Western Internal Systems, Technical Operations
Date: Fri, 22 Jan 1993 23:41:58 GMT

In article <1993Jan22.013725.5587@nntpd.lkg.dec.com> diamond@jit.dec.com (Norman Diamond) writes:
>In article <1993Jan21.182949.29796@cronkite.ocis.temple.edu> ray@astro.ocis.temple.edu (Ray Lauff) writes:
>>I often find myself wondering why standard C has no mechanisms for
>>embedding the libraries required for loading into the code.  Right
>>now I have to specify them on the command line of the compiler call.
...
>Surely the standard can't
>specify how to use extensions.

Surely the standard can evolve to include a few good ideas, like Ray's
#library directive.
-- 
Kevin Rodgers				kevin@traffic.den.mmc.com
Martin Marietta MS A16401		(303) 790-3971
116 Inverness Dr. East
Englewood CO 80112 USA			GO BUFFS!
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.std.c
Subject: Re: Macro replacement
Date: 21 Jan 93 15:42:47 GMT

In article <1993Jan19.180718.3482@csqx.cs.rhbnc.ac.uk> [which hasn't
arrived here yet], andreww@cscx.cs.rhbnc.ac.uk (Andrew Waters) writes:
> Is this truely more logical?  Look at the example:
> 
> #define echo(a) { a ; x }
> #define x       2 * x
> echo (x)
> 
> As before the macro argument "x" is replaced giving the replacement list
> 
> { 2 * x ; x }
> 
> We now examine this replacement list for further macro expansion.  "x" is no
> longer available for replacement,  giving the final result
> 
> { 2 * x ; x }

No.  The rule in the standard about nonreplacable macro names says:

	These nonreplaced macro name preprocessing tokens are no longer
	available for further replacement...

Note carefully that it's talking about the individual preprocessing
tokens, not the macro in general.  Thus, when "x" is expanded to "2 * x"
in the above example, the "x" in the replacement string is not replaced
and *that particular token* is marked unavailable for further
replacement, not the macro x.  Thus, when "{ 2 * x ; x }" is rescanned,
the first "x" would be replacable, but it has been marked and so is left
alone.  The second "x" has not been marked, so it is replaced normally
giving "{ 2 * x ; 2 * x }".  Now the second "x" has also been marked so
that if this string is later rescanned neither "x" will be replaced
again.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com
It doesn't have a moral, does it?  I hate being told how to live my life.
-- Calvin
Newsgroups: comp.std.c
From: diamond@jit533.jit.dec.com (Norman Diamond)
Subject: Re: Empty macro arguments
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Fri, 22 Jan 1993 07:38:03 GMT

In article <727657228@majors3.cs.duke.edu> dsb@duke.cs.duke.edu (D. Scott Bigham) writes:
>diamond@jit.dec.com (Norman Diamond) :
>>In article <16355@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>>>Am I likely to run into any trouble if I just go ahead and use what the
>>>standard itself proposes as an extension?

>>I don't see any wording in the standard that proposes an extension. [...]

>Does this imply that a conforming compiler faced with the [...] fragment
>#define fred(a,b,c) a b c
>fred(1,,3)
>is _required_ to issue a diagnostic?

No.  If this fragment violated a constraint, then the implementation would
have to issue a diagnostic while turning your keyboard into a mousetrap.
However, this fragment only violates semantics, so the implementation can
omit the diagnostic while turning your keyboard into a mousetrap (or can
issue a diagnostic if it wishes, or can proceed with b representing empty
like you really wanted if it wishes).
--
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: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Subject: Re: C things
Organization: University of Helsinki
Date: Sat, 23 Jan 1993 14:54:49 GMT

steve@dbaccess.com (Steve Suttles) writes:
>The problem is that with gets and strcat and several other routines,
>you pass the address of a destination array and it fills it up.

While strcat (and strcpy, sprintf, etc) doesn't have way to specify
the size of the target memory area, it is very, very different from
gets in that the programmer still can check the size in advance and
avoid problems in that way.  This advance checking is impossible with
the gets interface.  Hence, gets is inherently dangerous, strcat only
if you make a mistake when you use it (easy enough).  An important
distinction, IMHO.

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
   MS-DOS, you can't live with it, you can live without it.
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: Is this allowed in C?
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Tue, 26 Jan 1993 01:09:49 GMT

In article <553@heimdall.sdrc.com> scjones@thor.sdrc.com (Larry Jones) writes:
>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.

I half-agree.  ANSI Classic section 4.10.3, page 155 lines 13 to 15:
"The pointer returned if the allocation succeeds is suitably aligned so that
it may be assigned to a pointer to any type of object and then used to access
such an object or an array of objects in the space allocated [...]"

So if int, double, etc. have size larger than 1, and if int, double, etc.
require stricter alignment than char, then there are still two possibilities.
If pointers to them must have some low-order zero bits (which some hardware
architectures require) then malloc() must still suitably align the allocated
byte even though it's a single byte.  However, if pointers can contain any
random bits (not failing until an attempt is made to dereference them) then
the byte need not be aligned.  In either case, standard C does not permit
dereferencing a pointer to an object that doesn't actually exist there.

---------------------

Correction to my previous post:  Someone pointed out that the second post by
that student (whose name I have lost) contained the following expression:
>>> store = malloc(sizeof(blah)+3) + 3;

I didn't notice that one of the additions was outside of the parentheses.
In fact, the second + is illegal because a pointer-to-void cannot be an
operand of +, so the rest of the question was moot.
(However, malloc(sizeof(blah)+3) must still point to suitably aligned space
or else be null.)
--
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: bill@twwells.com (T. William Wells)
Subject: Re: Null pointer constant compatible with pointer to funtion ?
Date: Thu, 21 Jan 1993 10:41:26 GMT
Keywords: pointer
Organization: None, Mt. Laurel, NJ

In article <1993Jan21.001622.13452@xilinx.com> lou@xilinx.com (Lou Sanchez-Chopitea) writes:
:     Is a null pointer constant (3.2.2.3) (and therefore NULL (4.1.5))
: assignment compatible with a pointer to function ?

Yes.

---
Bill                            { rutgers | decwrl | telesci }!twwells!bill
bill@twwells.com
Newsgroups: comp.std.c
From: andrewc@g2syd.genasys.com.au (Andrew Congdon)
Subject: Re: offsetof in case labels
Organization: Genasys II, Sydney, Australia
Date: Thu, 28 Jan 1993 06:55:41 GMT

>In article <1993Jan21.232337.6527@g2syd.genasys.com.au>, roberts@g2syd.genasys.com.au (Robert Swan) writes:

>> A representative of one of the machine vendors (IBM), has glibly stated
>> that the compiler is doing the right thing by rejecting it.

IBM have made a patch available that does not exhibit the problem.  I'd
like to think that their change in attitude was due, at least partly, to
those who contributed here.

Thanks,
--
Andrew Congdon	|  Genasys II Pty Ltd
		|  13th Level, 33 Berry St, North Sydney, NSW, Australia
		|  Phone:    +61-2-954-0022 (-9930 FAX)
		|  Internet: andrewc@g2syd.genasys.com.au
Newsgroups: comp.std.c
From: diamond@jit533.jit.dec.com (Norman Diamond)
Subject: Re: Libraries specified in source?
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Fri, 22 Jan 1993 01:37:25 GMT

In article <1993Jan21.182949.29796@cronkite.ocis.temple.edu> ray@astro.ocis.temple.edu (Ray Lauff) writes:
>I often find myself wondering why standard C has no mechanisms for
>embedding the libraries required for loading into the code.  Right
>now I have to specify them on the command line of the compiler call.

If the implementation comes with documentation saying that, in order to
invoke a conforming implementation, you have to type
  c89 [source file names] -lm -lstring -lbool -lgoto
then that's what you type.  If the documentation doesn't say what you
have to type, ask your vendor for a refund.

If you're using implementation extensions, then friendly implementors
will tell you how to use the extensions too.  Surely the standard can't
specify how to use extensions.
--
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: darcy@druid.uucp (D'Arcy J.M. Cain)
Subject: Re: Libraries specified in source?
Date: Sat, 23 Jan 1993 19:42:02 GMT
Organization: D'Arcy Cain Consulting

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"

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
you know that the libraries reside in that directory?

>which would then alert the linker that that library will be 
>required.  DIGITAL supplies macro assembly programmers with
>this capibility (.library directive), but they recommend
>against using it since it makes moving library files a problem
>since all the source code would need to be updated.  Perhaps
>C could avoid this problem by putting them in an include file.

How is this easier than using the Make file?

-- 
D'Arcy J.M. Cain (darcy@druid.com)  |
D'Arcy Cain Consulting              |   There's no government
Toronto, Ontario, Canada            |   like no government!
+1 416 424 2871          DoD#0082   |
Newsgroups: comp.std.c
From: meissner@osf.org (Michael Meissner)
Subject: Re: Structure walking
Organization: Open Software Foundation
	<1993Jan27.014643.21507@nntpd.lkg.dec.com>
Date: 27 Jan 93 12:08:02

In article <1993Jan27.014643.21507@nntpd.lkg.dec.com> diamond@jit345.bad.jit.dec.com (Norman Diamond) writes:

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

True, and I even made a compiler that did this.  The compiler was on a
word machine (the Data General MV/Eclipse).  All structures had to
have word alignment, even if the members were only character.  This
was necessary because of the requirement that all structure pointers
look the same, to allow pointers to unknown structures to be declared.
--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

You are in a twisty little passage of standards, all conflicting.
Newsgroups: comp.std.c
From: "peter curran" <peter.curran@canrem.com>
Subject: Is this allowed in C?
Reply-To: "peter curran" <peter.curran@canrem.com>
Organization: Canada Remote Systems
Distribution: comp
Date: 26 Jan 93 07:08:35 EST


In <1993Jan22.012502.5241#nntpd.lkg.dec.com> diamond@jit533.jit.dec.com
                       (Norman Diamond) writes..

[original problem deleted]

ND>The C standard guarantees that whenever malloc() succeeds ... the
ND>value will point to storage suitably aligned for everything,....

This leads me to a question:

          void *p;
   p = malloc(1);

Are there any alignment restrictions on the allocated memory?
Assuming, for example, sizeof(double) > 1, a double cannot be
stored here, so does the memory have to be suitably aligned for
use as a "double *?"  Section 4.10.3 appears to me to be
sufficiently ambiguous that this is unclear.

I have on occasion needed addresses to serve as "markers"
(addresses that will not match any real object, nor NULL), and
have accomplished this by allocating objects that will never
really be used.  I could save some (probably trivial amount of)
memory by allocating single bytes for the purpose, but was
never sure that something strange couldn't happen if the
address wsan't properly aligned, even if nothing tried to
derefernce it.

Peter Curran                          FidoNet: 1:229/15
Usenet: peter.curran@canrem.com       RIME:    CRS (#118)
---
  DeLuxe 1.25 #12339  
--
Canada Remote Systems  - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044
Newsgroups: comp.std.c
From: andrewc@g2syd.genasys.com.au (Andrew Congdon)
Subject: const qualifier
Organization: Genasys II, Sydney, Australia
Date: Thu, 28 Jan 1993 07:39:47 GMT

I am still really confused about the use of the const qualifier.  I'd be
grateful if someone could point me at a clear demonstration of its use.

I have a function which takes a parameter that is a 2 dimensional array
which it will never modify.  A similar function takes the same parameter
type but does modify its contents.  To make it clear I thought I'd make
the former have a const qualified argument.  Except for a recently
patched IBM 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.  The compilers seem much happier if the call is changed to:

		fn((const float (*)[3])colours);

Why should the cast be necessary?

The DEC 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".

--
Andrew Congdon	|  Genasys II Pty Ltd
		|  13th Level, 33 Berry St, North Sydney, NSW, Australia
		|  Phone:    +61-2-954-0022 (-9930 FAX)
		|  Internet: andrewc@g2syd.genasys.com.au
Newsgroups: comp.std.c
From: andreww@cscx.cs.rhbnc.ac.uk (Andrew Waters)
Subject: Re: Macro replacement
Reply-To: andreww@dcs.rhbnc.ac.uk (Andrew Waters)
Organization: Dept of Comp Sci, Royal Holloway & Bedford New College Uni London
Date: Fri, 22 Jan 1993 12:14:37 GMT

The example given in the standard (section 3.8.3.5) makes use of an ambiguity
pointed out in the rational.

e.g. (taking only the relavent part)

#define x	2
#define f(a)	f(x * (a))
#define g	f
#define	t(a)	a

t(t(g)(0))

which the standard has going to f(2 * (0)) however if we follow the expansion:

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

So we have two answers

"f(2 * (0))" in the standard,  but just as legally "f(0)".  Surely a poor
example to illustrate expansion rules.
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.std.c
Subject: Re: offsetof in case labels
Date: 25 Jan 93 17:35:19 GMT

In article <1993Jan25.022444.23917@nntpd.lkg.dec.com>, diamond@jit345.bad.jit.dec.com (Norman Diamond) writes:
> In article <542@heimdall.sdrc.com> scjones@thor.sdrc.com (Larry Jones) writes:
> >[ about using an omniscient preprocessor to avoid needing a compiler
> >  extension to support sizeof() ]
> 
> 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.

To the contrary, a non-omniscient, non-integrated generic preprocessor
is still perfectly acceptable, it just requires that the compiler do
whatever is necessary to support sizeof.  Had the committee decided
otherwise on sizeof and limits, such a thing would be impossible.

Indeed, implementations do have a burden to meet the definition of
offsetof, just like they have a burden to meet the rest of the
requirements of the language.  offsetof does not appear to be a
particularly difficult case, since every pre-ANSI compiler I know of had
a broader definition of constant expressions than what the standard
requires (and the standard does allow such a broader definition), such
that one of the expressions listed in the Rationale can be used as the
definition of offsetof.  An implementation that does not wish to provide
such a broader definition must choose another method of implementing
offsetof.  The standard provides sufficient latitude that an implementor
is not forced to implement offsetof in a particular way, but rather has
sufficient latitude to select an implementation method that fit in best
with the rest of the implementation.

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

I've already promised to do so (but that was so long ago, I'm not
surprised you've forgotten -- either ANSI or X3 or both have been
sitting on the TIB for quite a while).
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com
These things just seem to happen. -- Calvin
From: ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig)
Newsgroups: comp.std.c
Subject: binary data with stdin/stdout
Date: 26 Jan 93 21:58:16 GMT
Organization: University of Karlsruhe, Germany
NNTP-Posting-Host: fg70.rz.uni-karlsruhe.de

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

Would a program which wrote binary data to standard output, or read it
from standard input, be complying?

The reason for asking is that many programs which were developed for
UNIX, which do this, fail on systems where binary and text mode for file
streams are not identical.  I'd like to know wether they fail in a
standard - conforming or a non - standard - conforming way :-)
-- 
Thomas Koenig, ig25@rz.uni-karlsruhe.de, ig25@dkauni2.bitnet
The joy of engineering is to find a straight line on a double
logarithmic diagram.
From: bbobak@undergrad.math.waterloo.edu (Brad Bobak)
Newsgroups: comp.std.c
Subject: Is this allowed in C?
Date: 21 Jan 93 16:14:46 GMT
Organization: University of Waterloo


 I was wondering if the following was valid in C. I can't see why it
  wouldn't be, but I'd thought I'd just make sure..


 struct astruct {
    int something;
    int something_else;
 } blah;

 main()
 {
    char *store;
    store = malloc(sizeof(blah));

    memcpy(store, &blah, sizeof(blah));

    ...
    /* how about this? */
    {
        int another_int = 5;
        memcpy(&((struct astruct *)store)->something, &another_int,
               sizeof(int));
    }

    memcpy(&blah, store, sizeof(blah));

    if (blah.something == 5)
    ...
 }

 and something else similar:

#define CHAR_MASK ((1 << BITS_IN_CHAR) - 1)
/* I realize this might fail if sizeof(int) == sizeof(char), if this is
 * possible
 */

 main()
 {
    int val;
    char *store;
    int ct;
    store = malloc(sizeof(val));

    for (ct=0; ct<sizeof(int); ct++)
        store[ct] = (val >> (ct * BITS_IN_CHAR)) & CHAR_MASK;

    ...

    for (val=0, ct=0; ct<sizeof(int); ct++)
        val |= store[ct] << (ct * BITS_IN_CHAR);

    if (val == 5)
    ...
 }

 The reason I'm doing it this way is that I've made a memory allocation
  library. And some systems require special alignment of data. So to
  archive something, I have to copy it to a char array. (I realize this
  may be a little slow). This next question probably has surfaced a few
  times, but is there any way to guarantee the right alignment of
  arbritary data on various architectures?
Newsgroups: comp.std.c
From: TOVSRUD@gribb.hsr.no (Tovsrud, Kjell Ove     1-94)
Subject: Libary with edit-rutines in ANSI-C ??
Organization: Rogaland University Centre
Date: Mon, 25 Jan 1993 23:25:25 GMT

Is there anybodu out there who knows about any libary in ANSI-C with good 
functions with text-editing, i.e. 
	edit_name(int x, int y, int length, ..... )

Or is there any book where I can get such things ?


Please halp me!!

Kjell Ove