HDTenEightyP/NetNews huggingface dataset:
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.std.c
Subject: Re: Function Prototypes: Don't they force casts?
Date: 26 Jul 92 21:06:09 GMT
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
NNTP-Posting-Host: 128.3.112.15

In article <OINK.92Jul26032212@julian.newshost.uwo.ca>
oink@newshost.uwo.ca (Test Account) writes:
>#include <signal.h>
>#include "myproto.h" /* This included many prototypes, but of particular
>interest here is: void memory_fault(void); */
>[...]
>	if ((int) signal(SIGSEGV, memory_fault) < 0) {
>		perror("Trouble initializing SEGV routine");
>		exit(-1);
>	}

>Under AIX 3.2 using c89, this produces a diagnostic about incompatible types:

It certainly should!

>int and pointer (don't have the exact text handy, but I hope you get the
>idea). This occurs IFF memory_fault() is declared AFTER its use or in another
>module, if it is declared before its use there is no diagnostic.

This is wrong (by which I mean `this behavior is nonconformant').
In any case, if myproto.h includes a prototype, the function is (as
it must be) declared before its name is used.  Perhaps you mean
`defined'?

>The fix is simple, ((void *) memory_fault) works fine but I THINK that
>it is unnecessary.

It is not only unnecessary, it is also wrong and should cause a
diagnostic.  The type `void *' is not assignment-compatible with any
pointer-to-function type.

The subject line asks whether prototypes `force casts'.  No.  Prototypes
provide *assignment context* and the legality of any argument for which
there is a prototype is identical to that for an assignment to a variable
of the same type as in the prototype (section 3.3.2.2, p. 42, ll. 10--16).

Now, signal() takes, as its second argument, a value of type:

	pointer to function (of one arg: int) returning void

(section 4.7.1.1).   The `memory_fault' prototype says that
memory_fault is a

	function (of no args) returning void

so that mentioning it produces a pointer to this.  These are not
assignment-compatible (section 3.3.16.1) and this requires a diagnostic.

The diagnostic can be eliminated (at the cost of undefined runtime
behavior, i.e., without fixing the bug) with:

	signal(SIGSEGV, (void (*)(int))memory_fault)

The correct fix, of course, is to change memory_fault so that it takes
exactly one `int' argument, and change the prototype correspondingly.

In any case, the test

	if ((int)signal(...) < 0) ...

is quite wrong, and will fail on machines on which function pointers
appear negative after conversion to int.  (I have a fuzzy memory that
suggests this may have been the case on some Elxsi machine, for
instance.)  It should be

	if (signal(...) == SIG_ERR) ...

If you have a pre-ANSI system that does not define SIG_ERR, this will
probably work:

	#ifndef SIG_ERR
	#define	SIG_ERR ((void (*)(int))-1)
	#endif

(The reason for using SIG_ERR in the first place is that the above is,
obviously, not portable.  I claim only that it will `probably work'.)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
Newsgroups: comp.std.c
From: smayo@wang.com (Scott Mayo)
Subject: Re: Character arrays in structures and address alignment -- any standard?
Organization: Wang Labs, Lowell MA, USA
Date: Tue, 28 Jul 92 16:12:18 GMT

jfw@ksr.com (John F. Woods) writes:
>msb@sq.sq.com (Mark Brader) writes:
>>> The Standard allows arbitrary padding between fields and after the
>>> last field.
>>Not quite; it allows padding so that the members are correctly aligned
>>for their types.  It does not say anything about padding being permitted
>>for any other reasons, and my interpretation is that it isn't.

>Please show a strictly conforming program which can tell the difference
>between "necessary" padding and "unnecessary" padding.

In spirit, there is something askew in this question. The usual intent
behind writing a strictly conforming program is to make it as portable
as possible. In that case, the last thing a program should be written to
know about is if padding occurs, how it occurs, and when. It varies from
environment to environment, and for all you know, it varies wildly at
different times of day on a given machine. The compiler is supposed to worry
about it - not you. The compiler can pad anything for any reason it
likes, as long as pointer subtraction and comparisons work.

In practice, you can detect padding by generating pointers to two objects
(in the same array or struct of course), casting them to char*, and
subtracting. If you get an unexpected value, padding has occured. Whether
it was "necessary" or not is hardly relevant, a quality of implementation
issue at best, I'd think.
--
..For to contend in words is not to care how error is overcome by truth,
   but how your speech is preferred to that of another.      -Augustine
smayo@wang.com
Newsgroups: comp.std.c
From: oink@newshost.uwo.ca (Test Account)
Subject: Function Prototypes: Don't they force casts?
Organization: The University of Western Ontario, London, Canada.
Date: Sun, 26 Jul 1992 08:22:12 GMT

Howdy:
	While I was completeing the port of my application to ANSI-C, I came
across this:

#include <signal.h>
#include "myproto.h" /* This included many prototypes, but of particular
interest here is: void memory_fault(void); */

[...]

	if ((int) signal(SIGSEGV, memory_fault) < 0) {
		perror("Trouble initializing SEGV routine");
		exit(-1);
	}

Under AIX 3.2 using c89, this produces a diagnostic about incompatible types:
int and pointer (don't have the exact text handy, but I hope you get the
idea). This occurs IFF memory_fault() is declared AFTER its use or in another
module, if it is declared before its use there is no diagnostic. The fix is
simple, ((void *) memory_fault) works fine but I THINK that it is unnecessary.

Now I know that a conforming implementation is allowed to issue any spurious
diagnostics that it wishes to but ...

Am I all wet here or should I make a call to IBM to ask for a fix (I mean, it
made me wonder whether the prototypes were being used at all (they are)).

what say you?

cheerskinch
Dave Kinchlea        kinch@betty.csd.uwo.ca (reply will (should) work)
Computer Science Dept.
University of Western Ontario
London, Ontario, Canada
From: johnm@cory.Berkeley.EDU (John D. Mitchell)
Newsgroups: comp.std.c
Subject: Scalars and Structs
Keywords: casts
Date: 30 Jul 92 20:56:01 GMT
Organization: University of California, at Berkeley

ANSI X3.159-1989:
	Section 3.3.4 Cast Operators:
		Constraints:
			"Unless the type name specifies void type, the type
			name shall specify qualified or unqualified scalar
			type and the operand shall have scalar type."

Am I correct in taking this to mean that there is no way to cast a
structure of known size to a scalar that just so happens to have the same
size (or vice versa)?

Is the right thing to do is to use a union?  Or is there a better solution.


Thanks,
	John
	johnm@cory.Berkeley.EDU
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.std.c
Subject: Re: does "always append" apply to "a+" mode?
Date: 29 Jul 1992 15:01:03 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
NNTP-Posting-Host: 128.3.112.15

In article <24992@dog.ee.lbl.gov> I wrote:
>>A number of existing implementations that claim POSIX
>>conformance (and hence ANSI X3.159-1989 conformance) do NOT always
>>append with "a+" mode; are they broken?

In article <Bs4vLp.A1y@jrd.dec.com> diamond@jit.dec.com (Norman Diamond) writes:
>I think that neither paragraph overrides the other.  If the program obeys
>the standard's requirements, then all writes will be appended to the end
>of the file.

Thus, these implementations *are* broken.  An example program fragment:

	fp = fopen(name, "a+");
	...
	rewind(fp);
	ret = fwrite(...);	/* replace record at offset 0 */

As the comment says, the author expected this `fwrite' call to overwrite
the first few bytes in the file.  On these existing implementations, it
*does*, even though the file is considerably longer.

(This was the question.  I am not sure if your answer above is meant
to say that "yes, these implementations are broken".  To name names:

    "HP and DEC are certified to have passed POSIX P1003.1 testing and HP
     runs an NIST approved POSIX P1003.1 testing facility. ..."

yet these same systems make the above fwrite write at other than EOF.)

>If the program does not obey the standard's requirements, then the
>results are undefined.

Certainly; that was never the question.

>>(As an aside, I have an existence proof that the intermediate seek
>>`feature' is unnecessary, in the form of the 4.3BSD-net.2 stdio.

>No.  An example of an implementation with an extension does not prove
>that programs don't have to obey the standard.

That is NOT what I meant.  I meant that the historical justification
(`ANSI C requires the seek because you have to seek to reset fp->_cnt')
is ONLY historical; it has no basis in sensibility.  (`Historical'
reasons are certainly good enough for a standard, though given that the
ANSI committee saw fit to fix other existing bugs, I am not sure why
they balked at fixing this one.)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: Scalars and Structs
Keywords: casts
Date: 31 Jul 92 13:05:26 EDT

diamond@jit345.bad.jit.dec.com (Norman Diamond) writes:
>In article <1992Jul30.205601.13276@pasteur.Berkeley.EDU> johnm@cory.Berkeley.EDU (John D. Mitchell) writes:
>>ANSI Section 3.3.4 Cast Operators:
>>Am I correct in taking this to mean that there is no way to cast a
>>structure of known size to a scalar that just so happens to have the same
>>size (or vice versa)?
>Yes.
>>Or is there a better solution. [than a union]
>If the structure doesn't have storage class register, then you can do
>*(scalar_type*)&structure.

The Standard even guarantees that this must work; if the structure looks like

	struct something {
		scalar_type frobozz;
	} honk;

then because "a pointer to a structure object, suitably converted, points to
its initial member", 

	*(scalar_type*)&structure

is officially blessed.

>If the scalar doesn't have storage class
>register, then you can do *(structure_type*)&scalar.

I'm much less sure about this one, in fact, I'm almost certain it's not
guaranteed; if "scalar" is of type "char", then &scalar need not be maximally
aligned, but the "all structure pointers smell alike" principle indicates that
even

	struct {
		char frobozz;
	};

can potentially require maximal alignment, hence

	*(struct_type*)&scalar;

can detonate with an addressing error or indulge in other undesirable behavior.
The standard guarantees that a pointer to the initial member of a structure
object can be converted to a pointer to the structure, but *not* that a pointer
to something of the same *type* may be so converted.
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.std.c
Subject: Re: #if and #endif in different files: legal?
Keywords: preprocessing
Date: 30 Jul 92 08:53:02 GMT
Organization: AND Software BV Rotterdam

In article <ntvfii4@fido.asd.sgi.com> shankar@sgi.com (Shankar Unni) writes:
|
|What is the accepted opinion as to the legality of a "#if" and a
|"#else" or "#endif" being in different files, as in:
|
| a.c:
|
|    #ifdef __STDC__
|    #include "a.h"
|
| a.h:
|
|    main() { }
|    #endif /* __STDC__ */
|
|
|Should the above compile? Not compile? Implementation-defined?

It shouldn't compile. Have a look at the syntax of a preprocessing-file:
ANSI 3.8 Preprocessing directives:

preprocessing-file:
	group_opt

group:
	group-part
	...

group-part:
	if-section
	control-line
	...

if-section:
	if-group elif-groups_opt else-group_opt endif-line

control-line:
	#include pp-tokens new-line
	...

As you can see, the entire #if ... #endif structure has to be present
in _one_ preprocessing file. The #include control line has to be processed
recursively as stated in ANSI 2.1.1.2 Translation phases:

`A #include preprocessing directive causes the named header or source file
 to be processed from phase 1 through phase 4 recursively.'

A footnote states:

`Implementations must behave as if these separate phaases occur, even
 though many are typically folded together in practice.'

So an #include directive is a bit more than just a switch from one
file to another for the lexical analyzer (after stacking the previous
file descriptors of course.)

kind regards,

Jos aka jos@and.nl
From: ian@airs.com (Ian Lance Taylor)
Newsgroups: comp.std.c
Subject: Re: does "always append" apply to "a+" mode?
Date: 29 Jul 92 03:09:19 GMT

torek@horse.ee.lbl.gov (Chris Torek) writes:

>To me, it seems clear that a stream opened in "a+" mode can be read at
>any arbitrary position, but all writes to that stream are appended to
>the underlying file.  There is some dissent, however, on the grounds
>that the second paragraph `overrides' the first, i.e., that the first
>paragraph does not apply because of the '+' character.

Table 4.1 in the Rationale clearly agrees with you (and so do I).
Although the Rationale is not part of the standard, it is presumably a
reliable guide in a case of ambiguity requiring an interpretation
ruling.
-- 
Ian Taylor | ian@airs.com | First to identify quote wins free e-mail message:
``It takes a man months and months to reconcile himself to a new hat.  And
  just when you're preparing to send it to the jumble sale, he says, `That's
  rather a nice hat you've got on, where did you get it?' ''
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: Aligning an arbitrary pointer?
Date: 21 Jul 92 12:19:51 EDT

barmar@think.com (Barry Margolin) writes:
>>I guess I still think that questions on how/if certain things can be
>>done in conformant C are legitimate for comp.std.c, but I'm willing
>>to be persuaded otherwise by a concensus... anyone?

>i don't think it's worthwhile debating it, so I'll keep replying here.

I think it is valuable to ask questions like that, but the problem is that
too many of the answers are "well, if your machine allows you to cast pointers
to integers with no change in bits, then you could do this"; if folks are
going to post the answer on comp.std.c, it would be nice if they'd constrain
the answers to what the Standard actually says is guaranteed...
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: Scalars and Structs
Keywords: casts
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Fri, 31 Jul 1992 11:07:37 GMT

In article <1992Jul30.205601.13276@pasteur.Berkeley.EDU> johnm@cory.Berkeley.EDU (John D. Mitchell) writes:
>ANSI Section 3.3.4 Cast Operators:
>Am I correct in taking this to mean that there is no way to cast a
>structure of known size to a scalar that just so happens to have the same
>size (or vice versa)?

Yes.

>Is the right thing to do is to use a union?

I think so.  A strictly conforming program cannot store into one element of
a union and then fetch out of a differently typed element, and the standard
does not guarantee how thorough the overlap is.  But in practice, you will
be more successful in writing implementation-dependent code that depends on
this rather than depending on extensions to the cast operation.
(Even if a conforming implementation extends the cast operation, it still
has to issue a diagnostic.)

>Or is there a better solution.

If the structure doesn't have storage class register, then you can do
*(scalar_type*)&structure.  If the scalar doesn't have storage class
register, then you can do *(structure_type*)&scalar.
--
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: volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe)
Newsgroups: comp.std.c
Subject: Re: Character arrays in structures and address alignment -- any standard?
Date: 31 Jul 92 01:09:41 GMT
Reply-To: volpe@ausable.crd.ge.com
Organization: GE Corporate Research & Development

In article <7022@skye.ed.ac.uk>, richard@aiai.ed.ac.uk (Richard Tobin) writes:
|> In article <Bs5pMJ.3nM@twwells.com> bill@twwells.com (T. William Wells) writes:
|> >: Please show a strictly conforming program which can tell the difference
|> >: between "necessary" padding and "unnecessary" padding.
|> 
|> >For example:
|> 
|> >	printf("%d\n", (offsetof(foo, y) - offset(foo, x)) - sizeof(int));
|> 
|> *If* the standard allows "unnecessary" padding, this program is not
|> strictly conforming.
|> 
|> (1.7 Compliance)
|> 
|> "A strictly conforming program ... shall not produce output dependent
|> on any unspecified, undefined, or implementation-defined behavior"

Your reasoning is wrong because your argument is circular. When you say,

   "*IF* the standard ..."

above, you mean to say, 

  "*If* the `as-if' rule can be applied here to allow unnecessary padding, 
  thereby overriding a literal interpretation which clearly states that 
  unnecessary padding is not allowed, THEN the program is not strictly 
  conforming." 

Look at the reasoning here (PRO advocates unnecessary padding):

PRO: "I think unneccessary padding is perfectly ok."
CON: "Wrong. The Standard clearly says padding can only be done for alignment
      purposes."
PRO: "Oh yeah, well that's a *literal* interpretation, but the `as-if' 
      rule states that unnecessary padding is acceptable as long as a 
      strictly conforming program can't tell that it's being done. Can
      you produce such a program? I bet you can't!"
CON: "Oh yeah? Here's one! It prints different output if the compiler
      is inserting unnecessary padding!!!"
PRO: "But *if* unnecessary padding is ok, *then* the program isn't
      Strictly Conforming, *therefore* the as-if rule still applies, 
      *therefore* unnecessary padding is ok!"

PRO's last argument is equivalent to "If A then A". However, you certainly
can't conclude A from that. The following statement is 100% true:

  "If the moon is made of green cheese, then the moon is made of 
   green cheese."

Perfectly true statement. Does that mean the moon is made of green cheese?


|> 
|> -- Richard
|> -- 
|> Richard Tobin,
|> AI Applications Institute,                                R.Tobin@ed.ac.uk
|> Edinburgh University.

-Chris

-- 
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
Newsgroups: comp.std.c
From: jimp@cognos.com (Jim Patterson)
Subject: Re: Aligning an arbitrary pointer?
Organization: Cognos Incorporated, Ottawa CANADA
X-Newsreader: Tin 1.1 PL3
Date: Tue, 21 Jul 1992 13:26:54 GMT

meissner@osf.org (Michael Meissner) writes:
: In article <1992Jul20.210212.2935@cognos.com> jimp@cognos.com (Jim
: Patterson) writes:
: 
: | I don't know of any way to do this that's guaranteed to work, but it
: | can be done for any compiler where casting a pointer to an int
: 
: Of course, if you ever want your code to run on Alpha, you had better
: cast the pointer to LONG and not INT.  On them new fangled 64-bit
: alpha's, ints are 32 bits, longs are 64 bits, and pointers are 64
: bits.

No, it doesn't matter. Only the low-order few bits are relevant in the
(int)-cast version of the pointer, since it's just used to determine
the amount of "unalignment", which is used to build an adjustment to
add to the original pointer. I believe it will even work on an AS/400,
where pointers are 16 bytes but there is no integer datatype larger
than 4 bytes in length. (On the AS/400, casting a pointer to an int
returns the offset but drops the segment info etc., but the algorithm
is only interested in the offset anyways so doesn't care). The only
really troublesome cases are where the alignment size is not a power
of two, but fortunately such machines are becoming increasingly rare.
-- 
Jim Patterson                  Cognos Incorporated
Sr Consulting Engineer         P.O. BOX 9707
UUNET:jimp@cognos.COM          3755 Riverside Drive
PHONE:(613)738-1338 x3385      Ottawa, Ont  K1G 3Z4
From: richard@aiai.ed.ac.uk (Richard Tobin)
Newsgroups: comp.std.c
Subject: Re: Character arrays in structures and address alignment -- any standard?
Date: 30 Jul 92 15:14:42 GMT
Organization: Templi Resurgentes Equites Synarchici

In article <Bs5pMJ.3nM@twwells.com> bill@twwells.com (T. William Wells) writes:
>: Please show a strictly conforming program which can tell the difference
>: between "necessary" padding and "unnecessary" padding.

>For example:

>	printf("%d\n", (offsetof(foo, y) - offset(foo, x)) - sizeof(int));

*If* the standard allows "unnecessary" padding, this program is not
strictly conforming.

(1.7 Compliance)

"A strictly conforming program ... shall not produce output dependent
on any unspecified, undefined, or implementation-defined behavior"

-- Richard
-- 
Richard Tobin,
AI Applications Institute,                                R.Tobin@ed.ac.uk
Edinburgh University.
From: cdrigget@helios.UUCP (Christopher T. Driggett)
Newsgroups: comp.emacs
Subject: Re: emacsclient doesn't work
Keywords: emacsclient
Date: 27 Jul 92 18:57:04 GMT
Organization: Consilium Inc

You must first run a regular emacs and then you can say emacsclient <file> and the file will appear in your first emacs window.  That's how I got it to work on SUN sparc 2 .

Summary:
	emacs .profile &
	emacsclient .cshrc &

Chris
Organization: Carnegie Mellon, Pittsburgh, PA
From: srm@ross.com (Sesha Myneni)
Newsgroups: comp.emacs
Subject: Re: Sequentially edit several files
Date: 22 Jul 92 23:18:25 GMT
	<BASHFORD.92Jul21211537@griffy.scripps.edu>
Organization: ROSS Technology, Inc. Austin, Tx.

In article <BASHFORD.92Jul21211537@griffy.scripps.edu> bashford@scripps.edu (Don &) writes:
|>>
|>>   Path: ross.COM!loyola!cs.utexas.edu!usc!sdd.hp.com!network.ucsd.edu!riscsm!usenet
|>>   From: bashford@scripps.edu (Don &)
|>>   Newsgroups: comp.emacs
|>>   Date: 22 Jul 92 04:10:35 GMT
|>>   References: <1992Jul22.004446.27938@Veritas.COM>
|>>   Sender: usenet@riscsm.scripps.edu
|>>   Organization: The Scripps Research Institute, La Jolla, CA, USA
|>>   Lines: 27
|>>
|>>   >>>>> In article <1992Jul22.004446.27938@Veritas.COM>, sef@Veritas.COM (Sef Kloninger) writes:
|>>
|>>   SK> There's a feature in VI that I still find useful:  you can select 
|>>   SK> many files to edit, and then use ":n" to go sequentially through
|>>   SK> the list, visiting or editing each file once and only once.
|>>
|>>   SK> Anyone know of something similar in emacs?  Just editing multiple
|>>   SK> files in emacs isn't enough because there's no quick way to visit

	Editing a bunch of files as Don explained below is a better
way than what we have in "vi". In vi you can't access the files
randomly(as I remember last). But in emacs once you invoke emacs on
all the files say "abc*" then using the buffer commands you can access
any file. I think this is a great feature.

|>>   SK> each file once, as far as I can tell...
|>>
|>>   kill-buffer (C-x k) is the key.  Do "emacs bunch o files" to start up and
|>>   you will be presented with a window into the buffer of one file.
|>>   After you've finished with it (perhaps saving it with C-x s) kill the
|>>   buffer with C-x k.  You will then get the buffer of the next file,
|>>   and so on.  The only big difference from VI is that you will be presented
|>>   with the files in the reverse order to what you typed on the input line.
|>>
|>>   For visiting files in random order, do C-x C-b as soon as emacs starts
|>>   and you'll get a listing of all the current buffers and their associated
|>>   files.  To edit one of the files on the list move your cursor to the
|>>   corresponding line and type f and you'll be in that file.  C-x b will
|>>   get you back to the *Buffer List* buffer so you can select a new file.
|>>
|>>   Enjoy,
|>>
|>>   Don Bashford
|>>   bashford@scripps.edu
|>>

-sesha

--
_______``When the going gets wierd, the weird turn pro...''__________
Seshagiri Rao Myneni                                     srm@ross.com
-ROSS Technology Inc., 5316 Hwy 290 West, Suite 500, Austin, TX 78735
-Work: (512) 892-7802 x264  fax: (512) 892-3036  Home: (512) 892-7993
Newsgroups: comp.emacs,gnu.emacs.help