nulib2/nufxlib/samples/TestBasic.c

1177 lines
31 KiB
C
Raw Normal View History

2000-05-23 01:55:31 +00:00
/*
* NuFX archive manipulation library
2007-02-19 23:12:22 +00:00
* Copyright (C) 2000-2007 by Andy McFadden, All Rights Reserved.
2000-05-23 01:55:31 +00:00
* This is free software; you can redistribute it and/or modify it under the
2007-02-19 23:12:22 +00:00
* terms of the BSD License, see the file COPYING.LIB.
2000-05-23 01:55:31 +00:00
*
* Test basic features of the library. Run this without arguments.
*/
#include <stdio.h>
#include <ctype.h>
#include "NufxLib.h"
#include "Common.h"
#define kTestArchive "nlbt.shk"
#define kTestTempFile "nlbt.tmp"
2000-05-23 01:55:31 +00:00
#define kNumEntries 3 /* how many records are we going to add? */
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
/* stick to ASCII characters for these -- not doing conversions just yet */
#define kTestEntryBytes "bytes"
#define kTestEntryBytesUPPER "BYTES"
#define kTestEntryEnglish "English"
#define kTestEntryLong "three|is a fairly long filename, complete with" \
"punctuation and other nifty/bad stuff"
#define kLocalFssep '|'
2000-05-23 01:55:31 +00:00
/*
* Globals.
*/
char gSuppressError = false;
#define FAIL_OK gSuppressError = true;
#define FAIL_BAD gSuppressError = false;
2000-05-23 01:55:31 +00:00
/*
* ===========================================================================
* Helper functions
2000-05-23 01:55:31 +00:00
* ===========================================================================
*/
/*
* Get a single character of input from the user.
*/
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
static char TGetReplyChar(char defaultReply)
2000-05-23 01:55:31 +00:00
{
char tmpBuf[32];
2000-05-23 01:55:31 +00:00
2014-12-22 02:17:23 +00:00
if (fgets(tmpBuf, sizeof(tmpBuf), stdin) == NULL)
return defaultReply;
if (tmpBuf[0] == '\n' || tmpBuf[0] == '\r')
return defaultReply;
2000-05-23 01:55:31 +00:00
return tmpBuf[0];
2000-05-23 01:55:31 +00:00
}
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
NuError AddSimpleRecord(NuArchive* pArchive, const char* filenameMOR,
NuRecordIdx* pRecordIdx)
2000-05-23 01:55:31 +00:00
{
NuFileDetails fileDetails;
2000-05-23 01:55:31 +00:00
memset(&fileDetails, 0, sizeof(fileDetails));
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
fileDetails.storageNameMOR = filenameMOR;
fileDetails.fileSysInfo = kLocalFssep;
fileDetails.access = kNuAccessUnlocked;
2000-05-23 01:55:31 +00:00
return NuAddRecord(pArchive, &fileDetails, pRecordIdx);
2000-05-23 01:55:31 +00:00
}
/*
* Display error messages... or not.
*/
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
NuResult ErrorMessageHandler(NuArchive* pArchive, void* vErrorMessage)
2000-05-23 01:55:31 +00:00
{
const NuErrorMessage* pErrorMessage = (const NuErrorMessage*) vErrorMessage;
2000-05-23 01:55:31 +00:00
if (gSuppressError)
return kNuOK;
2000-05-23 01:55:31 +00:00
if (pErrorMessage->isDebug) {
fprintf(stderr, "%sNufxLib says: [%s:%d %s] %s\n",
2014-12-22 02:17:23 +00:00
pArchive == NULL ? "GLOBAL>" : "",
pErrorMessage->file, pErrorMessage->line, pErrorMessage->function,
pErrorMessage->message);
} else {
fprintf(stderr, "%sNufxLib says: %s\n",
2014-12-22 02:17:23 +00:00
pArchive == NULL ? "GLOBAL>" : "",
pErrorMessage->message);
}
2000-05-23 01:55:31 +00:00
return kNuOK;
2000-05-23 01:55:31 +00:00
}
/*
* This gets called when a buffer DataSource is no longer needed.
*/
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
NuResult FreeCallback(NuArchive* pArchive, void* args)
{
free(args);
return kNuOK;
}
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
/*
* If the test file currently exists, ask the user if it's okay to remove
* it.
*
* Returns 0 if the file was successfully removed, -1 if the file could not
* be removed (because the unlink failed, or the user refused).
*/
int RemoveTestFile(const char* title, const char* fileName)
{
char answer;
if (access(fileName, F_OK) == 0) {
printf("%s '%s' exists, remove (y/n)? ", title, fileName);
fflush(stdout);
answer = TGetReplyChar('n');
if (tolower(answer) != 'y')
return -1;
if (unlink(fileName) < 0) {
perror("unlink");
return -1;
}
}
return 0;
}
2000-05-23 01:55:31 +00:00
/*
* ===========================================================================
* Tests
2000-05-23 01:55:31 +00:00
* ===========================================================================
*/
/*
* Make sure the flags that control how we open the file work right,
* and verify that we handle existing zero-byte archive files correctly.
*/
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
int Test_OpenFlags(void)
2000-05-23 01:55:31 +00:00
{
NuError err;
2014-12-22 02:17:23 +00:00
FILE* fp = NULL;
NuArchive* pArchive = NULL;
printf("... open zero-byte existing\n");
fp = fopen(kTestArchive, kNuFileOpenWriteTrunc);
2014-12-22 02:17:23 +00:00
if (fp == NULL) {
perror("fopen kTestArchive");
goto failed;
}
fclose(fp);
2014-12-22 02:17:23 +00:00
fp = NULL;
FAIL_OK;
err = NuOpenRW(kTestArchive, kTestTempFile, kNuOpenCreat|kNuOpenExcl,
&pArchive);
FAIL_BAD;
if (err == kNuErrNone) {
fprintf(stderr, "ERROR: file opened when it shouldn't have\n");
goto failed;
}
err = NuOpenRW(kTestArchive, kTestTempFile, kNuOpenCreat, &pArchive);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: file didn't open when it should have\n");
goto failed;
}
err = NuClose(pArchive);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: close failed\n");
goto failed;
}
2014-12-22 02:17:23 +00:00
pArchive = NULL;
if (access(kTestArchive, F_OK) == 0) {
fprintf(stderr, "ERROR: archive should have been removed but wasn't\n");
goto failed;
}
return 0;
2000-05-23 01:55:31 +00:00
failed:
2014-12-22 02:17:23 +00:00
if (pArchive != NULL) {
NuAbort(pArchive);
NuClose(pArchive);
}
return -1;
2000-05-23 01:55:31 +00:00
}
/*
* Add some files to the archive. These will be used by later tests.
*/
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
int Test_AddStuff(NuArchive* pArchive)
2000-05-23 01:55:31 +00:00
{
NuError err;
uint8_t* buf = NULL;
2014-12-22 02:17:23 +00:00
NuDataSource* pDataSource = NULL;
NuRecordIdx recordIdx;
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
uint32_t status;
int i;
static const char* testMsg =
"This is a nice test message that has linefeeds in it so we can\n"
"see if the line conversion stuff is actually doing anything at\n"
"all. It's certainly nice to know that everything works the way\n"
"it's supposed to, which I suppose is why we have this nifty test\n"
"program available. It sure would be nice if everybody tested\n"
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
"their code, but where would Microsoft be without endless upgrades\n"
"and service packs? Bugs are what America was built on, and\n"
"anybody who says otherwise is a pinko commie lowlife. Verily.\n";
printf("... add 'bytes' record\n");
buf = malloc(131072);
2014-12-22 02:17:23 +00:00
if (buf == NULL)
goto failed;
for (i = 0; i < 131072; i++)
*(buf+i) = i & 0xff;
FAIL_OK;
err = NuCreateDataSourceForBuffer(kNuThreadFormatUncompressed,
2014-12-22 02:17:23 +00:00
0, NULL, 0, 131072, FreeCallback, &pDataSource);
FAIL_BAD;
if (err == kNuErrNone) {
fprintf(stderr, "ERROR: that should've failed!\n");
goto failed;
}
/*
* Create a data source for the big batch of bytes.
*/
err = NuCreateDataSourceForBuffer(kNuThreadFormatUncompressed,
0, buf, 0, 131072, FreeCallback, &pDataSource);
if (err != kNuErrNone) {
fprintf(stderr,
"ERROR: 'bytes' data source create failed (err=%d)\n", err);
goto failed;
}
2014-12-22 02:17:23 +00:00
buf = NULL; /* now owned by library */
err = AddSimpleRecord(pArchive, kTestEntryBytes, &recordIdx);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: 'bytes' record failed (err=%d)\n", err);
goto failed;
}
err = NuAddThread(pArchive, recordIdx, kNuThreadIDDataFork, pDataSource,
2014-12-22 02:17:23 +00:00
NULL);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: 'bytes' thread add failed (err=%d)\n", err);
goto failed;
}
2014-12-22 02:17:23 +00:00
pDataSource = NULL; /* now owned by library */
/*
* Create a data source for our lovely text message.
*/
printf("... add 'English' record\n");
err = NuCreateDataSourceForBuffer(kNuThreadFormatUncompressed,
0, (const uint8_t*)testMsg, 0, strlen(testMsg), NULL, &pDataSource);
if (err != kNuErrNone) {
fprintf(stderr,
"ERROR: 'English' source create failed (err=%d)\n", err);
goto failed;
}
FAIL_OK;
err = NuAddThread(pArchive, recordIdx, kNuThreadIDDataFork, pDataSource,
2014-12-22 02:17:23 +00:00
NULL);
FAIL_BAD;
if (err == kNuErrNone) {
fprintf(stderr, "ERROR: 'English' add should've conflicted!\n");
goto failed;
}
FAIL_OK;
err = AddSimpleRecord(pArchive, kTestEntryBytes, &recordIdx);
FAIL_BAD;
if (err == kNuErrNone) {
fprintf(stderr, "ERROR: duplicates not allowed, should've failed\n");
goto failed;
}
err = AddSimpleRecord(pArchive, kTestEntryEnglish, &recordIdx);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: 'English' record failed (err=%d)\n", err);
goto failed;
}
err = NuAddThread(pArchive, recordIdx, kNuThreadIDDataFork, pDataSource,
2014-12-22 02:17:23 +00:00
NULL);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: 'English' thread add failed (err=%d)\n", err);
goto failed;
}
2014-12-22 02:17:23 +00:00
pDataSource = NULL; /* now owned by library */
/*
* Create an empty file with a rather non-empty name. Add it as
* a resource fork.
*/
printf("... add 'long' record\n");
err = NuCreateDataSourceForBuffer(kNuThreadFormatUncompressed,
2014-12-22 02:17:23 +00:00
0, NULL, 0, 0, NULL, &pDataSource);
if (err != kNuErrNone) {
fprintf(stderr,
"ERROR: 'English' source create failed (err=%d)\n", err);
goto failed;
}
err = AddSimpleRecord(pArchive, kTestEntryLong, &recordIdx);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: 'long' record failed (err=%d)\n", err);
goto failed;
}
err = NuAddThread(pArchive, recordIdx, kNuThreadIDRsrcFork, pDataSource,
2014-12-22 02:17:23 +00:00
NULL);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: 'long' thread add failed (err=%d)\n", err);
goto failed;
}
2014-12-22 02:17:23 +00:00
pDataSource = NULL; /* now owned by library */
/*
* Flush changes.
*/
err = NuFlush(pArchive, &status);
if (err != kNuErrNone) {
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
fprintf(stderr, "ERROR: couldn't flush after add (err=%d, status=%u)\n",
err, status);
goto failed;
}
/*
* Flush again; should succeed since it doesn't have to do anything.
*/
err = NuFlush(pArchive, &status);
if (err != kNuErrNone) {
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
fprintf(stderr, "ERROR: second add flush failed (err=%d, status=%u)\n",
err, status);
goto failed;
}
return 0;
2000-05-23 01:55:31 +00:00
failed:
2014-12-22 02:17:23 +00:00
if (pDataSource != NULL)
NuFreeDataSource(pDataSource);
2014-12-22 02:17:23 +00:00
if (buf != NULL)
free(buf);
return -1;
2000-05-23 01:55:31 +00:00
}
/*
* Make sure that what we're seeing makes sense.
*/
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
NuResult TestContentsCallback(NuArchive* pArchive, void* vpRecord)
2000-05-23 01:55:31 +00:00
{
const NuRecord* pRecord = (NuRecord*) vpRecord;
2000-05-23 01:55:31 +00:00
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
if (strcmp(pRecord->filenameMOR, kTestEntryBytes) == 0 ||
strcmp(pRecord->filenameMOR, kTestEntryEnglish) == 0 ||
strcmp(pRecord->filenameMOR, kTestEntryLong) == 0)
{
return kNuOK;
}
2000-05-23 01:55:31 +00:00
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
fprintf(stderr, "ERROR: found mystery entry '%s'\n", pRecord->filenameMOR);
return kNuAbort;
2000-05-23 01:55:31 +00:00
}
/*
* Verify that the contents look about right.
*/
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
int Test_Contents(NuArchive* pArchive)
2000-05-23 01:55:31 +00:00
{
NuError err;
long posn;
NuRecordIdx recordIdx;
const NuRecord* pRecord;
int cc;
/*
* First, do it with a callback.
*/
err = NuContents(pArchive, TestContentsCallback);
if (err != kNuErrNone)
goto failed;
/*
* Now step through the records with get-by-position and verify that
* they're in the expected order.
*/
for (posn = 0; posn < kNumEntries; posn++) {
err = NuGetRecordIdxByPosition(pArchive, posn, &recordIdx);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't get record #%ld (err=%d)\n",
posn, err);
goto failed;
}
err = NuGetRecord(pArchive, recordIdx, &pRecord);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't get record index %u (err=%d)\n",
recordIdx, err);
goto failed;
}
2014-12-22 02:17:23 +00:00
assert(pRecord != NULL);
switch (posn) {
case 0:
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
cc = strcmp(pRecord->filenameMOR, kTestEntryBytes);
break;
case 1:
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
cc = strcmp(pRecord->filenameMOR, kTestEntryEnglish);
break;
case 2:
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
cc = strcmp(pRecord->filenameMOR, kTestEntryLong);
if (!cc)
cc = !(pRecord->recStorageType == kNuStorageExtended);
break;
default:
fprintf(stderr, "ERROR: somebody forgot to put a case here (%ld)\n",
posn);
cc = -1;
}
if (cc) {
fprintf(stderr, "ERROR: got '%s' for %ld (%u), not expected\n",
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
pRecord->filenameMOR, posn, recordIdx);
goto failed;
}
}
/*
* Read one more past the end, should fail.
*/
FAIL_OK;
err = NuGetRecordIdxByPosition(pArchive, posn, &recordIdx);
FAIL_BAD;
if (err == kNuErrNone) {
fprintf(stderr, "ERROR: too many records (%ld was ok)\n", posn);
goto failed;
}
return 0;
2000-05-23 01:55:31 +00:00
failed:
return -1;
2000-05-23 01:55:31 +00:00
}
/*
* Selection callback filter for "test". This gets called once per record,
* twice per record for forked files.
2000-05-23 01:55:31 +00:00
*/
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
NuResult VerifySelectionCallback(NuArchive* pArchive, void* vpProposal)
2000-05-23 01:55:31 +00:00
{
NuError err;
const NuSelectionProposal* pProposal = vpProposal;
long count;
2014-12-22 02:17:23 +00:00
if (pProposal->pRecord == NULL || pProposal->pThread == NULL ||
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
pProposal->pRecord->filenameMOR == NULL)
{
2014-12-22 02:17:23 +00:00
fprintf(stderr, "ERROR: unexpected NULL in proposal\n");
goto failed;
}
err = NuGetExtraData(pArchive, (void**) &count);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: unable to get extra data (err=%d)\n", err);
goto failed;
}
count++;
err = NuSetExtraData(pArchive, (void*) count);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: unable to inc extra data (err=%d)\n", err);
goto failed;
}
return kNuOK;
2000-05-23 01:55:31 +00:00
failed:
return kNuAbort;
2000-05-23 01:55:31 +00:00
}
/*
* Verify the archive contents.
*/
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
int Test_Verify(NuArchive* pArchive)
2000-05-23 01:55:31 +00:00
{
NuError err;
long count;
printf("... verifying CRCs\n");
if (NuSetSelectionFilter(pArchive, VerifySelectionCallback) ==
kNuInvalidCallback)
{
fprintf(stderr, "ERROR: unable to set selection filter\n");
goto failed;
}
err = NuSetExtraData(pArchive, (void*) 0);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: unable to set extra data (err=%d)\n", err);
goto failed;
}
err = NuTest(pArchive);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: verify failed (err=%d)\n", err);
goto failed;
}
err = NuGetExtraData(pArchive, (void**) &count);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: last extra data get failed (err=%d)\n", err);
goto failed;
}
/* the count will be one higher than the number of records because
the last entry is forked, and each fork is tested separately */
if (count != kNumEntries + 1) {
fprintf(stderr, "ERROR: verified %ld when expecting %d\n", count,
kNumEntries);
goto failed;
}
return 0;
2000-05-23 01:55:31 +00:00
failed:
return -1;
2000-05-23 01:55:31 +00:00
}
/*
* Extract stuff.
*/
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
int Test_Extract(NuArchive* pArchive)
2000-05-23 01:55:31 +00:00
{
NuError err;
NuRecordIdx recordIdx;
const NuRecord* pRecord;
const NuThread* pThread;
2014-12-22 02:17:23 +00:00
NuDataSink* pDataSink = NULL;
uint8_t* buf = NULL;
printf("... extracting files\n");
/*
* Tell it the current system uses CRLF, so it'll bloat up when we do
* a text conversion.
*/
err = NuSetValue(pArchive, kNuValueEOL, kNuEOLCRLF);
/*
* Extract "bytes".
*/
err = NuGetRecordIdxByName(pArchive, kTestEntryBytesUPPER, &recordIdx);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't find '%s' (err=%d)\n", kTestEntryBytes,
err);
goto failed;
}
err = NuGetRecord(pArchive, recordIdx, &pRecord);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't get record index %u (err=%d)\n",
recordIdx, err);
goto failed;
}
2014-12-22 02:17:23 +00:00
assert(pRecord != NULL);
/* we're not using ShrinkIt compat mode, so there should not be a comment */
pThread = NuGetThread(pRecord, 1);
2014-12-22 02:17:23 +00:00
assert(pThread != NULL);
if (NuGetThreadID(pThread) != kNuThreadIDDataFork) {
fprintf(stderr, "ERROR: 'bytes' had unexpected threadID 0x%08x\n",
NuGetThreadID(pThread));
goto failed;
}
buf = malloc(pThread->actualThreadEOF);
2014-12-22 02:17:23 +00:00
if (buf == NULL) {
fprintf(stderr, "ERROR: malloc(%u) failed\n",pThread->actualThreadEOF);
goto failed;
}
/*
* Try to extract it with text conversion off.
*/
err = NuCreateDataSinkForBuffer(true, kNuConvertOff, buf,
pThread->actualThreadEOF, &pDataSink);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't create data sink (err=%d)\n", err);
goto failed;
}
err = NuExtractThread(pArchive, pThread->threadIdx, pDataSink);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't extract 'bytes' (off) (err=%d)\n",
err);
goto failed;
}
NuFreeDataSink(pDataSink);
2014-12-22 02:17:23 +00:00
pDataSink = NULL;
/*
* Try to extract with "on" conversion, which should fail because the
* buffer is too small.
*/
err = NuCreateDataSinkForBuffer(true, kNuConvertOn, buf,
pThread->actualThreadEOF, &pDataSink);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't create data sink (err=%d)\n", err);
goto failed;
}
FAIL_OK;
err = NuExtractThread(pArchive, pThread->threadIdx, pDataSink);
FAIL_BAD;
if (err == kNuErrNone) {
fprintf(stderr, "ERROR: managed to extract bloated 'bytes'?\n");
goto failed;
}
NuFreeDataSink(pDataSink);
2014-12-22 02:17:23 +00:00
pDataSink = NULL;
/*
* Try to extract with "auto" conversion, which should conclude that
* the input is text and not try to convert.
*/
err = NuCreateDataSinkForBuffer(true, kNuConvertAuto, buf,
pThread->actualThreadEOF, &pDataSink);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't create data sink (err=%d)\n", err);
goto failed;
}
err = NuExtractThread(pArchive, pThread->threadIdx, pDataSink);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't extract 'bytes' (auto) (err=%d)\n",
err);
goto failed;
}
NuFreeDataSink(pDataSink);
2014-12-22 02:17:23 +00:00
pDataSink = NULL;
free(buf);
2014-12-22 02:17:23 +00:00
buf = NULL;
/*
* Extract "English".
*/
err = NuGetRecordIdxByName(pArchive, kTestEntryEnglish, &recordIdx);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't find '%s' (err=%d)\n",
kTestEntryEnglish, err);
goto failed;
}
err = NuGetRecord(pArchive, recordIdx, &pRecord);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't get record index %u (err=%d)\n",
recordIdx, err);
goto failed;
}
2014-12-22 02:17:23 +00:00
assert(pRecord != NULL);
/* we're not using ShrinkIt compat mode, so there should not be a comment */
pThread = NuGetThread(pRecord, 1);
2014-12-22 02:17:23 +00:00
assert(pThread != NULL);
if (NuGetThreadID(pThread) != kNuThreadIDDataFork) {
fprintf(stderr, "ERROR: 'English' had unexpected threadID 0x%08x\n",
NuGetThreadID(pThread));
goto failed;
}
buf = malloc(pThread->actualThreadEOF);
2014-12-22 02:17:23 +00:00
if (buf == NULL) {
fprintf(stderr, "ERROR: malloc(%u) failed\n", pThread->actualThreadEOF);
goto failed;
}
/*
* Try to extract it with text conversion off.
*/
err = NuCreateDataSinkForBuffer(true, kNuConvertOff, buf,
pThread->actualThreadEOF, &pDataSink);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't create data sink (err=%d)\n", err);
goto failed;
}
err = NuExtractThread(pArchive, pThread->threadIdx, pDataSink);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't extract 'bytes' (off) (err=%d)\n",
err);
goto failed;
}
NuFreeDataSink(pDataSink);
2014-12-22 02:17:23 +00:00
pDataSink = NULL;
/*
* Try to extract with "auto" conversion, which should fail because the
* buffer is too small, and the input looks like text.
*/
err = NuCreateDataSinkForBuffer(true, kNuConvertAuto, buf,
pThread->actualThreadEOF, &pDataSink);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't create data sink (err=%d)\n", err);
goto failed;
}
FAIL_OK;
err = NuExtractThread(pArchive, pThread->threadIdx, pDataSink);
FAIL_BAD;
if (err == kNuErrNone) {
fprintf(stderr, "ERROR: managed to extract bloated 'English'?\n");
goto failed;
}
NuFreeDataSink(pDataSink);
2014-12-22 02:17:23 +00:00
pDataSink = NULL;
/*Free(buf);*/
2014-12-22 02:17:23 +00:00
/*buf = NULL;*/
/*
* Extract "long" (which is zero bytes).
*/
err = NuGetRecordIdxByName(pArchive, kTestEntryLong, &recordIdx);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't find '%s' (err=%d)\n",
kTestEntryLong, err);
goto failed;
}
err = NuGetRecord(pArchive, recordIdx, &pRecord);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't get record index %u (err=%d)\n",
recordIdx, err);
goto failed;
}
2014-12-22 02:17:23 +00:00
assert(pRecord != NULL);
/* we're not using ShrinkIt compat mode, so there should not be a comment */
pThread = NuGetThread(pRecord, 1);
2014-12-22 02:17:23 +00:00
assert(pThread != NULL);
if (NuGetThreadID(pThread) != kNuThreadIDRsrcFork) {
fprintf(stderr, "ERROR: 'Long' had unexpected threadID 0x%08x\n",
NuGetThreadID(pThread));
goto failed;
}
/*
* Try it with text conversion on; shouldn't matter.
*/
err = NuCreateDataSinkForBuffer(true, kNuConvertOn, buf,
1, &pDataSink);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't create data sink (err=%d)\n", err);
goto failed;
}
err = NuExtractThread(pArchive, pThread->threadIdx, pDataSink);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't extract 'Long' (off) (err=%d)\n",
err);
goto failed;
}
NuFreeDataSink(pDataSink);
2014-12-22 02:17:23 +00:00
pDataSink = NULL;
free(buf);
2014-12-22 02:17:23 +00:00
buf = NULL;
return 0;
2000-05-23 01:55:31 +00:00
failed:
2014-12-22 02:17:23 +00:00
if (buf != NULL)
free(buf);
2014-12-22 02:17:23 +00:00
if (pDataSink != NULL)
(void) NuFreeDataSink(pDataSink);
return -1;
2000-05-23 01:55:31 +00:00
}
/*
* Delete the first and last records. Does *not* flush the archive.
*/
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
int Test_Delete(NuArchive* pArchive)
2000-05-23 01:55:31 +00:00
{
NuError err;
NuRecordIdx recordIdx;
const NuRecord* pRecord;
2014-12-22 02:17:23 +00:00
const NuThread* pThread = NULL;
long count;
int idx;
printf("... deleting first and last\n");
/*
* Delete all threads from the first record ("bytes").
*/
err = NuGetRecordIdxByPosition(pArchive, 0, &recordIdx);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't find #%d (err=%d)\n", 0, err);
goto failed;
}
err = NuGetRecord(pArchive, recordIdx, &pRecord);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't get record index %u (err=%d)\n",
recordIdx, err);
goto failed;
}
2014-12-22 02:17:23 +00:00
assert(pRecord != NULL);
assert(pRecord->recTotalThreads > 0);
for (idx = 0; idx < (int)pRecord->recTotalThreads; idx++) {
pThread = NuGetThread(pRecord, idx);
2014-12-22 02:17:23 +00:00
assert(pThread != NULL);
err = NuDeleteThread(pArchive, pThread->threadIdx);
if (err != kNuErrNone) {
fprintf(stderr,
"ERROR: couldn't delete thread #%d (%u) (err=%d)\n",
idx, recordIdx, err);
goto failed;
}
}
/* try to re-delete the same thread */
2014-12-22 02:17:23 +00:00
assert(pThread != NULL);
FAIL_OK;
err = NuDeleteThread(pArchive, pThread->threadIdx);
FAIL_BAD;
if (err == kNuErrNone) {
fprintf(stderr, "ERROR: allowed to re-delete thread (%u) (err=%d)\n",
recordIdx, err);
goto failed;
}
/* try to delete the modified record */
FAIL_OK;
err = NuDeleteRecord(pArchive, recordIdx);
FAIL_BAD;
if (err == kNuErrNone) {
fprintf(stderr,
"ERROR: able to delete modified record (%u) (err=%d)\n",
recordIdx, err);
goto failed;
}
/*
* Make sure the attr hasn't been updated yet.
*/
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
count = 0;
err = NuGetAttr(pArchive, kNuAttrNumRecords, (uint32_t*) &count);
if (count != kNumEntries) {
fprintf(stderr, "ERROR: kNuAttrNumRecords %ld vs %d\n",
count, kNumEntries);
goto failed;
}
/*
* Delete the last record ("long").
*/
err = NuGetRecordIdxByPosition(pArchive, kNumEntries-1, &recordIdx);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't find #%d (err=%d)\n", 0, err);
goto failed;
}
err = NuGetRecord(pArchive, recordIdx, &pRecord);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't get record index %u (err=%d)\n",
recordIdx, err);
goto failed;
}
2014-12-22 02:17:23 +00:00
assert(pRecord != NULL);
/* grab the first thread before we whack the record */
pThread = NuGetThread(pRecord, 0);
2014-12-22 02:17:23 +00:00
assert(pThread != NULL);
err = NuDeleteRecord(pArchive, recordIdx);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: unable to delete record #%d (%u) (err=%d)\n",
kNumEntries-1, recordIdx, err);
goto failed;
}
/* try to delete a thread from the deleted record */
FAIL_OK;
err = NuDeleteThread(pArchive, pThread->threadIdx);
FAIL_BAD;
if (err == kNuErrNone) {
fprintf(stderr,
"ERROR: allowed to delete from deleted (%u) (err=%d)\n",
pThread->threadIdx, err);
goto failed;
}
return 0;
2000-05-23 01:55:31 +00:00
failed:
return -1;
2000-05-23 01:55:31 +00:00
}
/*
* Verify that the count in the master header has been updated.
*/
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
int Test_MasterCount(NuArchive* pArchive, long expected)
2000-05-23 01:55:31 +00:00
{
NuError err;
const NuMasterHeader* pMasterHeader;
2000-05-23 01:55:31 +00:00
printf("... checking master count\n");
2000-05-23 01:55:31 +00:00
err = NuGetMasterHeader(pArchive, &pMasterHeader);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: couldn't get master header (err=%d)\n", err);
goto failed;
}
2000-05-23 01:55:31 +00:00
if (pMasterHeader->mhTotalRecords != (uint32_t)expected) {
fprintf(stderr, "ERROR: unexpected MH count (%u vs %ld)\n",
pMasterHeader->mhTotalRecords, expected);
goto failed;
}
2000-05-23 01:55:31 +00:00
return 0;
2000-05-23 01:55:31 +00:00
failed:
return -1;
2000-05-23 01:55:31 +00:00
}
/*
* Run some tests.
*
* Returns 0 on success, -1 on error.
*/
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
int DoTests(void)
2000-05-23 01:55:31 +00:00
{
NuError err;
2014-12-22 02:17:23 +00:00
NuArchive* pArchive = NULL;
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
uint32_t status;
int cc, result = 0;
/*
* Make sure we're starting with a clean slate.
*/
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
if (RemoveTestFile("Test archive", kTestArchive) < 0) {
goto failed;
}
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
if (RemoveTestFile("Test temp file", kTestTempFile) < 0) {
goto failed;
}
/*
* Test some of the open flags.
*/
if (Test_OpenFlags() != 0)
goto failed;
/*
* Create a new archive to play with.
*/
err = NuOpenRW(kTestArchive, kTestTempFile, kNuOpenCreat|kNuOpenExcl,
&pArchive);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: NuOpenRW failed (err=%d)\n", err);
goto failed;
}
if (NuSetErrorMessageHandler(pArchive, ErrorMessageHandler) ==
kNuInvalidCallback)
{
fprintf(stderr, "ERROR: couldn't set message handler\n");
goto failed;
}
/*
* Add some test entries.
*/
if (Test_AddStuff(pArchive) != 0)
goto failed;
/*
* Check the archive contents.
*/
printf("... checking contents\n");
if (Test_Contents(pArchive) != 0)
goto failed;
/*
* Reopen it read-only.
*/
printf("... reopening archive read-only\n");
err = NuClose(pArchive);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: mid NuClose failed (err=%d)\n", err);
goto failed;
}
2014-12-22 02:17:23 +00:00
pArchive = NULL;
err = NuOpenRO(kTestArchive, &pArchive);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: NuOpenRO failed (err=%d)\n", err);
goto failed;
}
if (NuSetErrorMessageHandler(pArchive, ErrorMessageHandler) ==
kNuInvalidCallback)
{
fprintf(stderr, "ERROR: couldn't set message handler\n");
goto failed;
}
/*
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
* Make sure the TOC (i.e. list of files) is still what we expect.
*/
printf("... checking contents\n");
if (Test_Contents(pArchive) != 0)
goto failed;
/*
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
* Verify the archive data.
*/
if (Test_Verify(pArchive) != 0)
goto failed;
/*
* Extract the files.
*/
if (Test_Extract(pArchive) != 0)
goto failed;
/*
* Reopen it read-write.
*/
printf("... reopening archive read-write\n");
err = NuClose(pArchive);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: late NuClose failed (err=%d)\n", err);
goto failed;
}
2014-12-22 02:17:23 +00:00
pArchive = NULL;
err = NuOpenRW(kTestArchive, kTestTempFile, 0, &pArchive);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: re-NuOpenRW failed (err=%d)\n", err);
goto failed;
}
if (NuSetErrorMessageHandler(pArchive, ErrorMessageHandler) ==
kNuInvalidCallback)
{
fprintf(stderr, "ERROR: couldn't set message handler\n");
goto failed;
}
/*
* Contents shouldn't have changed.
*/
printf("... checking contents\n");
if (Test_Contents(pArchive) != 0)
goto failed;
/*
* Test deletion.
*/
if (Test_Delete(pArchive) != 0)
goto failed;
/*
* Abort the changes and verify that nothing has changed.
*/
printf("... aborting changes\n");
err = NuAbort(pArchive);
if (err != kNuErrNone) {
fprintf(stderr, "ERROR: abort failed (err=%d)\n", err);
goto failed;
}
printf("... checking contents\n");
if (Test_Contents(pArchive) != 0)
goto failed;
/*
* Delete them again.
*/
if (Test_Delete(pArchive) != 0)
goto failed;
/*
* Flush the deletions. This should remove the first and last records.
*/
err = NuFlush(pArchive, &status);
if (err != kNuErrNone) {
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
fprintf(stderr, "ERROR: flush failed (err=%d, status=%d)\n",
err, status);
goto failed;
}
/*
* Check count in master header.
*/
if (Test_MasterCount(pArchive, kNumEntries-2) != 0)
goto failed;
/*
* That's all, folks...
*/
NuClose(pArchive);
2014-12-22 02:17:23 +00:00
pArchive = NULL;
printf("... removing '%s'\n", kTestArchive);
cc = unlink(kTestArchive);
if (cc < 0) {
perror("unlink kTestArchive");
goto failed;
}
2000-05-23 01:55:31 +00:00
leave:
2014-12-22 02:17:23 +00:00
if (pArchive != NULL) {
NuAbort(pArchive);
NuClose(pArchive);
}
return result;
2000-05-23 01:55:31 +00:00
failed:
result = -1;
goto leave;
2000-05-23 01:55:31 +00:00
}
/*
* Crank away.
*/
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
int main(void)
2000-05-23 01:55:31 +00:00
{
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
int32_t major, minor, bug;
const char* pBuildDate;
const char* pBuildFlags;
int cc;
2000-05-23 01:55:31 +00:00
(void) NuGetVersion(&major, &minor, &bug, &pBuildDate, &pBuildFlags);
Distinguish Unicode and Mac OS Roman strings NufxLib has historically made no effort to distinguish between the character set used for filenames on the local disk, and for filenames stored within the archive. Now all Unicode filename strings use the UNICHAR type and have "UNI" in the name, and all Mac OS Roman strings have "MOR" in the name. (The naming convention makes it obvious when you're assigning the wrong thing; on Linux both formats are char*, so the compiler won't tell you if you get it wrong.) The distinction is necessary because filesystems generally support Unicode these days, but on Windows you need to use a separate set of wide-character file I/O functions. (On Linux it all works with "narrow" strings, and the UTF-8 encoding is interpreted by applications.) The character set used for NuFX archive filenames is MOR, matching what GS/OS + HFS supported, and we want to be able to convert back and forth between MOR and a Unicode representation. This change updates the various character types and string names, adds conversion functions, and updates NuLib2 for proper execution on Linux. It does not include the (probably extensive) changes required for Windows UTF-16 support. Instead, the conversion functions are no-ops, which should result in NuLib2 for Windows continuing to behave in the same slightly broken way. This adds "test-names", which exercises Unicode filenames a bit. It will not pass on Win32. Also, tweaked the Linux makefiles to have explicit dependencies, rather than empty space and an expectation that "makedepend" exists. Also, minor source code cleanups. While this probably doesn't affect binary compatibility -- it's mainly a matter of naming and string interpretation -- there's enough going on that it should be considered an API revision, so this updates the version to 3.0.0.
2014-12-24 19:14:32 +00:00
printf("Using NuFX library v%d.%d.%d, built on or after\n"
" %s with [%s]\n\n",
major, minor, bug, pBuildDate, pBuildFlags);
2000-05-23 01:55:31 +00:00
if (NuSetGlobalErrorMessageHandler(ErrorMessageHandler) ==
kNuInvalidCallback)
{
fprintf(stderr, "ERROR: can't set the global message handler");
exit(1);
}
2000-05-23 01:55:31 +00:00
printf("... starting tests\n");
2000-05-23 01:55:31 +00:00
cc = DoTests();
2000-05-23 01:55:31 +00:00
printf("... tests ended, %s\n", cc == 0 ? "SUCCESS" : "FAILURE");
exit(cc != 0);
2000-05-23 01:55:31 +00:00
}