{"thread":{"id":"37048","subject":"Support for EBCDIC","startedAt":"2014-07-03T02:39:12Z","lastAt":"2014-07-03T20:01:01Z","messageCount":3,"participants":["Scott McKellar","Jeff King","Jason Pyeron"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"245365","messageId":"1404355152.86116.YahooMailNeo@web184805.mail.gq1.yahoo.com","threadId":"37048","inReplyTo":null,"subject":"Support for EBCDIC","fromName":"Scott McKellar","fromEmail":"mck9@swbell.net","sentAt":"2014-07-03T02:39:12Z","receivedAt":"2014-07-03T02:39:12Z","isPatch":false,"sender":{"key":"mck9@swbell.net","avatar":null},"body":"Is Git supposed to be usable in an environment where the execution character set is EBCDIC?\n\nI ask because, in browsing the source code (version 2.0.0), I stumbled across three functions \n\nthat won't work as presumably intended in an EBCDIC environment (strihash(), memihash(), and \n\ngit_user_agent_sanitized()).  I can report them as bugs, but if EBCDIC is considered out of \n\nscope, then they aren't bugs.\n\nThese three functions can be readily fixed to make them portable across character sets.  There may be other spots that are harder to fix.\n\nI have done a lot of grepping and Googling, but I haven't found a clear, authoritative answer \n\nto this question.  From searching this mailing list, it appears that nobody is interested in \n\nsupporting EBCDIC.  However I found one wiki page describing how to run Git on an IBM i, which \n\nis an EBCDIC-based successor to the AS/400 series.  See:\n\n    http://wsip-174-79-32-155.ph.ph.cox.net/wiki/index.php/PASE/Git\n\nThat installation was reportedly running version 1.7.9.4, which I believe predates the \n\nintroduction of strihash() and memihash(); I don't know about git_user_agent_sanitized().\n\nMind you, I'm not advocating for EBCDIC.  I escaped from the EBCDIC world about fifteen years \n\nago, and have no desire to return.  I just want to know if character set issues are worth \n\nreporting.  The same issues may arise for other, more obscure character sets.\n\n\nScott McKellar\n"},{"id":"245383","messageId":"20140703173413.GC20571@sigill.intra.peff.net","threadId":"37048","inReplyTo":"1404355152.86116.YahooMailNeo@web184805.mail.gq1.yahoo.com","subject":"Re: Support for EBCDIC","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-07-03T17:34:13Z","receivedAt":"2014-07-03T17:34:13Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jul 02, 2014 at 07:39:12PM -0700, Scott McKellar wrote:\n\n> Is Git supposed to be usable in an environment where the execution character set is EBCDIC?\n\nNot really.\n\nIn addition to the cases you found (and I would be surprised if there\nare not more, such as our reimplementation of ctype.h), we assume:\n\n  - we can intermingle ASCII from string literals with user data to form\n    diffs, commit objects, network protocols, etc. This is actually a\n    problem not just for EBCDIC, but for any encoding which is not an\n    ASCII-superset (like UTF-16).\n\n  - many outputs from git should be ASCII in order to interoperate with\n    the outside world (object headers, network protocols, etc).\n\nSo I'd be surprised if things worked well in an EBCDIC environment (but\nI have never worked with one, so maybe I do not understand all of the\nimplications).\n\n-Peff\n"},{"id":"245388","messageId":"46A5AE733A22492FBD719EE01B20B0E7@black","threadId":"37048","inReplyTo":"20140703173413.GC20571@sigill.intra.peff.net","subject":"RE: Support for EBCDIC","fromName":"Jason Pyeron","fromEmail":"jpyeron@pdinc.us","sentAt":"2014-07-03T20:01:01Z","receivedAt":"2014-07-03T20:01:01Z","isPatch":false,"sender":{"key":"jpyeron@pdinc.us","avatar":"https://gravatar.com/avatar/c2e53452caa53d940768a1ffc9cf76196d851b9b534b7a39cd39852a70a0508f?d=mp&s=160"},"body":"> -----Original Message-----\n> From: Jeff King\n> Sent: Thursday, July 03, 2014 13:34\n> \n> On Wed, Jul 02, 2014 at 07:39:12PM -0700, Scott McKellar wrote:\n> \n> > Is Git supposed to be usable in an environment where the \n> execution character set is EBCDIC?\n> \n> Not really.\n\nIf the core uses specific 8bit values for the internals then there is a hope and\nprayer.\n\nE.g. \"blob\" would need to be char _BLOB={0x62,0x6c,0x6f,0x62} because the hash\ncalculation would be wrong if were {0x82,0x93,0x96,0x82} ensuring the compiler\ndoes not change that \"binary\" data value.\n\n> \n> In addition to the cases you found (and I would be surprised if there\n> are not more, such as our reimplementation of ctype.h), we assume:\n> \n>   - we can intermingle ASCII from string literals with user \n> data to form\n>     diffs, commit objects, network protocols, etc. This is actually a\n>     problem not just for EBCDIC, but for any encoding which is not an\n>     ASCII-superset (like UTF-16).\n\nAnd then all output would require code-page aware translation, but fix the above\nfirst.\n\n> \n>   - many outputs from git should be ASCII in order to \n> interoperate with\n>     the outside world (object headers, network protocols, etc).\n> \n> So I'd be surprised if things worked well in an EBCDIC \n> environment (but\n> I have never worked with one, so maybe I do not understand all of the\n> implications).\n\n--\n-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\n-                                                               -\n- Jason Pyeron                      PD Inc. http://www.pdinc.us -\n- Principal Consultant              10 West 24th Street #100    -\n- +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -\n-                                                               -\n-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\nThis message is copyright PD Inc, subject to license 20080407P00.\n"}]}