This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Build: ASCII Host: EBCDIC (or vice versa) question.


I've started sketching out some code for the driver's option handling
along the lines I sketched out a couple of months ago.

I have an options definition file, say gcc.opts, which contains the
options and various flags and attributes that go with them.  I want to
pass this through a filter, that produces one or more ".h" or ".def" files
that can be then be #include-d from gcc.c when we compile that file.
One of the things this filter does is calculate hash codes for each
option and put them in a compile-time hash table.  (Or, it may do a
qsort on the options; I've not decided yet which I prefer, though I'm
leaning towards the hash table implementation).

What concerns me is that the sorting or hashing will put things in
some order depending on the charset of the build machine, which may
be different to the charset of the host machine.  This would then give
nonsensical results at runtime, because hash codes and / or the sorted
order don't match.

How do we avoid such issues at present?  Or do we not support
configurations where host / build machines have different charsets?
Does this issue kill my idea at this early stage?

Neil.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]