0

I'm trying to get my old filemanager program that I coded years ago with ncurses as a school project to run (the code is not great, might be a good exercise for some refactoring). I created it on Ubuntu, doesn't work on my Macbook. Can't figure out the difference that makes it work on one system, but not the other.

Works fine on Linux: https://imageshack.com/a/img922/8487/1Atzsx.jpg

But OSX does not display the file names correctly: https://imageshack.com/a/img923/3640/CeRzCm.png

Neither do the type descriptions which are hardcoded based on the d_type from readdir.

At first I thought that there might be an issue with wide character support from ncurses. This should be supported by default on OSX, but to be sure I installed the lastest ncurses from Homebrew. Didn't help.

The file names are obtained in this way and saved into objects:

struct dirent *ent;
DIR *dir;
if((dir = opendir(path.c_str())) != NULL) {
    for(auto it = m_files.begin(); it != m_files.end(); ++it) {
        delete *it;
    }
    m_files.clear();

    while((ent = readdir (dir)) != NULL) {

        if(ent->d_type==DT_DIR) {
            if(!root) {
                m_files.push_back( new CDirectory(ent->d_name, path+"/"+ent->d_name) );
            }else{
                m_files.push_back( new CDirectory(ent->d_name, path+ent->d_name) );
            }
        }

These objects are then accessed to create items for the ncurses menu. Valgrind detects memory leaks here (not happening with the same code on Ubuntu).

void CSelection::CreateItems () {

    size_t number_of_choices = m_files.size();
    size_t i;

    m_items = (ITEM **)calloc(number_of_choices+1, sizeof(ITEM *));
    for(i = 0; i < number_of_choices; i++) {
        m_items[i] = new_item(m_files[i]->GetName().c_str(), m_files[i]->GetType().c_str());
    }
    m_items[i] = NULL;
}

After some research I think that I have the same problem as here: https://github.com/rust-lang/libc/issues/414 , but I'm stuck on implementing the fix.

I tried including this code (found here: https://forums.coronalabs.com/topic/53249-link-errors-with-openssl-plugin-when-building-universal-32-64-bit-binaries-for-ios/),

#include <dirent.h>
#include <fnmatch.h>

extern "C" DIR * opendir$INODE64( char * dirName );
DIR * opendir$INODE64( char * dirName )
{
    return opendir( dirName );
}

extern "C" struct dirent * readdir$INODE64( DIR * dir );
struct dirent * readdir$INODE64( DIR * dir )
{
    return readdir( dir );
}

but I get a segmentation fault on those returns.

Any advice? Thanks in advance.

Vojta S.
  • 11
  • 1
  • Possibly, there are objects that have to be constructed rather than allocated-and-memset(0)'d. – Eljay Dec 30 '18 at 18:09
  • I'm not on a Mac until the new year unfortunately otherwise I'd have a play. Potentially an interesting problem! – Lightness Races in Orbit Dec 30 '18 at 18:11
  • 1
    I tried on my machine (Xcode 10.1, Mojave 10.14.2), using opendir and readdir, and `cout << ent->d_name << '\n';`, and it worked correctly (i.e., no funny characters). Could it be that something is in UTF-8 format and ncurses is in "wide" mode (UTF-16 or UTF-32), or vice-versa? – Eljay Dec 30 '18 at 18:33
  • 2
    Okay let's see a [MCVE]. – Lightness Races in Orbit Dec 30 '18 at 18:52
  • Tried a snippet that prints contents of a folder within ncurses (https://pastebin.com/WpSzacqZ). On the same machine with the same settings it works correctly though. So the problem must be somewhere else. Conversions from d_name to string to C string work well too (https://pastebin.com/g92Pp36h). I'll try printing the same folder with ncurses menus once I'll get back online in a few days. – Vojta S. Dec 30 '18 at 22:07
  • In one code snippet, you show `#include`-ing the proper system header, but just to be sure: you **must** include that system header to get the declarations of the system library functions and structures. It is **not** OK to declare them in your own code, even if you think you're doing it right. In particular, on macOS, the system headers may use an `asm()` directive to map the C-language declaration to a different symbol in the library. – Ken Thomases Dec 30 '18 at 22:57
  • I guess what we're learning here is the value of an MCVE ;) – Lightness Races in Orbit Dec 31 '18 at 00:33

0 Answers0