How ignominious...

G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

Died on the Wizard Quest. Because I was too impatient to stay around in
the temple of Thoth and get the Magicbane. The Dark One got me because I
didn't have enough curse-absorption or something when I whacked him with
the +5 Sting, which was the best I had.

It left a bones file on the locate level, though; probably without the
Dark One and with my overstuffed pack (but not the spellbooks or the wand
of cancellation; they were safe in Sokoban).

Raisse, killed by the Dark One

--
irina@valdyas.org LegoHack: http://www.valdyas.org/irina/nethack/
Status of Raisse (piously neutral): Level 8 HP 63(67) AC -3, fast.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

Raisse the Thaumaturge wrote:
> Died on the Wizard Quest. Because I was too impatient to stay around in
> the temple of Thoth and get the Magicbane. The Dark One got me because I
> didn't have enough curse-absorption or something when I whacked him with
> the +5 Sting, which was the best I had.

You got killed by a curse? I don't understand, are there circumstances
in which they do damage? When it comes to other spells, as a Wizard,
unless something went dreadfully wrong you should still have a cloak of
magic resistance?


> It left a bones file on the locate level, though; probably without the
> Dark One and with my overstuffed pack (but not the spellbooks or the wand
> of cancellation; they were safe in Sokoban).

Wow. It would be so cool to run into someone else's Quest bones level
through Hearse....

- John H.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

Raisse the Thaumaturge wrote:
>
> Died on the Wizard Quest. Because I was too impatient to stay around in
> the temple of Thoth and get the Magicbane. The Dark One got me because I
> didn't have enough curse-absorption or something when I whacked him with
> the +5 Sting, which was the best I had.

One of my chaotic wizards recently completed the Quest. He
turned out very over prepared. +1 Magicbane, +4 Stormy,
10 elven daggers at Expert, finger of death from getting
crowned, lots of spells, several attack wands. White
dragon mail (white, red, yellow only ones encountered so
far and only wish spent on "oR).

He threw a potion of paralysis to have a couple of moves
to soften up the Dark One before the main battle. Cast
finger of death, done. Huh, the Dark One was not
resistant. Collect stuff, head back up.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

Douglas Henke wrote:
> Andrew Kerr <andykerr@SPAMGUARD.blueyonder.co.uk> writes:
> > YANI - standard bones file format across platforms. Surely such a thing
> > has been discussed before?
>
> See for example <x6is2kmezf.fsf@kharendaen.krall.org>. Executive
> summary: do-able, will take work, apt to inflate either storage or
> processor load to the detriment of those playing on embedded systems.

Alright then, how about a "bones converter" that can take in a bones
file from any platform and spit out a file suitable for (a compatible
version of nethack on) another given platform. Wouldn't that be
do-able?

Stick this onto the hearse server and you can share your bones with
just about anyone, regardless of their loafstyle choices.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

John H. wrote:

> Raisse the Thaumaturge wrote:
>> Died on the Wizard Quest. Because I was too impatient to stay around in
>> the temple of Thoth and get the Magicbane. The Dark One got me because
>> I didn't have enough curse-absorption or something when I whacked him
>> with the +5 Sting, which was the best I had.
>
> You got killed by a curse? I don't understand, are there circumstances
> in which they do damage? When it comes to other spells, as a Wizard,
> unless something went dreadfully wrong you should still have a cloak of
> magic resistance?

I had a cloak of magic resistance, but he (she? couldn't know because I
didn't kill him/her) disintegrated my gauntlets of power, taking away all
my damage bonus because I was back at STR 9.

>> It left a bones file on the locate level, though; probably without the
>> Dark One and with my overstuffed pack (but not the spellbooks or the
>> wand of cancellation; they were safe in Sokoban).
>
> Wow. It would be so cool to run into someone else's Quest bones level
> through Hearse....

You wouldn't be able to use my quirky self-compiled Linux bones file, even
if I *did* use Hearse. I tried exchanging bones with someone with
*almost* the same installation a while ago, but they weren't compatible.

Raisse, killed by the Dark One

--
irina@valdyas.org LegoHack: http://www.valdyas.org/irina/nethack/
Status of Raisse (piously neutral): Level 8 HP 63(67) AC -3, fast.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

Raisse the Thaumaturge wrote:
> John H. wrote:
>> Raisse the Thaumaturge wrote:

>>> The Dark One
>>> got me because I didn't have enough curse-absorption or something

>> You got killed by a curse? I don't understand, are there
>> circumstances in which they do damage?

> I had a cloak of magic resistance, but he (she? couldn't know because
> I didn't kill him/her) disintegrated my gauntlets of power, taking
> away all my damage bonus because I was back at STR 9.

But (a cloak of) magic resistance should protect you from attacks that
destroy your armour...

--
Boudewijn.

--
"I have hundreds of other quotes, just waiting to replace this one
as my signature..." - Me
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

In article <1124094525.369280.255640@z14g2000cwz.googlegroups.com>, John
H. says...

> Wow. It would be so cool to run into someone else's Quest bones level
> through Hearse....

I've exhanged priestly quest bones over Windows hearse. Not got there
yet; one >level 14 Priest tried clearing out the Dungeons down to Medusa
first (very few items for one thing) when a combination of carelessness,
cockiness and forgetting about the E-word resulted in YASD at the
Castle. I shall not be making the same mistakes again.

My current Priest is going well and should find them. His main problem
ATM is deciding what skills to advance.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

In article <43005c22$0$11066$e4fe514c@news.xs4all.nl>, Raisse the
Thaumaturge says...
> You wouldn't be able to use my quirky self-compiled Linux bones file, even
> if I *did* use Hearse. I tried exchanging bones with someone with
> *almost* the same installation a while ago, but they weren't compatible.
>
> Raisse, killed by the Dark One
>
>

YANI - standard bones file format across platforms. Surely such a thing
has been discussed before?
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

Boudewijn Waijers wrote:

> Raisse the Thaumaturge wrote:

>> I had a cloak of magic resistance, but he (she? couldn't know because
>> I didn't kill him/her) disintegrated my gauntlets of power, taking
>> away all my damage bonus because I was back at STR 9.
>
> But (a cloak of) magic resistance should protect you from attacks that
> destroy your armour...

Yes, so it should, come to think of it. I must have taken it off for some
reason. Ah well, in that case it's a simple YASD.

(the next W is now trying frantically to become level 14 to see if she hit
the bones pile, so she can get the SDSM and the bag with 27 potions of
holy water-- she does have a wand of cancellation, but I'd rather have
cursed +2 than uncursed +0 SDSM)

Raisse, killed by the Dark One

--
irina@valdyas.org LegoHack: http://www.valdyas.org/irina/nethack/
Status of Raisse (piously neutral): Level 8 HP 63(67) AC -3, fast.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

Andrew Kerr <andykerr@SPAMGUARD.blueyonder.co.uk> writes:
> YANI - standard bones file format across platforms. Surely such a thing
> has been discussed before?

See for example <x6is2kmezf.fsf@kharendaen.krall.org>. Executive
summary: do-able, will take work, apt to inflate either storage or
processor load to the detriment of those playing on embedded systems.
 

Alexis

Distinguished
Oct 28, 2001
157
0
18,680
Archived from groups: rec.games.roguelike.nethack (More info?)

andykerr@SPAMGUARD.blueyonder.co.uk wrote:
> YANI - standard bones file format across platforms. Surely such a thing
> has been discussed before?

Many, many times. But those sort of discussions never seem to result in
anything getting done. Which is a pity because it *is* a good idea,
just a shedload of work.

Take something like Hearse, which is pretty straightforward - searching
Google, I found discussions of a 'bones file exchanger' back in 1995.
It was probably discussed before that as well, but I wasn't interested
enough to spend hours looking into it.

Seems that there's lots of good ideas out there which everyone thinks
someone else should code :)

-- A.

--
My email address is hearse[AT]hotpop[DOT]com

Hearse Windows/Unix client: http://hearse.krollmark.com
Hearse announcements: http://groups.yahoo.com/group/hearseannounce
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

In article <x6ll33ff0k.fsf@kharendaen.krall.org>, Douglas Henke says...
> Andrew Kerr <andykerr@SPAMGUARD.blueyonder.co.uk> writes:
> > YANI - standard bones file format across platforms. Surely such a thing
> > has been discussed before?
>
> See for example <x6is2kmezf.fsf@kharendaen.krall.org>. Executive
> summary: do-able, will take work, apt to inflate either storage or
> processor load to the detriment of those playing on embedded systems.
>

Include a comiler option for either old format or new cross platform
format to solve the embedded issue. They're not going to be using Hearse
anyway.

That's an interesting thread. I'll have to think about whether I'd
prefer bzipped XML or fixed binary format.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

> Include a comiler option for either old format or new cross platform
> format to solve the embedded issue. They're not going to be using Hearse
> anyway.

/me immediately finds that Hearse supports Psion Nethack
 

Alexis

Distinguished
Oct 28, 2001
157
0
18,680
Archived from groups: rec.games.roguelike.nethack (More info?)

dogscoff@eudoramail.com wrote:
> Alright then, how about a "bones converter" that can take in a bones
> file from any platform and spit out a file suitable for (a compatible
> version of nethack on) another given platform. Wouldn't that be
> do-able?

That would be a potential bugfest - it'd be easier (I think) to design a
new flexible bones file format and use that one in future versions.


> Stick this onto the hearse server and you can share your bones with
> just about anyone, regardless of their loafstyle choices.

If anyone is working on such a converter and needs a supply of bones
from a few different versions to try and roundtrip, please let me know.

-- A.

--
My email address is hearse[AT]hotpop[DOT]com

Hearse Windows/Unix client: http://hearse.krollmark.com
Hearse announcements: http://groups.yahoo.com/group/hearseannounce
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

dogscoff@eudoramail.com writes:
> Alright then, how about a "bones converter" that can take in a bones
> file from any platform and spit out a file suitable for (a compatible
> version of nethack on) another given platform. Wouldn't that be
> do-able?

Bones format is sensitive to more than just platform. Every possible
combination of platform, architechture, compiler version, compiler
flags, build options, link libraries and system headers can
potentially have a different file format. (And, I'm probably
forgetting stuff.)

I don't think it would be possible to unambiguously autodetect the
record layout in every case, either.

Having a "convert native bones files to and from portabones format"
utility which gets built alongside of nethack (a la "recover") might
be do-able, given that it would implicitly know the on-disk
representation of all the relevant structures (as it gets built at the
same time using the same toolchain).

It might also work to generate a machine-readable description of
native bones-file format at build time, and send the "magic decoder
ring" file to Hearse along with the bones. (I'm thinking here about
some sort of list of "field X starts at byte offset Y, is Z bytes
long, and has foo endianness" for every field...)

Building something on _my_ system that can grok _your_ native bones
files is, like, hard and stuff.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

In article <x64q9rkmr5.fsf@kharendaen.krall.org>, Douglas Henke says...
....
> Having a "convert native bones files to and from portabones format"
> utility which gets built alongside of nethack (a la "recover") might
> be do-able, given that it would implicitly know the on-disk
> representation of all the relevant structures (as it gets built at the
> same time using the same toolchain).

Users of e.g. Psion Nethack would I assume be uploading bones files from
Win/Linux/MacOS, so either the Psion would have to do the conversion or you'd
have to cross compile.

>
> It might also work to generate a machine-readable description of
> native bones-file format at build time, and send the "magic decoder
> ring" file to Hearse along with the bones. (I'm thinking here about
> some sort of list of "field X starts at byte offset Y, is Z bytes
> long, and has foo endianness" for every field...)

Sounds like a good idea to me. The conversion program/library can be portable.
The file format spec in e.g. XML. The Hearse client can then convert on
transfer.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

Alexis wrote:
> andykerr@SPAMGUARD.blueyonder.co.uk wrote:
>
>>YANI - standard bones file format across platforms. Surely such a thing
>>has been discussed before?
>
>
> Many, many times. But those sort of discussions never seem to result in
> anything getting done. Which is a pity because it *is* a good idea,
> just a shedload of work.
>
> Take something like Hearse, which is pretty straightforward - searching
> Google, I found discussions of a 'bones file exchanger' back in 1995.
> It was probably discussed before that as well, but I wasn't interested
> enough to spend hours looking into it.
>
> Seems that there's lots of good ideas out there which everyone thinks
> someone else should code :)

I was working on it but then I stubled into a problem that no-one seemd
to know what was the cause so I've stopped working on it.

But to recap:

I have made a program that takes the native bones format and translates
it to a 8-bit proprietary coded format. Or takes the proprietary coded
format and translates it back to the native bones format.

The problem lies on the look of the dungeon.

Now in rm.h the structure rm is defined. This structure is what holds
all the information on a coordination position on the map of nethack and
it is:

*
* The structure describing a coordinate position.
* Before adding fields, remember that this will significantly affect
* the size of temporary files and save files.
*/
struct rm {
int glyph; /* what the hero thinks is there */
schar typ; /* what is really there */
uchar seenv; /* seen vector */
Bitfield(flags,5); /* extra information for typ */
Bitfield(horizontal,1); /* wall/door/etc is horiz. (more typ info) */
Bitfield(lit,1); /* speed hack for lit rooms */
Bitfield(waslit,1); /* remember if a location was lit */
Bitfield(roomno,6); /* room # for special rooms */
Bitfield(edge,1); /* marks boundaries for special rooms*/
};

Now the bones saving code before it saves the map does the following:

/* Clear all memory from the level. */
for(x=0; x<COLNO; x++) for(y=0; y<ROWNO; y++) {
levl[x][y].seenv = 0;
levl[x][y].waslit = 0;
levl[x][y].glyph = cmap_to_glyph(S_stone);
}

So when the level information is saved every seenv and waslit are 0 and
every glyph is stone. My translator program doesn't save this info into
the proprietary format but the retranslation restores the cleared
information to the rm structures before saving the native code format.

The other fields:

schar typ; /* what is really there */
Bitfield(flags,5); /* extra information for typ */
Bitfield(horizontal,1); /* wall/door/etc is horiz. (more typ info) */
Bitfield(lit,1); /* speed hack for lit rooms */
Bitfield(roomno,6); /* room # for special rooms */
Bitfield(edge,1); /* marks boundaries for special rooms*/

are converted to unsigned chars by copying so schar -127 will become 255
before saved into the proprietary format file. Upon retranslation they
are read as unsigned chars and cast to the proper format.

The problem is that when the retranslated bones file is read in then no
left and bottom room walls are shown unless you see them from the other
side and the (cannot remember which way it was but either or) the
downstairs looks like upstairs (or vice verse cannot remember).
Everything works alright but doesn't look good.

If somebody can shed some light to this issue I'd certainly open up that
project.

Topi

P.S. I've actually succeeded to translate bones files to the itermediate
format and back even though they've got very problematic object <->
monster combinations. A monster is carrying a statue of the quest leader
that had when stoned a robe (or whatever).

Same
--
"The whole problem with the world is that fools and fanatics are
always so certain of themselves, but wiser people so full of doubts."
- Bertrand Russell
"How come he didn't put 'I think' at the end of it?" - Anonymous
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

Douglas Henke wrote:

> dogscoff@eudoramail.com writes:
>
>>Alright then, how about a "bones converter" that can take in a bones
>>file from any platform and spit out a file suitable for (a compatible
>>version of nethack on) another given platform. Wouldn't that be
>>do-able?
>
>
> Bones format is sensitive to more than just platform. Every possible
> combination of platform, architechture, compiler version, compiler
> flags, build options, link libraries and system headers can
> potentially have a different file format. (And, I'm probably
> forgetting stuff.)
>
> I don't think it would be possible to unambiguously autodetect the
> record layout in every case, either.
>
> Having a "convert native bones files to and from portabones format"
> utility which gets built alongside of nethack (a la "recover") might
> be do-able, given that it would implicitly know the on-disk
> representation of all the relevant structures (as it gets built at the
> same time using the same toolchain).
>
> It might also work to generate a machine-readable description of
> native bones-file format at build time, and send the "magic decoder
> ring" file to Hearse along with the bones. (I'm thinking here about
> some sort of list of "field X starts at byte offset Y, is Z bytes
> long, and has foo endianness" for every field...)
>
> Building something on _my_ system that can grok _your_ native bones
> files is, like, hard and stuff.


The conversion program that I was (or am) working on is not backward or
forward compatible unless the native bones are. So it follows in that
sense the vanilla nethack code except that it would enable cross
compilation platform compatibility of bones.

If you change conditional compilation directives that affect the major
version then no dice. I'm btw. hoping that the DevTeam will adopt the
stand that enabling SCORE_ON_BOTL is not a major change as it is not
game dependent but instance dependent information.

I _was_ thinking about a forward compatible format of the intermediate
file format but decided that it's not something I want to do in the
first version and frankly I'm not sure if we want to load bones that has
to be fitted into the mold of our future version of nethack.

Vision what you'd have to do to read Slashem bones to vanilla or vice
versa. I don't mean technically but decision based: what to do to the
items or monster or whatever that the other game doesn't understand?
Tecnically this could be easy as there is already routines that enable
item, monster and dungeon feature generation from a textual descrption.

So I decided to make a format that handles the little-endian big-endian
things etc. but leaves the features to be accepted by the version number.

This would mean that there is no exchange of bones between systems where
one has compiled TOURIST in and the other one hasn't. But there isn't
today so nothing would be compromised.

Topi
--
"The whole problem with the world is that fools and fanatics are
always so certain of themselves, but wiser people so full of doubts."
- Bertrand Russell
"How come he didn't put 'I think' at the end of it?" - Anonymous
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

Raisse the Thaumaturge wrote:

>
>
> You wouldn't be able to use my quirky self-compiled Linux bones file, even
> if I *did* use Hearse. I tried exchanging bones with someone with
> *almost* the same installation a while ago, but they weren't compatible.
>
> Raisse, killed by the Dark One
>

Have you tried using the Hide features from bones patch?

http://www.netsonic.fi/~walker/nh/showscore_hide.diff or the combined
patch: http://www.netsonic.fi/~walker/nh/nh343jl.diff that contains it?

Reading the recent posts about Hearse gave me incentive to try that out
and see if it worked for me.

That seemed to fix my compatibility with Hearse (uploaded my first bones
not long ago) and I'm running NH on a Playstation 2 Linux kit.


CronoCloud (Ron Rogers Jr.)
 

Alexis

Distinguished
Oct 28, 2001
157
0
18,680
Archived from groups: rec.games.roguelike.nethack (More info?)

nes@iki.fi wrote:
> I _was_ thinking about a forward compatible format of the intermediate
> file format but decided that it's not something I want to do in the
> first version and frankly I'm not sure if we want to load bones that has
> to be fitted into the mold of our future version of nethack.
>
> Vision what you'd have to do to read Slashem bones to vanilla or vice
> versa. I don't mean technically but decision based: what to do to the
> items or monster or whatever that the other game doesn't understand?

On the face of it that part seems pretty straightforward - either dump
the creature / object or, if the type is recognised, replace it with one
of the same type, e.g. 'a ring of fish control --> a random ring'.

-- A.

--
My email address is hearse[AT]hotpop[DOT]com

Hearse Windows/Unix client: http://hearse.krollmark.com
Hearse announcements: http://groups.yahoo.com/group/hearseannounce
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

Andrew Kerr wrote:

> In article <x64q9rkmr5.fsf@kharendaen.krall.org>, Douglas Henke
> says... ...
>> Having a "convert native bones files to and from portabones format"
>> utility which gets built alongside of nethack (a la "recover") might
>> be do-able, given that it would implicitly know the on-disk
>> representation of all the relevant structures (as it gets built at
>> the same time using the same toolchain).
>
> Users of e.g. Psion Nethack would I assume be uploading bones files
> from Win/Linux/MacOS, so either the Psion would have to do the
> conversion or you'd have to cross compile.

Yes, and cross compiling Nethack is already a bit of a pain. For a long
time the Psion Nethack got the magic numbers wrong in its save files: this
was because the magic number is generated by the makedefs program on the
machine doing the build, and has the values for that compiler. The cross
compiled nethack program just uses the magic number from the generated
header file, and there isn't an easy way to get a Microsoft Visual C/C++
version of makedefs.exe to produce output matching an ARM compiler.

Producing an MSVC program which can read all the data structures saved on
the Psion could be an interesting exercise. Actually, I'm not sure you need
a portabones format at all.

You would need to write a program which recognises the appropriate magic
numbers, has a table describing the structure layouts that match each magic
number, and can then load the data adapting to the different table formats.
Once you have done that you can convert any format to the correct one for
the current machine, so you might as well just write the bones file out
again in the local format. The tricky bit would be doing it without having
to copy all the existing save machinery.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

Duncan Booth <duncan.booth@invalid.invalid> writes:
> header file, and there isn't an easy way to get a Microsoft Visual C/C++
> version of makedefs.exe to produce output matching an ARM compiler.

Your mention of MS attracts a Linux weenie. --More--
"Here's a quarter, go buy a real compiler." --More--

> You would need to write a program which recognises the appropriate magic
> numbers, has a table describing the structure layouts that match each magic
> number,

A magic number uniquely identifies what fields are there, and what each
value of a given field means. It does not tell you about representation
(width and endianness, for integers) nor does it tell you where to find
that representation within the overall structure.

Compilers may arbitrarily add padding within the structure, and may
do so differently given, e.g., different optimization flags. ("gcc -O2"
may put fields at different offsets than "gcc -O3".)

I can't even find anything in the standard that says the in-memory
positions of fields in a structure have to be in the same _order_
that they are in the declaration, though neither can I produce a real
example which permutes the order.

Suffice it to say that you can have bones with the same magic, same
endianness and same width of all integral types, but which are nonetheless
incompatible.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

Dovglas Henke wrote:

> Dvncan Booth <dvncan.booth@invalid.invalid> writes:
>> header file, and there isn't an easy way to get a Microsoft Visval
>> C/C++ version of makedefs.exe to prodvce ovtpvt matching an ARM
>> compiler.
>
> Yovr mention of MS attracts a Linvx weenie. --More--
> "Here's a qvarter, go bvy a real compiler." --More--
>
I think my main point there may have escaped yov. Nethack isn't set vp
for cross compiling. It doesn't matter whether yov are vsing MSVC+GCC,
or cross compiling jvst with GCC bvt onto a different architectvre.
Either way, the valves generated by makedefs match the host system
rather than the target system.

>> Yov wovld need to write a program which recognises the appropriate
>> magic nvmbers, has a table describing the strvctvre layovts that
>> match each magic nvmber,
>
> A magic nvmber vniqvely identifies what fields are there, and what
> each valve of a given field means. It does not tell yov abovt
> representation (width and endianness, for integers) nor does it tell
> yov where to find that representation within the overall strvctvre.

Which is why I said yov wovld need a table mapping the magic nvmbers
back to the strvctvre layovt. The version information ovtpvt by makedefs
inclvdes strvctvre sizes, so different field widths or padding rvles
will tend to vary the valve. The valves actvally written to bones files
are written in the native byte order of the target system, so the
endianness is also (effectively) encapsvlated. The vpshot is that the
valve is not gvaranteed vniqve for a particvlar layovt, bvt different
layovts will rarely give a conflicting resvlt.

>
> Compilers may arbitrarily add padding within the strvctvre, and may
> do so differently given, e.g., different optimization flags. ("gcc
> -O2" may pvt fields at different offsets than "gcc -O3".)
>
> I can't even find anything in the standard that says the in-memory
> positions of fields in a strvctvre have to be in the same _order_
> that they are in the declaration, thovgh neither can I prodvce a real
> example which permvtes the order.

How abovt (from 6.7.2.1 Strvctvre and vnion specifiers, constraint nvmber
12):

Within a strvctvre object, the non-bit-field members and the vnits in
which bit-fields reside have addresses that increase in the order in
which they are declared. A pointer to a strvctvre object, svitably
converted, points to its initial member (or if that member is a
bit-field, then to the vnit in which it resides), and vice versa. There
may be vnnamed padding within a strvctvre object, bvt not at its
beginning.

[That's from a committee draft I fovnd on the web, sorry don't have a
recent copy of the C standard to hand]

>
> Svffice it to say that yov can have bones with the same magic, same
> endianness and same width of all integral types, bvt which are
> nonetheless incompatible.
>
In theory yes, bvt for that to happen yov have to have moved fields
within a strvctvre withovt changing the overall size of the strvctvre,
and that has to hold for all 4 strvctvres vsed in calcvlating the magic
nvmber.

Hearse seems to svrvive on identifying the type of bones files by the
magic nvmber, the only time I know where that scheme has gone wrong was
when Psion svpport was being added, and that was becavse the Psion
version was ovtpvtting the wrong nvmbers.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

Dvncan Booth <dvncan.booth@invalid.invalid> writes:
> Dovglas Henke wrote:
> > Yovr mention of MS attracts a Linvx weenie. --More--
> > "Here's a qvarter, go bvy a real compiler." --More--
> >
> I think my main point there may have escaped yov. Nethack isn't set vp
> for cross compiling.

No, I vnderstood. I was jvst being silly.

> > I can't even find anything in the standard that says the in-memory
> > positions of fields in a strvctvre have to be in the same _order_
> > that they are in the declaration, thovgh neither can I prodvce a real
> > example which permvtes the order.
>
> 6.7.2.1 Strvctvre and vnion specifiers, constraint nvmber 12

Thanks, that's the one. (It also forbids padding at the start of the
strvctvre, which I'd forgotten abovt.)