At 5:59 PM +0200 on 7/21/99, M. Uli Kusterer wrote:
>>Multi-character constants are not allowed. Why are there any in XBlockFile?
>>We should do this in a compatable manner. An enum would be better -- one
>>that uses integers, not character constants.
>
>Anthony,
>
> it eases debugging if field types are character constants. You see 'MAP '
>and instantly know that this must be part of the block entry for the map.
>I've added a workaround, tell me if it helps.
Is the new source on the server? I'll test it sometime soon.
But, for the record, use 0x4d415020ul for 'MAP '.
>
>>And what kind of coding is that? What's wrong with a for loop? Why code
>>around it?
>
> Oops. Sorry, that's a bad habit of mine. Consider them replaced through
>"for"s.
Ok. You made me thing there was something there I was missing...
>
>>XEndianFile.h: At top level:
>>XEndianFile.h:71: warning: `long int sTypeSizes[6]' defined but not used
>>XEndianFile.h:77: warning: `long int sTypeBounds[3]' defined but not used
>>
>>What are these structs for? And powerc needs to be documented. Any other
>>preprocessor things to document? Hmmm.... I'll grep it.
>
>They belong in the .cpp file, sorry. They're there so XBlockFile's
>templates can correctly walk data structures. See WriteStruct() and
>ReadStruct() (and where XBlockFile uses those) for an example. These are
>platform dependent, you put the following into sTypeSizes:
>
><size of packed char>, <size of char as struct field>, <size of packed
>short>, <size of short as struct field>, <size of packed long>, <size of
>long as struct field>
>
>The SFT_* constants are indexes into this array.
>sTypeBounds contains a list on which boundaries the specified types are to
>be aligned:
>
><align char on>, <align short on>, <align long on>
Why not just use a dang enum or some defines?! What's with the structs?
Or better, how about platform-specific read/write functions?
>
>I hope you know how the linux compiler aligns structures in RAM ? Can you
>send me the conditional for that? It's different for 680x0 and PowerPC, and
>I guess it also will be for PowerPC.
>
>>DATA_CHUNK_SIZE -- self evident, but did not know about it with
>> -- grep.
>
> Umm what does this mean? Could you re-phrase? What does grep do?
Grep searches the contents of files for a pattern. I had to grep for all
the times that you used "#if" to find it.
>>TRUE -- these are C++ keywords. Try "true" and "false"
>>FALSE
>
> Pardon? I thought TRUE and FALSE were the new standard for C++ booleans,
>since CW didn't declare them I thought I'd do it when they're missing.
No. "true" and "false" are the keywords. They are lowercase, only.
>"true" and "false" are Macintosh-specific, I thought. Is it different
>actually?
Yes. The Mac headers define true and false when the compiler does not have
support for them.
MPW supports them (option "-bool on") and I'm betting CodeWarrior does,
too. Egcs does.
>>/usr/lib/crt1.o(.text+0xb0): undefined reference to `main'
>>collect2: ld returned 1 exit status
>>
>>Hmmm.... were we supposed to get a test suite?
>
>What do you mean? Let me guess ... egcc doesn't find main()? It's declared
>as int main(void) in HelloWorld.cpp. What does egcc expect?
I must not of compiled HelloWorld.cpp...don't know how...I'll have to try
again.
