nulib2/nufxlib/SourceSink.c

859 lines
22 KiB
C
Raw Permalink 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
*
* Implementation of DataSource and DataSink objects.
*/
#include "NufxLibPriv.h"
/*
* ===========================================================================
* NuDataSource
2000-05-23 01:55:31 +00:00
* ===========================================================================
*/
/*
* Allocate a new DataSource structure.
*/
static NuError Nu_DataSourceNew(NuDataSource** ppDataSource)
2000-05-23 01:55:31 +00:00
{
2014-12-22 02:17:23 +00:00
Assert(ppDataSource != NULL);
2000-05-23 01:55:31 +00:00
2014-12-22 02:17:23 +00:00
*ppDataSource = Nu_Malloc(NULL, sizeof(**ppDataSource));
if (*ppDataSource == NULL)
return kNuErrMalloc;
2000-05-23 01:55:31 +00:00
(*ppDataSource)->sourceType = kNuDataSourceUnknown;
2000-05-23 01:55:31 +00:00
return kNuErrNone;
2000-05-23 01:55:31 +00:00
}
/*
* Make a copy of a DataSource. Actually just increments a reference count.
2000-05-23 01:55:31 +00:00
*
* What we *really* want to be doing is copying the structure (since we
* can't guarantee copy-on-write semantics for the fields without adding
* more stuff) and refcounting the underlying resource, so that "auto-free"
* semantics work out right.
*
* We're okay for now, since for the most part we only do work on one
* copy of each. (I wish I could remember why this copying thing was
* needed in the first place.) Buffer sources are a little scary since
* they include a "curOffset" value.
2000-05-23 01:55:31 +00:00
*
2014-12-22 02:17:23 +00:00
* Returns NULL on error.
2000-05-23 01:55:31 +00:00
*/
NuDataSource* Nu_DataSourceCopy(NuDataSource* pDataSource)
2000-05-23 01:55:31 +00:00
{
Assert(pDataSource->common.refCount >= 1);
pDataSource->common.refCount++;
return pDataSource;
#if 0 /* we used to copy them -- very bad idea */
NuDataSource* pNewDataSource;
2000-05-23 01:55:31 +00:00
2014-12-22 02:17:23 +00:00
Assert(pDataSource != NULL);
2000-05-23 01:55:31 +00:00
if (Nu_DataSourceNew(&pNewDataSource) != kNuErrNone)
2014-12-22 02:17:23 +00:00
return NULL;
Assert(pNewDataSource != NULL);
2000-05-23 01:55:31 +00:00
/* this gets most of it */
memcpy(pNewDataSource, pDataSource, sizeof(*pNewDataSource));
2000-05-23 01:55:31 +00:00
/* copy anything we're sure to free up */
if (pDataSource->sourceType == kNuDataSourceFromFile) {
2014-12-22 02:17:23 +00:00
Assert(pDataSource->fromFile.fp == NULL); /* does this matter? */
pNewDataSource->fromFile.pathname =
strdup(pDataSource->fromFile.pathname);
}
2000-05-23 01:55:31 +00:00
/* don't let the original free up the resources */
if (pDataSource->common.doClose) {
DBUG(("--- clearing doClose on source-copy of data source\n"));
pDataSource->common.doClose = false;
}
2000-05-23 01:55:31 +00:00
return pNewDataSource;
#endif
2000-05-23 01:55:31 +00:00
}
/*
* Free a data source structure, and any type-specific elements.
*/
NuError Nu_DataSourceFree(NuDataSource* pDataSource)
2000-05-23 01:55:31 +00:00
{
2014-12-22 02:17:23 +00:00
if (pDataSource == NULL)
return kNuErrNone;
Assert(pDataSource->common.refCount > 0);
if (pDataSource->common.refCount > 1) {
pDataSource->common.refCount--;
return kNuErrNone;
}
switch (pDataSource->sourceType) {
case kNuDataSourceFromFile:
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
Nu_Free(NULL, pDataSource->fromFile.pathnameUNI);
2014-12-22 02:17:23 +00:00
if (pDataSource->fromFile.fp != NULL) {
fclose(pDataSource->fromFile.fp);
2014-12-22 02:17:23 +00:00
pDataSource->fromFile.fp = NULL;
}
break;
case kNuDataSourceFromFP:
2014-12-22 02:17:23 +00:00
if (pDataSource->fromFP.fcloseFunc != NULL &&
pDataSource->fromFP.fp != NULL)
{
2014-12-22 02:17:23 +00:00
(*pDataSource->fromFP.fcloseFunc)(NULL, pDataSource->fromFP.fp);
pDataSource->fromFP.fp = NULL;
}
break;
case kNuDataSourceFromBuffer:
2014-12-22 02:17:23 +00:00
if (pDataSource->fromBuffer.freeFunc != NULL) {
(*pDataSource->fromBuffer.freeFunc)(NULL,
(void*)pDataSource->fromBuffer.buffer);
2014-12-22 02:17:23 +00:00
pDataSource->fromBuffer.buffer = NULL;
}
break;
case kNuDataSourceUnknown:
break;
default:
Assert(0);
return kNuErrInternal;
}
2014-12-22 02:17:23 +00:00
Nu_Free(NULL, pDataSource);
return kNuErrNone;
2000-05-23 01:55:31 +00:00
}
/*
* Create a data source for an unopened file.
*/
NuError Nu_DataSourceFile_New(NuThreadFormat threadFormat, uint32_t otherLen,
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
const UNICHAR* pathnameUNI, Boolean isFromRsrcFork,
NuDataSource** ppDataSource)
2000-05-23 01:55:31 +00:00
{
NuError err;
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 (pathnameUNI == NULL ||
!(isFromRsrcFork == true || isFromRsrcFork == false) ||
2014-12-22 02:17:23 +00:00
ppDataSource == NULL)
{
return kNuErrInvalidArg;
}
2000-05-23 01:55:31 +00:00
err = Nu_DataSourceNew(ppDataSource);
BailErrorQuiet(err);
2000-05-23 01:55:31 +00:00
(*ppDataSource)->common.sourceType = kNuDataSourceFromFile;
(*ppDataSource)->common.threadFormat = threadFormat;
(*ppDataSource)->common.rawCrc = 0;
(*ppDataSource)->common.dataLen = 0; /* to be filled in later */
(*ppDataSource)->common.otherLen = otherLen;
(*ppDataSource)->common.refCount = 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
(*ppDataSource)->fromFile.pathnameUNI = strdup(pathnameUNI);
(*ppDataSource)->fromFile.fromRsrcFork = isFromRsrcFork;
2014-12-22 02:17:23 +00:00
(*ppDataSource)->fromFile.fp = NULL; /* to be filled in later */
2000-05-23 01:55:31 +00:00
bail:
return err;
2000-05-23 01:55:31 +00:00
}
/*
* Create a data source for an open file at a specific offset. The FILE*
* must be seekable.
*/
NuError Nu_DataSourceFP_New(NuThreadFormat threadFormat, uint32_t otherLen,
FILE* fp, long offset, long length, NuCallback fcloseFunc,
NuDataSource** ppDataSource)
{
NuError err;
2014-12-22 02:17:23 +00:00
if (fp == NULL || offset < 0 || length < 0 ||
ppDataSource == NULL)
{
return kNuErrInvalidArg;
}
if (otherLen && otherLen < (uint32_t)length) {
DBUG(("--- rejecting FP len=%ld other=%ld\n", length, otherLen));
err = kNuErrPreSizeOverflow;
goto bail;
}
err = Nu_DataSourceNew(ppDataSource);
BailErrorQuiet(err);
(*ppDataSource)->common.sourceType = kNuDataSourceFromFP;
(*ppDataSource)->common.threadFormat = threadFormat;
(*ppDataSource)->common.rawCrc = 0;
(*ppDataSource)->common.dataLen = length;
(*ppDataSource)->common.otherLen = otherLen;
(*ppDataSource)->common.refCount = 1;
(*ppDataSource)->fromFP.fp = fp;
(*ppDataSource)->fromFP.offset = offset;
(*ppDataSource)->fromFP.fcloseFunc = fcloseFunc;
2000-05-23 01:55:31 +00:00
bail:
return err;
2000-05-23 01:55:31 +00:00
}
/*
* Create a data source for a buffer.
*
2014-12-22 02:17:23 +00:00
* We allow "buffer" to be NULL so long as "offset" and "length" are also
* NULL. This is useful for creating empty pre-sized buffers, such as
2000-05-23 01:55:31 +00:00
* blank comment fields.
*/
NuError Nu_DataSourceBuffer_New(NuThreadFormat threadFormat, uint32_t otherLen,
const uint8_t* buffer, long offset, long length, NuCallback freeFunc,
NuDataSource** ppDataSource)
{
NuError err;
2014-12-22 02:17:23 +00:00
if (offset < 0 || length < 0 || ppDataSource == NULL)
return kNuErrInvalidArg;
2014-12-22 02:17:23 +00:00
if (buffer == NULL && (offset != 0 || length != 0))
return kNuErrInvalidArg;
2014-12-22 02:17:23 +00:00
if (buffer == NULL) {
DBUG(("+++ zeroing freeFunc for empty-buffer DataSource\n"));
2014-12-22 02:17:23 +00:00
freeFunc = NULL;
}
if (otherLen && otherLen < (uint32_t)length) {
DBUG(("--- rejecting buffer len=%ld other=%ld\n", length, otherLen));
err = kNuErrPreSizeOverflow;
goto bail;
}
err = Nu_DataSourceNew(ppDataSource);
BailErrorQuiet(err);
(*ppDataSource)->common.sourceType = kNuDataSourceFromBuffer;
(*ppDataSource)->common.threadFormat = threadFormat;
(*ppDataSource)->common.rawCrc = 0;
(*ppDataSource)->common.dataLen = length;
(*ppDataSource)->common.otherLen = otherLen;
(*ppDataSource)->common.refCount = 1;
(*ppDataSource)->fromBuffer.buffer = buffer;
(*ppDataSource)->fromBuffer.offset = offset;
(*ppDataSource)->fromBuffer.curOffset = offset;
(*ppDataSource)->fromBuffer.curDataLen = length;
(*ppDataSource)->fromBuffer.freeFunc = freeFunc;
2000-05-23 01:55:31 +00:00
bail:
return err;
2000-05-23 01:55:31 +00:00
}
/*
* Get the type of a NuDataSource.
*/
NuDataSourceType Nu_DataSourceGetType(const NuDataSource* pDataSource)
2000-05-23 01:55:31 +00:00
{
2014-12-22 02:17:23 +00:00
Assert(pDataSource != NULL);
return pDataSource->sourceType;
2000-05-23 01:55:31 +00:00
}
/*
* Get the threadFormat for a data source.
*/
NuThreadFormat Nu_DataSourceGetThreadFormat(const NuDataSource* pDataSource)
2000-05-23 01:55:31 +00:00
{
2014-12-22 02:17:23 +00:00
Assert(pDataSource != NULL);
return pDataSource->common.threadFormat;
2000-05-23 01:55:31 +00:00
}
/*
* Get "dataLen" from a dataSource.
*/
uint32_t Nu_DataSourceGetDataLen(const NuDataSource* pDataSource)
2000-05-23 01:55:31 +00:00
{
2014-12-22 02:17:23 +00:00
Assert(pDataSource != NULL);
2000-05-23 01:55:31 +00:00
if (pDataSource->sourceType == kNuDataSourceFromFile) {
/* dataLen can only be valid if file has been opened */
2014-12-22 02:17:23 +00:00
Assert(pDataSource->fromFile.fp != NULL);
}
2000-05-23 01:55:31 +00:00
return pDataSource->common.dataLen;
2000-05-23 01:55:31 +00:00
}
/*
* Get "otherLen" from a dataSource.
*/
uint32_t Nu_DataSourceGetOtherLen(const NuDataSource* pDataSource)
2000-05-23 01:55:31 +00:00
{
2014-12-22 02:17:23 +00:00
Assert(pDataSource != NULL);
return pDataSource->common.otherLen;
2000-05-23 01:55:31 +00:00
}
/*
* Change the "otherLen" value.
*/
void Nu_DataSourceSetOtherLen(NuDataSource* pDataSource, long otherLen)
2000-05-23 01:55:31 +00:00
{
2014-12-22 02:17:23 +00:00
Assert(pDataSource != NULL && otherLen > 0);
pDataSource->common.otherLen = otherLen;
2000-05-23 01:55:31 +00:00
}
/*
* Get the "raw CRC" value.
*/
uint16_t Nu_DataSourceGetRawCrc(const NuDataSource* pDataSource)
2000-05-23 01:55:31 +00:00
{
2014-12-22 02:17:23 +00:00
Assert(pDataSource != NULL);
return pDataSource->common.rawCrc;
2000-05-23 01:55:31 +00:00
}
/*
* Set the "raw CRC" value. You would want to do this if the input was
* already-compressed data, and you wanted to propagate the thread CRC.
*/
void Nu_DataSourceSetRawCrc(NuDataSource* pDataSource, uint16_t crc)
2000-05-23 01:55:31 +00:00
{
2014-12-22 02:17:23 +00:00
Assert(pDataSource != NULL);
pDataSource->common.rawCrc = crc;
2000-05-23 01:55:31 +00:00
}
/*
* Prepare a data source for action.
*/
NuError Nu_DataSourcePrepareInput(NuArchive* pArchive,
NuDataSource* pDataSource)
2000-05-23 01:55:31 +00:00
{
NuError err = kNuErrNone;
2014-12-22 02:17:23 +00:00
FILE* fileFp = NULL;
/*
* Doesn't apply to buffer sources.
*/
if (Nu_DataSourceGetType(pDataSource) == kNuDataSourceFromBuffer)
goto bail;
/*
* FP sources can be used several times, so we need to seek them
* to the correct offset before we begin.
*/
if (Nu_DataSourceGetType(pDataSource) == kNuDataSourceFromFP) {
err = Nu_FSeek(pDataSource->fromFP.fp, pDataSource->fromFP.offset,
SEEK_SET);
goto bail; /* return this err */
}
/*
* We're adding from a file on disk. Open it.
*/
err = Nu_OpenInputFile(pArchive,
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
pDataSource->fromFile.pathnameUNI,
pDataSource->fromFile.fromRsrcFork, &fileFp);
BailError(err);
2014-12-22 02:17:23 +00:00
Assert(fileFp != NULL);
pDataSource->fromFile.fp = fileFp;
err = Nu_GetFileLength(pArchive, fileFp,
(long*)&pDataSource->common.dataLen);
BailError(err);
if (pDataSource->common.otherLen &&
pDataSource->common.otherLen < pDataSource->common.dataLen)
{
DBUG(("--- Uh oh, looks like file len is too small for presized\n"));
}
2000-05-23 01:55:31 +00:00
bail:
return err;
2000-05-23 01:55:31 +00:00
}
/*
* Un-prepare a data source. This really only affects "file" sources, and
* is only here so we don't end up with 200+ FILE* structures hanging around.
* If we don't do this, the first resource we're likely to run out of is
* file descriptors.
*
* It's not necessary to do this in all error cases -- the DataSource "Free"
* call will take care of this eventually -- but for normal operation on
* a large number of files, it's vital.
*/
void Nu_DataSourceUnPrepareInput(NuArchive* pArchive, NuDataSource* pDataSource)
2000-05-23 01:55:31 +00:00
{
if (Nu_DataSourceGetType(pDataSource) != kNuDataSourceFromFile)
return;
2000-05-23 01:55:31 +00:00
2014-12-22 02:17:23 +00:00
if (pDataSource->fromFile.fp != NULL) {
fclose(pDataSource->fromFile.fp);
2014-12-22 02:17:23 +00:00
pDataSource->fromFile.fp = NULL;
pDataSource->common.dataLen = 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
* Get the pathname from a "from-file" dataSource. Returned string is UTF-8.
2000-05-23 01:55:31 +00:00
*/
const char* Nu_DataSourceFile_GetPathname(NuDataSource* pDataSource)
2000-05-23 01:55:31 +00:00
{
2014-12-22 02:17:23 +00:00
Assert(pDataSource != NULL);
Assert(pDataSource->sourceType == kNuDataSourceFromFile);
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
Assert(pDataSource->fromFile.pathnameUNI != NULL);
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
return pDataSource->fromFile.pathnameUNI;
2000-05-23 01:55:31 +00:00
}
/*
* Read a block of data from a dataSource.
*/
NuError Nu_DataSourceGetBlock(NuDataSource* pDataSource, uint8_t* buf,
uint32_t len)
2000-05-23 01:55:31 +00:00
{
NuError err;
2000-05-23 01:55:31 +00:00
2014-12-22 02:17:23 +00:00
Assert(pDataSource != NULL);
Assert(buf != NULL);
Assert(len > 0);
2000-05-23 01:55:31 +00:00
switch (pDataSource->sourceType) {
case kNuDataSourceFromFile:
2014-12-22 02:17:23 +00:00
Assert(pDataSource->fromFile.fp != NULL);
err = Nu_FRead(pDataSource->fromFile.fp, buf, len);
if (feof(pDataSource->fromFile.fp))
Nu_ReportError(NU_NILBLOB, err, "EOF hit unexpectedly");
return err;
2000-05-23 01:55:31 +00:00
case kNuDataSourceFromFP:
err = Nu_FRead(pDataSource->fromFP.fp, buf, len);
if (feof(pDataSource->fromFP.fp))
Nu_ReportError(NU_NILBLOB, err, "EOF hit unexpectedly");
return err;
2000-05-23 01:55:31 +00:00
case kNuDataSourceFromBuffer:
if ((long)len > pDataSource->fromBuffer.curDataLen) {
/* buffer underrun */
return kNuErrBufferUnderrun;
}
memcpy(buf,
pDataSource->fromBuffer.buffer + pDataSource->fromBuffer.curOffset,
len);
pDataSource->fromBuffer.curOffset += len;
pDataSource->fromBuffer.curDataLen -= len;
return kNuErrNone;
2000-05-23 01:55:31 +00:00
default:
Assert(false);
return kNuErrInternal;
}
2000-05-23 01:55:31 +00:00
}
/*
* Rewind a data source to the start of its input.
*/
NuError Nu_DataSourceRewind(NuDataSource* pDataSource)
2000-05-23 01:55:31 +00:00
{
NuError err;
2000-05-23 01:55:31 +00:00
2014-12-22 02:17:23 +00:00
Assert(pDataSource != NULL);
2000-05-23 01:55:31 +00:00
switch (pDataSource->sourceType) {
case kNuDataSourceFromFile:
2014-12-22 02:17:23 +00:00
Assert(pDataSource->fromFile.fp != NULL);
err = Nu_FSeek(pDataSource->fromFile.fp, 0, SEEK_SET);
break; /* fall through with error */
case kNuDataSourceFromFP:
err = Nu_FSeek(pDataSource->fromFP.fp, pDataSource->fromFP.offset,
SEEK_SET);
break; /* fall through with error */
case kNuDataSourceFromBuffer:
pDataSource->fromBuffer.curOffset = pDataSource->fromBuffer.offset;
pDataSource->fromBuffer.curDataLen = pDataSource->common.dataLen;
err = kNuErrNone;
break;
default:
Assert(false);
err = kNuErrInternal;
}
2000-05-23 01:55:31 +00:00
return err;
2000-05-23 01:55:31 +00:00
}
/*
* ===========================================================================
* NuDataSink
2000-05-23 01:55:31 +00:00
* ===========================================================================
*/
/*
* Allocate a new DataSink structure.
*/
static NuError Nu_DataSinkNew(NuDataSink** ppDataSink)
2000-05-23 01:55:31 +00:00
{
2014-12-22 02:17:23 +00:00
Assert(ppDataSink != NULL);
2000-05-23 01:55:31 +00:00
2014-12-22 02:17:23 +00:00
*ppDataSink = Nu_Malloc(NULL, sizeof(**ppDataSink));
if (*ppDataSink == NULL)
return kNuErrMalloc;
2000-05-23 01:55:31 +00:00
(*ppDataSink)->sinkType = kNuDataSinkUnknown;
2000-05-23 01:55:31 +00:00
return kNuErrNone;
2000-05-23 01:55:31 +00:00
}
/*
* Free a data sink structure, and any type-specific elements.
*/
NuError Nu_DataSinkFree(NuDataSink* pDataSink)
2000-05-23 01:55:31 +00:00
{
2014-12-22 02:17:23 +00:00
if (pDataSink == NULL)
return kNuErrNone;
2000-05-23 01:55:31 +00:00
switch (pDataSink->sinkType) {
case kNuDataSinkToFile:
Nu_DataSinkFile_Close(pDataSink);
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
Nu_Free(NULL, pDataSink->toFile.pathnameUNI);
break;
case kNuDataSinkToFP:
break;
case kNuDataSinkToBuffer:
break;
case kNuDataSinkToVoid:
break;
case kNuDataSinkUnknown:
break;
default:
Assert(0);
return kNuErrInternal;
}
2000-05-23 01:55:31 +00:00
2014-12-22 02:17:23 +00:00
Nu_Free(NULL, pDataSink);
return kNuErrNone;
2000-05-23 01:55:31 +00:00
}
/*
* Create a data sink for an unopened file.
*/
NuError Nu_DataSinkFile_New(Boolean doExpand, NuValue convertEOL,
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
const UNICHAR* pathnameUNI, UNICHAR fssep, NuDataSink** ppDataSink)
{
NuError err;
if ((doExpand != true && doExpand != false) ||
(convertEOL != kNuConvertOff && convertEOL != kNuConvertOn &&
convertEOL != kNuConvertAuto) ||
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
pathnameUNI == NULL ||
fssep == 0 ||
2014-12-22 02:17:23 +00:00
ppDataSink == NULL)
{
return kNuErrInvalidArg;
}
err = Nu_DataSinkNew(ppDataSink);
BailErrorQuiet(err);
(*ppDataSink)->common.sinkType = kNuDataSinkToFile;
(*ppDataSink)->common.doExpand = doExpand;
if (doExpand)
(*ppDataSink)->common.convertEOL = convertEOL;
else
(*ppDataSink)->common.convertEOL = kNuConvertOff;
(*ppDataSink)->common.outCount = 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
(*ppDataSink)->toFile.pathnameUNI = strdup(pathnameUNI);
(*ppDataSink)->toFile.fssep = fssep;
2014-12-22 02:17:23 +00:00
(*ppDataSink)->toFile.fp = NULL;
2000-05-23 01:55:31 +00:00
bail:
return err;
2000-05-23 01:55:31 +00:00
}
/*
* Create a data sink based on a file pointer.
*/
NuError Nu_DataSinkFP_New(Boolean doExpand, NuValue convertEOL, FILE* fp,
NuDataSink** ppDataSink)
{
NuError err;
if ((doExpand != true && doExpand != false) ||
(convertEOL != kNuConvertOff && convertEOL != kNuConvertOn &&
convertEOL != kNuConvertAuto) ||
2014-12-22 02:17:23 +00:00
fp == NULL ||
ppDataSink == NULL)
{
return kNuErrInvalidArg;
}
err = Nu_DataSinkNew(ppDataSink);
BailErrorQuiet(err);
(*ppDataSink)->common.sinkType = kNuDataSinkToFP;
(*ppDataSink)->common.doExpand = doExpand;
if (doExpand)
(*ppDataSink)->common.convertEOL = convertEOL;
else
(*ppDataSink)->common.convertEOL = kNuConvertOff;
(*ppDataSink)->common.outCount = 0;
(*ppDataSink)->toFP.fp = fp;
2000-05-23 01:55:31 +00:00
bail:
return err;
2000-05-23 01:55:31 +00:00
}
/*
* Create a data sink for a buffer in memory.
*/
NuError Nu_DataSinkBuffer_New(Boolean doExpand, NuValue convertEOL,
uint8_t* buffer, uint32_t bufLen, NuDataSink** ppDataSink)
{
NuError err;
if ((doExpand != true && doExpand != false) ||
(convertEOL != kNuConvertOff && convertEOL != kNuConvertOn &&
convertEOL != kNuConvertAuto) ||
2014-12-22 02:17:23 +00:00
buffer == NULL ||
bufLen == 0 ||
2014-12-22 02:17:23 +00:00
ppDataSink == NULL)
{
return kNuErrInvalidArg;
}
err = Nu_DataSinkNew(ppDataSink);
BailErrorQuiet(err);
(*ppDataSink)->common.sinkType = kNuDataSinkToBuffer;
(*ppDataSink)->common.doExpand = doExpand;
if (doExpand)
(*ppDataSink)->common.convertEOL = convertEOL;
else
(*ppDataSink)->common.convertEOL = kNuConvertOff;
(*ppDataSink)->common.convertEOL = convertEOL;
(*ppDataSink)->common.outCount = 0;
(*ppDataSink)->toBuffer.buffer = buffer;
(*ppDataSink)->toBuffer.bufLen = bufLen;
(*ppDataSink)->toBuffer.stickyErr = kNuErrNone;
2000-05-23 01:55:31 +00:00
bail:
return err;
2000-05-23 01:55:31 +00:00
}
/*
* Create a data sink that goes nowhere.
*/
NuError Nu_DataSinkVoid_New(Boolean doExpand, NuValue convertEOL,
NuDataSink** ppDataSink)
2000-05-23 01:55:31 +00:00
{
NuError err;
2000-05-23 01:55:31 +00:00
Assert(doExpand == true || doExpand == false);
2014-12-22 02:17:23 +00:00
Assert(ppDataSink != NULL);
2000-05-23 01:55:31 +00:00
err = Nu_DataSinkNew(ppDataSink);
BailErrorQuiet(err);
2000-05-23 01:55:31 +00:00
(*ppDataSink)->common.sinkType = kNuDataSinkToVoid;
(*ppDataSink)->common.doExpand = doExpand;
(*ppDataSink)->common.convertEOL = convertEOL;
(*ppDataSink)->common.outCount = 0;
2000-05-23 01:55:31 +00:00
bail:
return err;
2000-05-23 01:55:31 +00:00
}
/*
* Get the type of a NuDataSink.
*/
NuDataSinkType Nu_DataSinkGetType(const NuDataSink* pDataSink)
2000-05-23 01:55:31 +00:00
{
2014-12-22 02:17:23 +00:00
Assert(pDataSink != NULL);
return pDataSink->sinkType;
2000-05-23 01:55:31 +00:00
}
/*
* Return the "doExpand" parameter from any kind of sink.
*/
Boolean Nu_DataSinkGetDoExpand(const NuDataSink* pDataSink)
2000-05-23 01:55:31 +00:00
{
return pDataSink->common.doExpand;
2000-05-23 01:55:31 +00:00
}
/*
* Return the "convertEOL" parameter from any kind of sink.
*/
NuValue Nu_DataSinkGetConvertEOL(const NuDataSink* pDataSink)
2000-05-23 01:55:31 +00:00
{
return pDataSink->common.convertEOL;
2000-05-23 01:55:31 +00:00
}
/*
* Return the #of bytes written to the sink.
*/
uint32_t Nu_DataSinkGetOutCount(const NuDataSink* pDataSink)
2000-05-23 01:55:31 +00:00
{
return pDataSink->common.outCount;
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
* Get "pathname" from a to-file sink. Returned string is UTF-8.
2000-05-23 01:55:31 +00:00
*/
const char* Nu_DataSinkFile_GetPathname(const NuDataSink* pDataSink)
2000-05-23 01:55:31 +00:00
{
2014-12-22 02:17:23 +00:00
Assert(pDataSink != NULL);
Assert(pDataSink->sinkType == kNuDataSinkToFile);
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
return pDataSink->toFile.pathnameUNI;
2000-05-23 01:55:31 +00:00
}
/*
* Get "fssep" from a to-file sink.
*/
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
UNICHAR Nu_DataSinkFile_GetFssep(const NuDataSink* pDataSink)
2000-05-23 01:55:31 +00:00
{
2014-12-22 02:17:23 +00:00
Assert(pDataSink != NULL);
Assert(pDataSink->sinkType == kNuDataSinkToFile);
2000-05-23 01:55:31 +00:00
return pDataSink->toFile.fssep;
2000-05-23 01:55:31 +00:00
}
/*
* Get the "fp" for a file sink.
*/
FILE* Nu_DataSinkFile_GetFP(const NuDataSink* pDataSink)
2000-05-23 01:55:31 +00:00
{
2014-12-22 02:17:23 +00:00
Assert(pDataSink != NULL);
Assert(pDataSink->sinkType == kNuDataSinkToFile);
2000-05-23 01:55:31 +00:00
return pDataSink->toFile.fp;
2000-05-23 01:55:31 +00:00
}
/*
* Set the "fp" for a file sink.
*/
void Nu_DataSinkFile_SetFP(NuDataSink* pDataSink, FILE* fp)
2000-05-23 01:55:31 +00:00
{
2014-12-22 02:17:23 +00:00
Assert(pDataSink != NULL);
Assert(pDataSink->sinkType == kNuDataSinkToFile);
2000-05-23 01:55:31 +00:00
pDataSink->toFile.fp = fp;
2000-05-23 01:55:31 +00:00
}
/*
* Close a to-file sink.
*/
void Nu_DataSinkFile_Close(NuDataSink* pDataSink)
2000-05-23 01:55:31 +00:00
{
2014-12-22 02:17:23 +00:00
Assert(pDataSink != NULL);
2000-05-23 01:55:31 +00:00
2014-12-22 02:17:23 +00:00
if (pDataSink->toFile.fp != NULL) {
fclose(pDataSink->toFile.fp);
2014-12-22 02:17:23 +00:00
pDataSink->toFile.fp = NULL;
}
2000-05-23 01:55:31 +00:00
}
/*
* Write a block of data to a DataSink.
*/
NuError Nu_DataSinkPutBlock(NuDataSink* pDataSink, const uint8_t* buf,
uint32_t len)
2000-05-23 01:55:31 +00:00
{
NuError err;
2014-12-22 02:17:23 +00:00
Assert(pDataSink != NULL);
Assert(buf != NULL);
Assert(len > 0);
switch (pDataSink->sinkType) {
case kNuDataSinkToFile:
2014-12-22 02:17:23 +00:00
Assert(pDataSink->toFile.fp != NULL);
err = Nu_FWrite(pDataSink->toFile.fp, buf, len);
if (err != kNuErrNone)
return err;
break;
case kNuDataSinkToFP:
2014-12-22 02:17:23 +00:00
Assert(pDataSink->toFP.fp != NULL);
err = Nu_FWrite(pDataSink->toFP.fp, buf, len);
if (err != kNuErrNone)
return err;
break;
case kNuDataSinkToBuffer:
if (len > pDataSink->toBuffer.bufLen) {
/* buffer overrun; set a "sticky" error, like FILE* does */
err = kNuErrBufferOverrun;
pDataSink->toBuffer.stickyErr = err;
return err;
}
memcpy(pDataSink->toBuffer.buffer, buf, len);
pDataSink->toBuffer.buffer += len;
pDataSink->toBuffer.bufLen -= len;
break;
case kNuDataSinkToVoid:
/* do nothing */
break;
default:
Assert(false);
return kNuErrInternal;
}
pDataSink->common.outCount += len;
return kNuErrNone;
2000-05-23 01:55:31 +00:00
}
/*
* Figure out if one of our earlier writes has failed.
*/
NuError Nu_DataSinkGetError(NuDataSink* pDataSink)
2000-05-23 01:55:31 +00:00
{
NuError err = kNuErrNone;
2014-12-22 02:17:23 +00:00
Assert(pDataSink != NULL);
switch (pDataSink->sinkType) {
case kNuDataSinkToFile:
if (ferror(pDataSink->toFile.fp))
err = kNuErrFileWrite;
break;
case kNuDataSinkToFP:
if (ferror(pDataSink->toFP.fp))
err = kNuErrFileWrite;
break;
case kNuDataSinkToBuffer:
err = pDataSink->toBuffer.stickyErr;
break;
case kNuDataSinkToVoid:
/* do nothing */
break;
default:
Assert(false);
err = kNuErrInternal;
break;
}
return err;
2000-05-23 01:55:31 +00:00
}