leo@philmds.UUCP (Leo de Wit) (06/28/88)
In article <734@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes: [stuff about calloc and its drawbacks deleted]... >This has been my approach to a Q&D allocator for some >kind of arbitrary data type: > >/* > * objalloc() > * > * Return one initialized item. > */ > >typedef struct object OBJ; > >OBJ * >objalloc() >{ >static OBJ dummy; /* guaranteed to be "the right" zeros */ >OBJ *p; > > p = (OBJ *)Malloc(sizeof(*p)); /* does error checking internally */ > > *p = dummy; /* do a *real* initialization */ > > return(p); >} Nice idea, but... a) what if you want to initialize several different types? Each type will need its own initialization function. b) If sizeof(OBJ) is large you waste a large variable. No so terrible on a VAX, but what to think of PC's? c) the structure assignment: is that correct (i.e. does ANSI allow it)? K&R says that it 'draws an error message', but 'In the future, it is expected that these operations,...., will be allowed'. d) If b) is not important and a) is, a macro could do the trick: #define OBJALLOC(p,type) \ { \ static type dummy; \ p = (type *)Malloc(sizeof(*p));\ *p = dummy; \ } I'd rather have the compiler supply the functionality, if that was possible , for instance by a keyword that translates to a runtime (evt. inline) function being called with a pointer to the object and a parameter indicating the type (just philosofing). If I'm correct the bss is initialized when an image gets loaded (not yet present in the program file) so there should be functions that provide these initializations. Perhaps someone that is familiar with this stuff cares to comment? Leo.
rpjday@ccu.umanitoba.ca (08/01/90)
I would like to know the official behaviour of the following
initialization code, which seems as if it should blow up one way
or the other:
int func(int a)
{
int i = a, j = i + 1 ;
Am I allowed to initialize the integer "j" with the value of
another variable initialized in the same line? What if I put
the two definitions on separate lines?
Thanks for any info.
R. Day
U of Manitobasteve@taumet.com (Stephen Clamage) (08/01/90)
rpjday@ccu.umanitoba.ca writes: |int func(int a) |{ | int i = a, j = i + 1 ; |Am I allowed to initialize the integer "j" with the value of |another variable initialized in the same line? What if I put |the two definitions on separate lines? According to ANSI C this is fine, and is equivalent in effect to int i = a; int j = i + 1 ; (By "line" above, I assume you meant "declaration".) The end of an initializer is a "sequence point", and must be fully completed before the next initialization (or statement). There may be non-standard compilers which do not follow this rule. -- Steve Clamage, TauMetric Corp, steve@taumet.com
henry@zoo.toronto.edu (Henry Spencer) (08/02/90)
In article <1990Aug1.011654.22068@ccu.umanitoba.ca> rpjday@ccu.umanitoba.ca writes: >{ > int i = a, j = i + 1 ; > >Am I allowed to initialize the integer "j" with the value of >another variable initialized in the same line? ... The scope of the variable `i' starts at the `=' following `i', so it is a perfectly legal variable for use in initializing `j'. (There is nothing illegal about using it in its *own* initialization, in fact, except that since it has no defined value at the time, the effect is undefined.) -- The 486 is to a modern CPU as a Jules | Henry Spencer at U of Toronto Zoology Verne reprint is to a modern SF novel. | henry@zoo.toronto.edu utzoo!henry
jindak@surfside.sgi.com (Chris Schoeneman) (08/02/90)
In article <1990Aug1.011654.22068@ccu.umanitoba.ca> rpjday@ccu.umanitoba.ca writes: >int func(int a) >{ > int i = a, j = i + 1 ; > >Am I allowed to initialize the integer "j" with the value of >another variable initialized in the same line? Of course you're allowed. C doesn't care if "i" is initialized or not! But don't worry, the comma operator is evaluated left to right. So your code will always work correctly (i.e. "a" will be assigned to "i", then "i"+1 will be assigned to "j"). Chris Schoeneman | I was neat, clean, shaved and sober, jindak@surfside.esd.sgi.com | and I didn't care who knew it. Silicon Graphics, Inc. | -Raymond Chandler Mountain View, CA | (The Big Sleep)
shirono@ssd.csd.harris.com (Roberto Shironoshita) (08/02/90)
In article <1990Aug1.170117.21763@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: > In article <1990Aug1.011654.22068@ccu.umanitoba.ca> rpjday@ccu.umanitoba.ca writes: > > int i = a, j = i + 1 ; > > The scope of the variable `i' starts at the `=' following `i', so it is > a perfectly legal variable for use in initializing `j'. Would the comma (,) separating the two variables (i and j) be considered a sequence point then? Or do we have no guarantees as to the value j is initialized to? -- Roberto Shironoshita || Internet: shirono@ssd.csd.harris.com Harris Corporation || Computer Systems Division || UUCP: ...!uunet!hcx1!shirono || DISCLAIMER: The opinions expressed here are my own; they in no way reflect the opinion or policies of Harris Corporation.
chris@mimsy.umd.edu (Chris Torek) (08/02/90)
In article <11221@odin.corp.sgi.com> jindak@surfside.sgi.com (Chris Schoeneman) writes: (re the code `f(int a) { int i = a, j = i + 1;') >... don't worry, the comma operator is evaluated left to right. So your >code will always work correctly (i.e. "a" will be assigned to "i", then >"i"+1 will be assigned to "j"). Strictly speaking, the comma in int i = a, j = i + 1; is not a comma operator. Nonetheless the ANSI C standard guarantees that, after the sequence point at the semicolon, `i' will have the value `a' has and `j' will have the result of `a + 1' (since i==a, i+1 has the same effect as a+1, including such things as runtime traps, at least if overflow is `implementation defined' [I cannot remember whether this is in fact the case]). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
steve@taumet.com (Stephen Clamage) (08/02/90)
shirono@ssd.csd.harris.com (Roberto Shironoshita) writes: |> > int i = a, j = i + 1 ; |Would the comma (,) separating the two variables (i and j) be considered a |sequence point then? Or do we have no guarantees as to the value j is |initialized to? A sequence point occurs after an initialization. A comma as part of a comma-expression marks a sequence point, but the comma here is not such a comma. So this comma could be considered a sequence point in that it marks the end of the initialization expression. -- Steve Clamage, TauMetric Corp, steve@taumet.com
bruce@seismo.gps.caltech.edu (Bruce Worden) (08/04/90)
In article <11221@odin.corp.sgi.com> jindak@surfside.sgi.com (Chris Schoeneman) writes: >In article <1990Aug1.011654.22068@ccu.umanitoba.ca> rpjday@ccu.umanitoba.ca >writes: >>int func(int a) >>{ >> int i = a, j = i + 1 ; >> >>Am I allowed to initialize the integer "j" with the value of >>another variable initialized in the same line? >Of course you're allowed. C doesn't care if "i" is initialized or not! >But don't worry, the comma operator is evaluated left to right. So your >code will always work correctly (i.e. "a" will be assigned to "i", then >"i"+1 will be assigned to "j"). I am under the impression that the commas that separate variables in declarations, like those that separate function arguments, are not comma operators. I am under that impression because it explicitly states that in K&R. Is this statement a mis-statement in the book, or am I misunderstanding the statement? Does the presence of an assignment in a declaration change the comma into a comma operator? sig("Bruce Worden", "bruce@seismo.gps.caltech.edu", "No NeWS is good NeWS");
steve@taumet.com (Stephen Clamage) (08/05/90)
bruce@seismo.gps.caltech.edu (Bruce Worden) writes: >I am under the impression that the commas that separate variables in >declarations, like those that separate function arguments, are not comma >operators. I am under that impression because it explicitly states that >in K&R. ANSI C also states that. You are right, as has been recently posted. -- Steve Clamage, TauMetric Corp, steve@taumet.com
lab@spader.UUCP (Lars Berntzon) (10/04/90)
Hello!
My problem is that i want to initialize two types of struct variables with
the address of the opposit struct.
What i want to do is:
{
struct a {
struct b *b;
variable
.
.
};
struct b {
struct a *a;
other variables
.
.
};
static a = {&b, data ...};
static b = {&a, other data...};
}
I thought of declaring the two structs as extern, but i need (would like) to
have them as static beccause in my application there arent just two structs
but hundreds. Is there any similar way for static declarations as for extern
declarations (ie. declaring, not defining static variables), or is there any
other way to do this initialization ?
Any suggestions how this could be done would be apprecciated.
--------------------------------------------------------------------------------
Lars Berntzon UUCP: mcsun!sunic!spader!lab
CGL Techno
Danmarksg. 46
Swedenbrnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/05/90)
In article <464@spader.UUCP> lab@spader.UUCP (Lars Berntzon) writes: > My problem is that i want to initialize two types of struct variables with > the address of the opposit struct. > static a = {&b, data ...}; > static b = {&a, other data...}; Deja vu... I quote from <18201:Sep2203:25:3190@kramden.acf.nyu.edu>: : > > static struct xtag x = {&y}; : > > static struct ytag y = {&x}; : : A different approach should work under any C compiler, though it may not : be implemented efficiently. It also has the usual syntactic problems of : macros. : : static struct { struct xtag x; struct ytag y; } : shmoe = { &(shmoe.y), &(shmoe.x) } ; : #define x (shmoe.x) : #define y (shmoe.y) : : Caveat: This is untested. But the idea is useful to remember. I think the conclusion of the discussion was that there's no (other) portable solution. ---Dan