small endianness issue in hfsplus code

  • Nathan Hjelm

    Nathan Hjelm - 2002-07-07

    There is a small endianness issue in the hfsplus code. convertEndian should look like this to fix the problem.

    void convertEndian( void *value, int bytes ) {
      unsigned char *temp;
      unsigned char ph;
      int cnt;

      temp = (char *)malloc( bytes );
      memcpy( temp, value, bytes );
      cnt = 0;
      while ( cnt < ( bytes / 2 ) ) {
        ph = temp[cnt];
        temp[cnt] = temp[((bytes-cnt)-1)];
        temp[((bytes-cnt)-1)] = ph;
      memcpy( value, temp, bytes );
      free( temp );

    • Anonymous - 2002-07-08

      Yeah I knew about this....I haven't made the change yet because I am not ready to port it to other platforms yet. It is too hard to keep track off all the issues while the software isn't even ready yet. Can you keep a list of all changes that have to be made to be portable? This way when it is finished we can add the changes and not have to do all the research...


    • John Stracke

      John Stracke - 2002-09-03

      Rather than make up your own BYTE_ORDER macro, it would be better to use the conversion macros that already exist for networking.  They convert between host byte order and network byte order--and network byte order is big-endian, same as the Mac, so that's what you want.

      man htons

      • Anonymous - 2002-09-03

        I actually have issues doing this. The first reason being that it requires the use of networking functions. Though they work, I would rather avoid it to make things less confusing.

        We are actually now using the bswap functions which are in the byteswap.h header. These are much faster then my original function, and work on linux and bsd.

        I like the idea of having my own convertEndian function instead of calling the individual functions directly because I only have one #ifdef BYTE_ORDER line in the convertEndian function and not around every call to bswap or htons.

        The original goal was to write a function that is system independant. In other words I want to rely on as few outside functions as possible to minimize the amount of porting that needs to be done. In other words if hton or bswap didn't exist on a system there would be problems. The next step in convertEndian's evolution is to write a function that is as fast as bswap yet doesn't call outside code. It isn't important and probably won't be done for a while.



Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks