HDTenEightyP/NetNews huggingface dataset:
From: pds@lemming.webo.dg.com (Paul D. Smith)
Newsgroups: comp.std.c
Subject: Re: Aligning an arbitrary pointer?
Date: 21 Jul 92 19:39:18 GMT
	<1473f4INNq24@early-bird.think.com> <PDS.92Jul18154500@lemming.webo.dg.com>
	<14f6u9INNon7@early-bird.think.com>
Organization: NSDD/ONSD, Data General Corp., Westboro, MA

[] Regarding Re: Aligning an arbitrary pointer?;
[] barmar@think.com (Barry Margolin) writes:

    bm> In article <PDS.92Jul18154500@lemming.webo.dg.com>
    bm> pds@lemming.webo.dg.com (Paul D. Smith) writes:

    >I'm modifying an existing piece of code which allocates a huge
    >chunk of memory then segments it into various parts, one of which
    >is an array of structs (it's a page table).

    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 (that's pretty much what happens on
my RISC system :-)

In fact I'd much rather it did that than quietly modify my pointer by
dropping bits... it would be a *major* pain to find *that* bug! :-)

    >For various reasons I don't want to introduce massive changes;
    >the obvious way to do this properly is allocate the memory
    >individually so I know it's properly aligned, but I don't want to
    >change things that much.  I can't think of *any* other way to do
    >it, actually.

    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.

Anyway, I guess the consensus is that you can't do this in standard C,
so that's all I wanted to know!  Thanks all...
--

                                                                paul
-----
 ------------------------------------------------------------------
| Paul D. Smith                          |    paul_smith@dg.com    |
| Data General Corp.                     | pds@lemming.webo.dg.com |
| Network Systems Development Division   |                         |
| Open Network Systems Development       |   "Pretty Damn S..."    |
 ------------------------------------------------------------------
Newsgroups: comp.std.c
From: darcy@druid.uucp (D'Arcy J.M. Cain)
Subject: Re: Function Prototypes: Don't they force casts?
Date: Tue, 28 Jul 1992 11:19:16 GMT
Organization: D'Arcy Cain Consulting

oink@newshost.uwo.ca (Test Account) writes:
>#include <signal.h>
> ... void memory_fault(void); */
>[...]
>	if ((int) signal(SIGSEGV, memory_fault) < 0) {

Prototypes don't actually cast.  Here is the relevant section:

    On entry to the function the value of each argument expression shall
    be converted to the type of its corresponding parameter, as if by
    assignment to the parameter.

So it isn't casting that is being done but rather promotion.  In this case
you need the cast because the second parameter to signal isn't the same as
your memory_fault function.  Signal handlers take an int argument.  The
right way to fix this is fix your signal handler and declare it as:

    void memory_fault(int);

You are free to ignore the argument in the actual handler but you should
still declare it in the parameter list.

>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

This suggests that the handler actually is defined with an int argument
except that you should get a diagnostic from the compiler if the above
prototype is in scope when you define it.  Perhaps you don't have enough
warnings turned on.

-- 
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   |
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: Character arrays in structures and address alignment -- any standard?
Date: 28 Jul 92 10:20:59 EDT

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.
Newsgroups: comp.std.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: Character arrays in structures and address alignment -- any standard?
Organization: SoftQuad Inc., Toronto, Canada
Date: Tue, 28 Jul 92 06:33:56 GMT

> |  struct {
> |    char a[3];
> |    char b[2];
> |  } x;
> 
> 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.

> You cannot rely on the offset of member 'b' being the
> same on different implementations.

This conclusion is correct, though; there's nothing to say that array-of-
character types have to have the alignment requirement as character types.
For example, the compiler is at liberty to force all arrays of char to
begin on a 4-byte boundary, and therefore insert 1 byte between a and b.
-- 
Mark Brader	  "I'm not a lawyer, but I'm pedantic and that's just as good."
utzoo!sq!msb, msb@sq.com				       -- D Gary Grady

This article is in the public domain.
Newsgroups: comp.std.c
From: duane@anasazi.com (Duane Morse)
Subject: Character arrays in structures and address alignment -- any standard?
Organization: Anasazi Inc, Phoenix AZ USA
Date: Sun, 26 Jul 1992 22:52:52 GMT

Consider

  struct {
    char a[3];
    char b[2];
  } x;

On the 5 different Unix machines in our building, 'b' always starts 3
bytes after 'a'; the compiler is smart enough to know that it is both
legal and proper to leave the start of 'b' on an odd byte boundary.

But is that a standard or a requirement?  In other words, is it really
portable to send a structure of purely character data to another machine
without taking it apart first to insure that one doesn't send 'filler'
bytes too?

-- 

Duane Morse	e-mail: duane@anasazi.com
(602) 861-7609
Newsgroups: comp.std.c
From: bill@twwells.com (T. William Wells)
Subject: Re: does "always append" apply to "a+" mode?
Organization: None, Mt. Laurel, NJ
Date: Wed, 29 Jul 1992 15:17:25 GMT

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

Suggest that they take a remedial reading course before bothering
you further. See:

# Opening a file with append mode (|'a'| as the first character
...                                             ^^^^^
# When a file is opened with update mode (|'+'| as the second or
						       ^^^^^^
# third character in the above list of |mode| argument values), both
  ^^^^^
The first paragraph applies whenever the first character is an
`a'; the second paragraph applies whenever the second or third
character is a `+'. When the first and second characters are `a+'
both paragraphs apply. There is no other reading possible.

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

Yes.

---
Bill                            { uunet | decwrl | telesci }!twwells!bill
bill@twwells.com
From: richard@aiai.ed.ac.uk (Richard Tobin)
Newsgroups: comp.std.c
Subject: Re: Character arrays in structures and address alignment -- any standard?
Date: 31 Jul 92 17:08:14 GMT
Organization: Templi Resurgentes Equites Synarchici

In article <1992Jul31.010941.7282@crd.ge.com> volpe@ausable.crd.ge.com writes:
>|> *If* the standard allows "unnecessary" padding, this program is not
>|> strictly conforming.

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

You're over-interpreting my statement.  I wasn't trying to prove that
unnecessary padding is ok.  I was merely pointing out that it couldn't
be a strictly conforming program that behaved differently under the
two interpretations, because under one of them it wouldn't be strictly
conforming.

It appears to be the case that you can't write a strictly conforming
program that prints the value of any implementation-defined parameter.

-- Richard
-- 
Richard Tobin,
AI Applications Institute,                                R.Tobin@ed.ac.uk
Edinburgh University.
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.std.c
Subject: Re: does "always append" apply to "a+" mode?
Date: 30 Jul 92 04:15:44 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

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

My understanding of O_APPEND in UNIX (peace; I'll get to the std.c bit soon)
is that every write goes to the end of the file, regardless of where the
file pointer is, and regardless of where the end of the file _was_ last time
we looked.  This means that every time I write a record to such a file, it
is, _at the instant it goes into the file_, the last thing there.

It has never been clear to me what the model is for "a" mode.
Is it like Fortran's
	OPEN(UNIT=..., FILE='name', ACTION='WRITE', POSITION='APPEND')
(i.e. is it just like "w" mode except for being _initially_ positioned at
the end of the existing file), or is like like UNIX's
	open("name", O_WRONLY|O_APPEND|O_CREAT)

If it is the latter, I don't quite understand how to use it.  In particular,
I don't understand what if any use I can make of ftell() or fgetpos() (there
is where the last write finished, there is where the end of the file is right
now, and there is where the buffered characters will actually go, and those
three places can all be different).  Indeed, it seems to me that there are
just two ways I can use an "a" mode file:

    (1)	Assume or ensure that no other process or FILE* refers to the file,
	and treat it as if it was "w" except for seeking to the end instead
	of truncating.

    (2)	Assume that other processes _might_ be using the file,
	explicitly use setvbuf() to make sure the buffer is big enough to
	hold a complete formatted record, and _religiously_ use fflush()
	after writing each record (because if I don't do these things,
	the buffer might fragment my logical formatted record, and the
	fragments might be interleaved with fragments from another process).

I appreciate that the ANSI standard cannot and should not make promises
about UNIX-specific features sucha s O_APPEND; I'm not so much asking
"can I get access to this feature" as asking "might this feature be used,
and if so, what damage can that do to me".
-- 
You can lie with statistics ... but not to a statistician.
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.std.c
Subject: Re: can I call vprintf() twice in a row?
Date: 25 Jul 1992 06:13:45 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
NNTP-Posting-Host: 128.3.112.15

In article <ZJ2FoB1w165w@tsoft.sf-bay.org> bbs.dennis@tsoft.sf-bay.org
(Dennis Yelle) writes:
>    Is the following legal ansi c?
>    I beleave that it is, but if not, I would like to know why not.

>#include <stdarg.h>
>#include <stdio.h>
>
>void report( char *fmt, ...)
>{
>    va_list arg_ptr;
>    
>    va_start( arg_ptr, fmt);
>    vprintf( fmt, arg_ptr);
>    vprintf( fmt, arg_ptr);  /* Yes, we want to print it twice.     */
>                             /* In the original program, the second */
>                             /* was vfprintf to a log file.         */
>    va_end( arg_ptr);
>}

X3.159-1989, section 4.8, p. 123, ll. 13--15:

    The object |ap| [equivalently, |arg_ptr| above] may be passed as
    an argument to another function; if that function invokes the |va_arg|
    macro with parameter |ap|, the value of |ap| in the calling function
    is indeterminate and shall be passed to the |va_end| macro prior to
    any further reference to |ap|.

Since |vprintf| certainly uses |va_arg| on |arg_ptr|, the code quoted
above violates this `shall' (which, note, is outside a `constraints'
section, so that this violation does not require a diagnostic).

There is a trivial fix for the report() function:

	va_start(arg_ptr, fmt);
	vprintf(fmt, arg_ptr);
	va_end(arg_ptr);
	va_start(arg_ptr, fmt);
	vprintf(fmt, arg_ptr);
	va_end(arg_ptr);

will do the trick.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
From: strider@concour.cs.concordia.ca (GEORGAKAKIS peter)
Newsgroups: comp.std.c
Subject: C Coding standard wanted.
Date: 29 Jul 92 21:53:15 GMT
Distribution: na
Organization: Concordia University, Montreal, Quebec

Hi,

I am looking for a C coding standard.  If you have one that you can share or
know were to get one (from ftp) I would appreciate it very much.  I can be
reached at strider@cs.concordia.ca


Peter Georgakakis
strider@cs.concordia.ca
From: boyne@hplvec.LVLD.HP.COM (Art Boyne)
Date: Mon, 20 Jul 1992 14:55:05 GMT
Subject: Re: volatile qualifier
Organization: Hewlett-Packard Co., Loveland, CO
Newsgroups: comp.std.c

One caveat, though, regarding volatile.  The ANSI standard does not
impose any particular implementation on how the compiler handles
volatile.  And one very well-known PC-based compiler has a rather
stupid definition.  Given then code segment:

    #define device_register (*(volatile int*)12345)	/* some address */
    #define MASK 0x400

    if (device_register & MASK)
	    ...

the compiler, realizing that MASK only affects the upper byte of the
16-bit device register, "optimizes" the register access, and does
an 8-bit access.  Now it just happens that the hardware only supports
16-bit access and gives a bus error on 8-bit access....

Art Boyne, boyne@hplvla.lvld.hp.com
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: Character arrays in structures and address alignment -- any standard?
Date: 28 Jul 92 16:20:16 EDT

smayo@wang.com (Scott Mayo) writes:
>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 topic here is what the Standard does and doesn't allow.  The usual way
of inferring a restriction or requirement when it is too subtle to read
directly from the Standard is to demonstrate a program which is strictly
conforming but which does not behave in the expected way if the proposed
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.

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

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

After all, the Standard explicitly does not describe "the mechanism by which
C programs are invoked for use by a data-processing system", but this does not
therefore imply that a conforming system may *not* invoke C programs...
Newsgroups: comp.std.c
From: bill@twwells.com (T. William Wells)
Subject: Re: Aligning an arbitrary pointer?
Organization: None, Mt. Laurel, NJ
Date: Fri, 24 Jul 1992 19:00:12 GMT

In article <14les7INN4m@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
: 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.

Yes, that works. However, if the object is malloced, you don't
even need the union.

There's an awful lot of gobbledygook about this in the standard
but when all is said and done, the standard has eliminated the
notion that all objects are contained in a single address space.
However, each object still behaves as if it were a single address
space in the style to which we had become accustomed, with
increasing and contiguous addresses (in char*s) and the object's
alignment is determined by how it came into being. Malloced
objects are aligned with the strongest restriction possible in the
implementation.

Once you have an object, so long as you keep your pointers within
it (or at the end, provided you don't dereference the pointer)
and never generate an pointer with an alignment that is
incompatible with the alignment associated with its type, you can
do all the old pointer manipulation tricks we've all come to know
and love.

Suppose that you have a malloced area and a char pointer within
it. You suppose that the pointer points to the start of or to a
byte within some array element and you want to find the start of
the array element. This works:

	(array *)((char *)area +
		  (pointer - (char *)area)
		    / sizeof(array[0])
		    * sizeof(array[0]))

Watch out for ptrdiff_t oddities, though. (If those are a problem,
one is reduced to a certain amount of searching.)

---
Bill                            { uunet | decwrl | telesci }!twwells!bill
bill@twwells.com
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: Mon, 27 Jul 1992 18:36:22 GMT

duane@anasazi.com (Duane Morse) writes:

|  struct {
|    char a[3];
|    char b[2];
|  } x;

|On the 5 different Unix machines in our building, 'b' always starts 3
|bytes after 'a'; the compiler is smart enough to know that it is both
|legal and proper to leave the start of 'b' on an odd byte boundary.

|But is that a standard or a requirement?

The Standard allows arbitrary padding between fields and after the
last field.  You cannot rely on the offset of member 'b' being the
same on different implementations.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.std.c
From: kbass@gmuvax2.gmu.edu (Ken Bass)
Subject: Help with bit and byte addressable bitfields
Organization: George Mason University, Fairfax, Va.
Distribution: na
Date: Sun, 26 Jul 1992 04:39:00 GMT

I'd like to know your suggestions on how to define and access a bitfield
that is both bit and byte addressable. The application is to maintain a
ram image in a memory mapped i/o system.

Lets say we have WidgetRamImg of type WidgetRamImgDef where

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.
Casting to WidgetRamImgDef does not work either.

Any suggestions?

-- 
Ken Bass (kbass@gmuvax2.gmu.edu)              |   Telecommunications  
George Mason University                       |   Techniques Corp, 
Student, Department of Electrical Engineering |   Software Engineer