HDTenEightyP/NetNews huggingface dataset:
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.std.c
Subject: Re: Aligning an arbitrary pointer?
Date: 23 Jul 1992 05:08:23 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com

In article <PDS.92Jul21153918@lemming.webo.dg.com> pds@lemming.webo.dg.com (Paul D. Smith) writes:
>    bm> On some systems, casting a pointer to a more restrictive type
>    bm> may have the effect of realigning it. [...]
>
>Bleah :).  Maybe true, but certainly not Standard practice.  I would
>expect that on at least some systems the compiler will happily allow
>you to assign 0x01381 (or some other non-aligned value) to an int*,
>say, and then just core with a bus error (or otherwise die) when you
>tried to dereference the pointer 

I expect so as well.  But since the purpose of my post was to list
useful possibilities, I didn't feel like mentioning all the other kinds of
systems.  That's why I said "on some systems".

>    bm> Why not just declare a structure that contains the array and
>    bm> the preceding stuff?  The compiler will guarantee that the
>    bm> array is suitably aligned.
>
>The preceding stuff is of dynamic size; it's read in from a file where
>the file contains the total size and interesting offsets.  The page
>table size has to be dynamic as well.

I was wondering whether this was the case.  I came up with an idea, but I'm
not sure whether it really works.

Declare the structure as a union, where one case is an array of page table
entries, and the other is the preceding stuff.  Then find the array element
whose address is greater than the address of the end of the preceding
stuff.  Use the address of that array element as the address of the page
table.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.std.c
From: jfc@athena.mit.edu (John F Carr)
Subject: Re: Function Prototypes: Don't they force casts?
Organization: Massachusetts Institute of Technology
Date: Sun, 26 Jul 1992 21:38:27 GMT

In article <24914@dog.ee.lbl.gov> torek@horse.ee.lbl.gov (Chris Torek) writes:
>... 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.)

On a VAX or MIPS, a pointer to a function in the kernel will convert
to a negative integer.  I think Sun OS on a SPARC maps some code at
high addresses (0xff??????) which appear negative.

--
    John Carr (jfc@athena.mit.edu)
From: jeff@claw.clearpoint.com (Jeffrey J. Griglack)
Newsgroups: comp.std.c
Subject: Re: Doesn't gcc like // comments?
Date: 21 Jul 92 20:18:41 GMT
	<8ndmvlj.xtifr@netcom.com>
Reply-To: jeff@fang.clearpoint.com
Followup-To: comp.std.c
Organization: /home/jeff/.organization

On 21 Jul 92 10:29:33 GMT, xtifr@netcom.com (Chris Waters) said:

C> In <d!dm_8m.grega@netcom.com> grega@netcom.com (Greg Altman) writes:

>I have some ANSI C code that uses // (since ICC and CL do accept them).

C> Er, no you don't.  If it has // as a comment character, it is *not* ANSI
C> compliant code.  Just a minor nit.  Yes, many compilers do accept this,
C> but they must *not* accept it if run in full ANSI-compliant mode (e.g.
C> -ansi for GCC, /Za for CL).

G++ likes // for a comment line.  It works just fine for me.  // is standard 
for C++, though there is not yet an ANSII standard for C++.
--

-------------------------------------------------------------------------------
|Jeff Griglack             |"Hey, you talking to me or are you just practicing|
|jeff@claw.clearpoint.com  | for one of those performances you do?"           |
|jeff@fang.clearpoint.com  |                          -- Lori Anderson        |
-------------------------------------------------------------------------------
Newsgroups: comp.std.c
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Help with bit and byte addressable bitfields
Date: Wed, 29 Jul 1992 16:22:42 GMT
Organization: U of Toronto Zoology

In article <1992Jul26.043900.7020@gmuvax2.gmu.edu> kbass@gmuvax2.gmu.edu (Ken Bass) writes:
>typedef struct {
>   unsigned int bit0;
>         ...
>   unsigned int bit32;
>} WidgetRamImgDef;
>
>WidgetRamImgDef WidgetRamImg;
>
>I'd like to say WidgetRamImg=0x0; at init time, but the type is wrong.

There are no struct constants in ANSI C, and no way to make them.  What
you have to do is declare a variable, say WidgetRamImgZero, of that type,
initialize its fields individually to zeros, and then say

	WidgetRamImg = WidgetRamImgZero;

Note that if you make the zero variable global, the default initialization
to zero will do the zeroing for you.
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry
Newsgroups: comp.std.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: Character arrays in structures and address alignment -- any standard?
Organization: TauMetric Corporation
Date: Thu, 30 Jul 1992 17:58:41 GMT

bill@twwells.com (T. William Wells) writes:

>In article <14216@ksr.com> jfw@ksr.com (John F. Woods) writes:
>: Please show a strictly conforming program which can tell the difference
>: between "necessary" padding and "unnecessary" padding.

>For example:

>typedef struct {
>	int     x;
>	int     y;
>} foo;
>foo z;

>main()
>{
>	printf("%d\n", (offsetof(foo, y) - offset(foo, x)) - sizeof(int));
>	return (0);
>}

>should print 0 on any standards conforming compiler, if it is true
>that the standard permits only padding for the purpose of
>creating proper alignment.

A good case could be made for this particular example that 0 must be
printed.  (The offset of x must be zero, so the example can be simplified).

The sizeof operator returns the size of an object as used in an array,
with whatever padding is added.  One would then expect that array of
two ints and "foo" would be the same size.  There is the possibility
that padding in an array is not necessary but padding in a struct
is necessary.  It seems unlikely, but I don't know that the Standard
forbids such a situation.

The original example was something like
	typedef struct {
	    char a[3];
	    char b[3];
	}foo;
and the question was whether offsetof(foo,b) must be 3.  I don't believe
a strictly-conforming program could determine whether padding between
fields "a" and "b" is "necessary", but only whether it was present.

"Necessary" is kind of a vague term.  On some architectures, alignment
is absolutely required to avoid runtime faults.  Certainly this is
"necessary".  On other architectures, alignment results in code which
runs considerably faster at the expense of increased data space.  Is
alignment then "necessary"?  I believe that is an economic, not a
Standards, question.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.std.c
From: bill@twwells.com (T. William Wells)
Subject: Re: Character arrays in structures and address alignment -- any standard?
Organization: None, Mt. Laurel, NJ
Date: Wed, 29 Jul 1992 15:27:53 GMT

In article <14216@ksr.com> 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.

For example:

typedef struct {
	int     x;
	int     y;
} foo;
foo z;

main()
{
	printf("%d\n", (offsetof(foo, y) - offset(foo, x)) - sizeof(int));
	return (0);
}

should print 0 on any standards conforming compiler, if it is true
that the standard permits only padding for the purpose of
creating proper alignment. (I'll not argue the question of
whether it does. Since it would be a daft compiler that added
padding for any reason other than alignment, I think it not worth
arguing.)

---
Bill                            { uunet | decwrl | telesci }!twwells!bill
bill@twwells.com
From: volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe)
Newsgroups: comp.std.c
Subject: Re: Character arrays in structures and address alignment -- any standard?
Date: 29 Jul 92 12:40:05 GMT
Reply-To: volpe@ausable.crd.ge.com
Organization: GE Corporate Research & Development

In article <14235@ksr.com>, jfw@ksr.com (John F. Woods) writes:
|> restriction or requirement is met.  For example, it was claimed at one time
|> that, although the Standard lists two and only two kinds of null pointer
|> constants (an integral constant zero or an integral constant zero cast to
|> void *), a compiler could make NULL expand into (char *)0, because a strictly
|> conforming program couldn't tell the difference.  Doug Gwyn (I think) then
|> demonstrated one that could, taking advantage of the # operator.

I believe that was me, not Doug. 

|> What the standard says about alignment of things in a structure is:
|> 
|> 	"Each non-bit-field member of a structure or union object is aligned
|> 	in an implementation-defined manner appropriate to its type."
|> 
|> An implementation must document its strategy, but
|> 
|> 	"For all types, structure members are aligned on 16-byte boundaries,
|> 	except on Fat Tuesday and Christmas, when for all types, structure
|> 	members are aligned on 64-byte boundaries for good luck."

I guess we've exhausted all creative examples of undefined behavior, so
we're moving on to implementation-defined behavior :). I love it!

|> 
|> is perfectly acceptable, even if everything is addressable on arbitrary byte
|> boundaries.  If you would quibble with whether that is "appropriate", either
|> write a SCP that exposes the error, or chalk it up to "quality of
|> implementation".

I would agree with that.

-Chris

-- 
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.std.c
Subject: does "always append" apply to "a+" mode?
Date: 28 Jul 92 20:04:27 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley
NNTP-Posting-Host: 128.3.112.15

In the section on fopen (4.9.5.3, pp. 130--131), the Standard says:

    Opening a file with append mode (|'a'| as the first character in
    the |mode| argument) causes all subsequent writes to the file to be
    forced to the then current end-of-file, regardless of intervening
    calls to the |fseek| function. ...

    When a file is opened with update mode (|'+'| as the second or
    third character in the above list of |mode| argument values), both
    input and output may be performed on the associated stream.
    However, [switching directions requires an intervening reposition
    or flush or EOF].

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.

As I understand it, the seek/flush/EOF requirement for direction-
changing is a direct result of existing Unix (and possibly other)
implementations, where an intervening seek is required to `sync up'
internal counters and set a read/write stream's mode to
`indeterminate', so that the next getc or putc macro will trigger a
function call, where the new direction will be set.  It is not meant
to imply that seeks have any effect on "a+" mode files.

Is this correct?  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?

(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.  My
stdio will never allow a getc or putc on an open write- or read-only
stream, whether or not the counters are `synced up'.  All it takes is
two counters, instead of one....)
-- 
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,comp.std.c++
From: aa761@cleveland.Freenet.Edu (Patrick Murowsky)
Subject: The Programming SIG
Reply-To: aa761@cleveland.Freenet.Edu (Patrick Murowsky)
Organization: Case Western Reserve University, Cleveland, OH (USA)
Date: Fri, 31 Jul 92 15:38:44 GMT


Announcing the arrival of new programming language newsgroups.

freenet.sci.comp.prog.basic
freenet.sci.comp.prog.c
freenet.sci.comp.prog.pascal
freenet.sci.comp.prog.questions
freenet.sci.comp.prog.syntax
freenet.sci.comp.prog.var

The second newsgroup covers C/C++, Turbo C++, and other C languages.

Thanks!

-- 
% Patrick Murowsky `94 %%%%%%%%% "I don't like to lose."  -- James T. Kirk 
%% aa761@cleveland.Freenet.Edu % "Everything is impossible until it isn't." 
%%% SysOp of Programming SIG %%%                          -- Jean-Luc Picard
%%%% SysOp of Movies SIG %%%%%%% "A genetic weakness of the species..."  -- Q
From: jjsc@inf.rl.ac.uk (John Cullen)
Newsgroups: comp.std.c
Subject: Re: dereferencing function pointer as an expression
Keywords: functions pointers dereferencing
Date: 22 Jul 92 08:19:50 GMT
Reply-To: GORMAN_B@P1.LANCSP.AC.UK (Barry Gorman)
Organization: Rutherford Appleton Laboratory, Informatics Department

This article is being posted on behalf of a friend without direct access to
netnews. Please reply to him direct and/or followup to this group.

John Cullen

----------------------------Cut Here------------------------------

From: Barry Gorman  <GORMAN_B@uk.ac.LANCSP.P1>
Date:         Tue, 21 Jul 92 13:57:25
Subject:      Re: dereferencing function pointer as an expression

In article 6839 Norman Diamond writes:
> In article .. Mike Lijewski writes:
>>int f(int i) { return i + 1;}
>>main(){
>>       int (*fp)(int) = f;
>>       if (*f) puts("isn't life fun");}
>>}
> .... the if always succeeds.

Now I saw the original article, and thought that the test should have
been "if (*fp) ...", which I thought I understood; but the "if (*f) ..."
threw me into confusion. This was resolved by reading the ANSI Standard.
-----
3.2.2.1 Lvalues and Function Designators (line 20)

Except when it is the operand of a sizeof operator or the unary & operator,
a function designator with type "function returning type" is converted to
an expression that has type "pointer to function returning type".
-----
3.3.2.2 Function Calls (line 18)

The expression that denotes the called function shall have type pointer to
function returning void or returning an object type other than array type.
-----
I must confess that this was news to me. It seems that a simple function call
such as " y = sin(x); " is more complex than I thought. The "sin" is initally
converted to a pointer to conform to #3.2.2.1 and the call requires a pointer
to conform to #3.3.2.1, however these effectively cancel, and I can sleep at
nights again, or can I ?

What about the " if (*f)... ", what does the standard say:
-----
3.3.3.2 Address and Indirection Operators (line 43)

The unary * operator denotes indirection. If the operand points to a function,
the result is a function designator; ...
-----
All is now clear. First of all, the "f" is converted to a pointer according
to #3.2.2.1. Then the "*f" is converted back to a function designator according
to #3.3.3.2. Finally the expression "*f" is converted back again to a pointer,
which is then (implicitly) compared to NULL (as the function is not called).
Had it been (if ((*f)(2)) ...) then #3.3.2.2 applies, and all would be well.

Many thanks to the ANSI Committee who produced such a readable and well
indexed Standard. It took me only a few moments to find the above information.
May I recommend that you all purchase the Standard, or pester your librarian
to obtain a copy (as I did).

In view of the discussion of "F" in comp.lang.c, may I suggest that the
appropriate word is contained in the statement: "Read The FINE Manual".

Barry
.....
Lancashire Polytechnic is now known as The University of Central Lancashire.
Newsgroups: comp.std.c
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: ANSI Prototype Header Files for C
Date: Thu, 30 Jul 1992 15:48:54 GMT
Organization: U of Toronto Zoology

In article <1992Jul30.075518.5178@neptune.inf.ethz.ch> kaufmann@apsst1.inf.ethz.ch (Helmut Kaufmann) writes:
>Where do I get the above header files? Thank you for any pointer!

From your supplier of an ANSI C compiler.  It is not possible to write
header files that will work independently of the C compiler and C library.
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry
Newsgroups: comp.std.c
From: kaufmann@apsst1.inf.ethz.ch (Helmut Kaufmann)
Subject: ANSI Prototype Header Files for C
Organization: ETH Zurich
Date: Thu, 30 Jul 1992 07:55:18 GMT

Where do I get the above header files? Thank you for any pointer!

Helmut
kaufmann@inf.ethz.ch
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: ANSI Prototype Header Files for C
Date: 31 Jul 92 12:57:03 EDT

kaufmann@apsst1.inf.ethz.ch (Helmut Kaufmann) writes:
>Where do I get the above header files? Thank you for any pointer!

With your ANSI C compilation system.

You can't just glue ANSI header files onto an existing implementation, because
a few of the things that must be defined in the header files require some
cooperation from the "raw" C compiler.  For example, there is no portable way
to define the "offsetof()" macro, so you can't write it without knowing how
the compiler works--and it might even have to be a compiler built-in, i.e.

	#define offsetof(x,y) __offsetof(x,y)

If you're just interested in seeing some existing practice, you can FTP the GNU
C library (prep.ai.mit.edu), or the latest NET2 BSD sources (ftp.uu.net).
(There are, no doubt, places in Europe to ftp both of these, but I don't know
them offhand.)  
Newsgroups: comp.std.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: Scalars and Structs
Keywords: casts
Organization: TauMetric Corporation
Date: Fri, 31 Jul 1992 18:23:57 GMT

johnm@cory.Berkeley.EDU (John D. Mitchell) writes:

>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)?

Correct.  You cannot cast to or from a struct type.

Example:
	struct s { char a[4]; } s1;

It seems likely that s1 is the same size as a long, so we might be
tempted to try to treat its address as the address of a long:
	*(long*)(&s1)
The problem is that struct s1 might not need to be aligned, whereas
a long might need alignment.  This could result in a runtime abort.

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

A union will probably cause the fewest problems.  The members will
start at the same address, and the alignment will be correct.

The best thing to do is to write code which does not require you to
worry about it at all.  Whatever you do risks portability problems.
In particular, the assumption about the struct and the scalar having
the same size is unlikely (in general) to be portable.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: shankar@sgi.com (Shankar Unni)
Newsgroups: comp.std.c
Subject: #if and #endif in different files: legal?
Keywords: preprocessing
Date: 30 Jul 92 00:18:45 GMT
Organization: Silicon Graphics, Inc.


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?

Thanks,
--
Shankar Unni				E-Mail:	shankar@sgi.com
Silicon Graphics Inc.			Phone:	+1-415-390-2072
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: Aligning an arbitrary pointer?
Date: 21 Jul 92 12:08:18 EDT

flaps@dgp.toronto.edu (Alan J Rosenthal) writes:
[ make a union of everything and use its size as the magic pessimal alignment
 constant ]
>The existence of this constant is the remaining issue.  I don't think that
>anything in the standard mandates that this exists; for example, suppose the
>rule was that all pointers, ints, longs, etc had to be aligned on an *odd*
>word?  But I'd be awfully surprised if such a machine existed.

I *think* that the standard requires alignment to get worse, so that odd word
alignment wouldn't be legal, but I'm not sure.  However, there's still a
fundamental problem -- in order to round up a random pointer in this manner,
you need to perform integer arithmetic on it, not pointer arithmetic.  The
standard makes too few guarantees about what happens when you turn pointers
into integers and vice versa.  If you have an array of char whose base you
*know* is maximally aligned (eg it came from malloc (the title of a horror
film?)), then you can re-align pointers within the array if you have the
base pointer handy.
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: Character arrays in structures and address alignment -- any standard?
Date: 31 Jul 92 12:42:36 EDT

bill@twwells.com (T. William Wells) writes:
>In article <14216@ksr.com> 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.
>: >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.

>For example:
>	printf("%d\n", (offsetof(foo, y) - offset(foo, x)) - sizeof(int));
>should print 0 on any standards conforming compiler, if it is true that the
>standard permits only padding for the purpose of creating proper alignment.

Conversely, in the absense of any means of deriving from the Standard this
unstated requirement, the program is not strictly conforming.

The Rationale isn't the Standard, but I'll quote it anyway: 3.5.2.1 "Since
some existing implementations, in the interest of enhanced access time, leave
internal holes larger than absolutely necessary, it is not clear that a
portable deterministic method can be given for traversing a structure field
by field."