We just make these aliases for snprintf, which should work fine for all valid cases given our calling convention. Since they are actually implemented via snprintf (and the printf machinery in general), they are in stdio.asm, even though the functions are declared in <stdlib.h>.
Note that the input for strndup is not required to be a null-terminated string, so we need to avoid using operations like strlen on it. Also, we limit the length allocated for strndup to the minimum of n+1 or the length needed to hold the whole input string. Some implementations might always allocate n+1 bytes, but that could lead to avoidable allocation failures on a fairly memory-constrained system like the IIGS.
Note that this returns the actual alignment of the address, which can be greater than what can be used with alignas. In IIGS-specific code, it could be used to test for page or bank alignment.
The previous code could fail for times within the first or last few hours of the representable range, depending on the time zone. Specifically, it failed for times that would be outside the representable range if they were local time, but were representable when they were UTC times due to the time zone offset.
Several of the multiplies and divides are now implemented via shifts and additions, which should be significantly faster. (These also take advantage of the limited range of operands to use only 16-bit operations where possible.)
This uses a "year length" slightly longer than the real average. Because our (time_t)0 is November 13, this brings the cutoffs for the year estimates closer to the end of the year as years pass, which reduces the number of dates for which the initial estimate is incorrect. This means that there are fewer instances where an extra factor call is required, so it should produce a slight speedup on average.
If we ever move to 64-bit time_t, this fudge factor would have to be removed, since it is only valid within our 32-bit time_t range.
This now requires only one factor call for the year computation. Previously, year-1969 factor calls were required, so the new approach is significantly faster.
These are supported both with base=0 (where they indicate the number is in binary) and with base=2 (where the prefix is optional and does not change the base).
When base is 0 or 16 and the numeric part of the string (after possible leading white space and/or sign) starts with 0x or 0X but is not followed by a hex digit, only the 0 should be taken as part of the subject sequence. Thus, this is not an error condition (errno should not be set), the result should be 0, and if endptr is non-null, *endptr should be set to point to the x or X.
Note that like with fprintf, unsupported wN/wfN length modifiers do not cause undefined behavior. In the case of fscanf, they are handled similarly to a matching failure. In such cases, we assume that there was a pointer-sized parameter passed corresponding to the unsupported conversion (unless assignment was suppressed), so that and any parameters matching the rest of the format string are removed from the stack.
Note that fprintf is specified as returning a negative number for unsupported wN/wfN length modifiers (i.e. it's not undefined behavior). This implements that behavior. However, there's no good way to know how many parameter bytes were passed for the unsupported conversion, and thus no way no pull those and subsequent parameter bytes off the stack. Accordingly, we just leave them on the stack. That works fine if the caller has varargs stack repair code enabled, but not otherwise, so this is another situation where varargs stack repair code is necessary for full standards conformance. This generally shouldn't be an issue for real code, since we support the power-of-2 widths from 8 to 64, which are the only ones likely to be used in practice.
This makes the code slightly smaller and faster. It also fixes a theoretical bug, which is that the old code would report a matching failure if the number of digits was a multiple of 64K (of course, this would only have defined behavior if the vast majority of the digits were leading zeros).
Like in other places, the binary number support is conditional on ~C23ORLATER.
This is implemented by integrating the code for scanf 'i' and 'd' formats with the formats for unsigned integers. This shrinks the code size and reduces duplication. It also fixes at least one bug, which is that if a hexadecimal number was used as input to an 'i' conversion, the next character after it could be changed, e.g. capitalizing a letter.
A new label is added in the library named ~C23ORLATER. Its presence in the executable acts as a flag for enabling C23 library behavior, including the new 'b' format. The compiler will generate a reference to it when compiling a program in C23 mode, causing it to be linked in. This can then be detected in library code by including a soft (weak) reference to it, which will be non-zero if the flag is linked in (C23+) or zero if it is not (pre-C23).
This prints integers in binary, with an optional '0B' prefix. It is specified but optional in C23.
The similar 'b' format (differing only in the case used for the '0b' prefix) is required in C23, but not yet implemented here, since 'b' has historically been used for something different in ORCA/C. The C23 'b' format would be simple to implement with small adjustments to the entry code, but I plan to provide compatibility support to pick between the two versions based on the standard in use.
The ORCA/C compiler was updated to support 32-bit line numbers some time ago (as required by C99 and later), so assert should support them as well.
The code to return from any of the assert calls is also removed, since it was unreachable.
In some implementations, these functions could potentially be faster than free() and/or perform additional safety checks, but this implementation just ignores the extra arguments.
This is just equivalent to memset in ORCA/C, since there are no optimizations that would remove memset operations. Note that in addition to clearing the old data in memory, this implementation of memset/memset_explicit also will not leave any of the old data in registers or in the stack space that it used.
This implementation includes synchronization suitable for multithreading (albeit with inefficient busy waiting), even though ORCA/C does not currently support that. This could potentially be used with forked processes under GNO.
This is documented in TBR3 and is already declared in <misctool.h>, but did not previously have glue code. TBR3 says "Applications should never make this call," but it may be useful in system utilities.
This moves the free() call for the file buffer before the malloc() that occurs when closing a temp file, which should at least slightly reduce the chances that the malloc() call fails.
Previously, the code for closing a temporary file assumed that malloc would succeed. If it did not, the code would trash memory and (at least in my testing) crash the system. Now it checks for and handles malloc failures, although they will still lead to the temporary file not being deleted.
Here is a test program illustrating the problem:
#include <stdio.h>
#include <stdlib.h>
int main(void) {
FILE *f = tmpfile();
if (!f)
return 0;
void *p;
do {
p = malloc(8*1024);
} while (p);
fclose(f);
}
This can happen, e.g., if there is an IO error or if there is insufficient free disk space to flush the data. In this case, fclose should return -1 to report an error, but it should still effectively close the stream and deallocate the buffer for it. (This behavior is explicitly specified in the C99 and later standards.)
Previously, ORCA/C effectively left the stream open in these cases. As a result, the buffer was not deallocated. More importantly, this could cause the program to hang at exit, because the stream would never be removed from the list of open files.
Here is an example program that demonstrates the problem:
/*
* Run this on a volume with less than 1MB of free space, e.g. a floppy.
* The fclose return value should be -1 (EOF), indicating an error, but
* the two RealFreeMem values should be close to each other (indicating
* that the buffer was freed), and the program should not hang on exit.
*/
#include <stdio.h>
#include <stddef.h>
#include <memory.h>
#define BUFFER_SIZE 1000000
int main(void) {
size_t i;
int ret;
printf("At start, RealFreeMem = %lu\n", RealFreeMem());
FILE *f = fopen("testfile", "wb");
if (!f)
return 0;
setvbuf(f, NULL, _IOFBF, BUFFER_SIZE);
for (i = 0; i < BUFFER_SIZE; i++) {
putc('x', f);
}
ret = fclose(f);
printf("fclose return value = %d\n", ret);
printf("At end, RealFreeMem = %lu (should be close to start value)\n",
RealFreeMem());
}
This fixes the following issues:
*If n was 0x80000000 or greater, strncmp would return 0 without performing a comparison.
*If n was 0x1000000 or greater, strncmp might compare fewer characters than it should because the high byte of n was effectively ignored, causing it to return 0 when it should not.
Here is an example demonstrating these issues:
#pragma memorymodel 1
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#define LEN 100000
int main(void) {
char *s1 = malloc(LEN+1);
char *s2 = malloc(LEN+1);
if (!s1 || !s2)
return 0;
for (unsigned long i = 0; i < LEN; i++) {
s2[i] = s1[i] = '0' + (i & 0x07);
}
s1[LEN] = 'x';
return strncmp(s1,s2,0xFFFFFFFF);
}
This addresses the following issues:
*If the low-order 16 bits of n were 0x0000, no concatenation would be performed.
*If n was 0x1000000 or greater, the output could be cut off prematurely because the high byte of n was effectively ignored.
The following test program demonstrates these issues:
#pragma memorymodel 1
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#define LEN2 100000
int main(void) {
char *s1 = malloc(LEN2+2);
char *s2 = malloc(LEN2+1);
if (!s1 || !s2)
return 0;
for (unsigned long i = 0; i < LEN2; i++)
s2[i] = '0' + (i & 0x07);
strcpy(s1,"a");
strncat(s1, s2, 0x1000000);
puts(s1);
printf("len = %zu\n", strlen(s1));
}
There were two issues:
*If bit 15 of the n value was set, the second string would not be copied.
*If the length of the second string was 64K or more, it would not be copied properly because the pointers were not updated.
This test program demonstrates both issues:
#pragma memorymodel 1
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#define LEN2 100000
int main(void) {
char *s1 = malloc(LEN2+2);
char *s2 = malloc(LEN2+1);
if (!s1 || !s2)
return 0;
for (unsigned long i = 0; i < LEN2; i++)
s2[i] = '0' + (i & 0x07);
strcpy(s1,"a");
strncat(s1, s2, LEN2);
puts(s1);
printf("len = %zu\n", strlen(s1));
}
Previously, the pointer was not properly updated to account for the bank crossing, so the characters from the second string would be written to the wrong bank.
Here is an example that illustrates this:
#include <memory.h>
#include <string.h>
#include <orca.h>
#include <stdio.h>
int main(void) {
Handle hndl = NewHandle(0x1000f, userid(), 0xC000, 0);
if (toolerror())
return 0;
char *s = *hndl;
s = (void*)((unsigned long)s | 0xffff);
strcpy(s, "foo");
strcat(s, "bar");
strncat(s, "baz", 5);
puts(s);
}
If the format string is empty or contains only %n conversions, then nothing should be read from the stream, so no error should be indicated even if it is at EOF. If a directive does read from the stream and encounter EOF, that will be handled when the directive is processed.
This could cause scanf to pause waiting for input from the console in cases where it should not.
This uses an approximation based on the Stirling series for most positive values, but uses separate rational approximations for greater accuracy near 1 and 2. A reflection formula is used for negative values.
These are similar enough that they can use the same code with just a few conditionals, which saves space.
(This same code can also be used for binary when that is added.)
These print a floating-point number in a hexadecimal format, with several variations based on the conversion specification:
Upper or lower case letters (%A or %a)
Number of digits after decimal point (precision)
Use + sign for positive numbers? (+ flag)
Use leading space for positive numbers (space flag)
Include decimal point when there are no more digits? (# flag)
Pad with leading zeros after 0x? (0 flag)
If no precision is given, enough digits are printed to represent the value exactly. Otherwise, the value is correctly rounded based on the rounding mode.
This is what the standards require. Previously, the '0' flag would effectively override '-'.
Here is a program that demonstrates the problem:
#include <stdio.h>
int main(void) {
printf("|%-020d|\n", 123);
printf("|%0-20d|\n", 123);
printf("|%0*d|\n", -20, 123);
}
This tries to carefully follow the C and IEEE standards regarding rounding, exceptions, etc. Like the other ORCA/C <math.h> functions, there is really just one version that has extended precision, so double rounding is still possible if the result gets assigned to a float or double variable.
In addition to the tests I added to the ORCA/C test suite, I have also tested this against (somewhat modified versions of) the following:
*FreeBSD fma tests by David Schultz:
https://github.com/freebsd/freebsd-src/blob/release/9.3.0/tools/regression/lib/msun/test-fma.c
*Tests by Bruno Haible, in the Gnulib test suite and attached to this bug report:
https://sourceware.org/bugzilla/show_bug.cgi?id=13304
Previously, the functions registered with atexit() would be called with data bank corresponding to the blank segment, which is correct in the small memory model but not necessarily in the large memory model. This could cause memory corruption or misbehavior for certain operations accessing global variables.
ORCA/C's tmpnam() implementation is designed to use prefix 3 if it is defined and the path is sufficiently short. I think it was intended to allow up to a 15-character disk name to be specified, but it used a GS/OS result buffer size of 16, which only leaves 12 characters for the path, including initial and terminal : characters. As such, only up to a 10-character disk name could be used. This patch increases the specified buffer size to 21, allowing for a 17-character path that can encompass a 15-character disk name.
If the last element in the range being sorted has the smallest value, rsort can be called with last set to first-1, i.e. pointing to (what would be) the element before the first one. But with large enough element sizes and appropriate address values, this address computation can wrap around and produce a negative value for last. We need to treat such a value as being less than first, so it terminates that branch of the recursive computation. Previously, we were doing an unsigned comparison, so such a last value would be treated as greater than first and would lead to improper behavior including memory trashing.
Here is an example program that can show this (depending on memory layout):
#pragma memorymodel 1
#include <stdlib.h>
#include <stdio.h>
#define PADSIZE 2000000 /* may need to adjust based on memory size/layout */
#define N 2
struct big {
int i;
char pad[PADSIZE];
};
int cmp(const void *p1, const void *p2) {
int a = ((struct big *)p1)->i;
int b = ((struct big *)p2)->i;
return (a < b) ? -1 : (a > b);
}
int main(void) {
int j;
struct big *p = malloc(sizeof(struct big) * N);
if (!p)
return 0;
for (j = 0; j < N; j++) {
p[j].i = N-j;
}
qsort(p, N, sizeof(struct big), cmp);
for (j = 0; j < N; j++) {
printf("%i\n", p[j].i);
}
}
It could have O(n) recursion depth for some inputs (e.g. if already sorted or reverse sorted), which could easily cause stack overflows.
Now, recursion is only used for the smaller of the two subarrays at each step, so the maximum recursion depth is bounded to log2(n).
When using the large memory model, the wrong data bank (that of the library code rather than the program's static data) would be in place when the comparison function was called, potentially leading to data corruption or other incorrect behavior.
This code did not previously work properly, because the X register value was overwritten within the loop. This could result in incorrect behavior such as hanging or data corruption when using qsort with element sizes >= 64KiB.
This is used by the new ORCA/C debugging option to check for illegal use of null pointers. It is similar to an existing routine in PasLib used by ORCA/Pascal's similar checks.
This ensures use of the Time Tool is fully under the control of the programmer, rather than potentially being affected by other things that may load it (like the Time Zone CDev). It also avoids calls to tiStatus in the default non-Time Tool code paths, and thereby allows them to work under Golden Gate.
The UTC time may be several hours before or after local time, and therefore the UTC time/date may be slightly outside the limits of what can be represented as a local time/date. This is now handled correctly.
This also more generally fixes handling of negative seconds/minutes/hours, which is also applicable to mktime().
ORCA/C uses an unsigned 32-bit time_t which should give a range up to 2105, but calculations on it were being done with signed types, causing them not to work correctly beyond 2036-2038. Now the factor routine, mktime(), and time() should work up to 2105. (In the case of time(), this assumes ReadTimeHex reports the time correctly.)
The factor routine actually computes a 64-bit time value. Currently, the rest of the code only takes the bottom 32 bits of it, but this could be extended if we ever wanted to switch to 64-bit time_t.
It was clearly supposed to be 1 Jan 1970, but it's actually not, probably because the number of days from 1 Jan 1900 to 1 Jan 1970 was miscalculated. Changing it now could potentially cause compatibility issues (especially for GNO, which uses time_t in some kernel call interfaces and file formats), so for now it is left as is and just documented appropriately.
Nothing in the C standards requires the time_t epoch to be 1 Jan 1970, so this does not cause any standards-compliance problem for the C standards. (It is different from POSIX, though.)
This is used for the %z conversion specifier (giving the time zone offset in +-HHMM format). The %Z conversion specifier (giving the locale's time zone name or abbreviation) also prints the same thing for now.
As with gmtime, this will only use the Time Tool Set if it has already been started. Otherwise, these conversions simply produce no output.
If the Time Tool Set (tool 56, by Geoff Weiss) is present and active, gmtime will use it (plus the DST flag) to determine the local time offset from UTC, allowing it to produce the correct UTC time. If not, it will still treat local time as being equal to UTC, like it did previously.
The library code will not try to load or start the Time Tool Set, so the program will have to do that before calling gmtime if it wants to use this functionality.
Previously, 1-4 low-order bits of the input value were essentially ignored when calculating the numerator, but used to some degree when calculating the denominator. This would lead to the calculated tgamma values decreasing slightly over the range of several consecutive input values (when they should increase). Now, the low-order bits of the input value are effectively just rounded away. This should give slightly more accurate results, and greatly reduces the frequency of cases where consecutive output values go in the wrong direction.
This uses an approximation based on the Stirling series for large enough x (for which it is highly accurate). For smaller x, identities are used to express gamma(x) in terms of gamma(x+1) or gamma(1-x), ultimately letting the Stirling series approximation be used.
This implementation is based on the approximations given in the following paper:
W. J. Cody, Rational Chebyshev Approximations for the Error Function, Mathematics of Computation, Vol. 23, No. 107 (Jul., 1969), pp. 631-637.
Per the paper, the approximations have maximal relative error of 6e-19 or lower (although I have not verified what the figure is for this actual implementation).
See also Cody's FORTRAN implementation based on the same approach:
https://netlib.org/specfun/erf
The new CDev root code generated by ORCA/C will now branch to this code after each CDev call, giving it an opportunity to clean up if necessary. Specifically, it will dispose of the user ID allocated for the CDev if it is going away after this call. There are several cases where this occurs, which need to be detected based on the message code passed to the CDev and in some cases other factors.
Bugs fixes:
*fgets() would write 2 bytes in the buffer if called with n=1 (should be 1).
*fgets() would write 2 bytes in the buffer if it encountered EOF before reading any characters, but the EOF flag had not previously been set. (It should not modify the buffer in this case.)
*fgets() and gets() would return NULL if EOF was encountered after reading one or more characters. (They should return the buffer pointer).
The direction specified by the offset was essentially reversed when calling lseek with whence==2 (seek to offset from end of file). Therefore, specifying a negative offset with whence==2 would fail, rather than seeking before the end of the file as it should.
(The ORCA/C manual is not totally clear about this behavior, but the new behavior is consistent with the POSIX spec and all other implementations I'm aware of, including traditional Unix and APW C. Note that Unix/POSIX allows seeking beyond the end of the file, but GS/OS does not.)
There are also improvements to error handling, so lseek consistently reports EINVAL for invalid offsets.
This differs from the existing ~UMul2 in SysLib in that it gives the low-order 16 bits of the true result in the event of overflow. The C standards require this behavior for computations on unsigned types.
The __-prefixed versions were introduced for use in <stdio.h> macros that have since been removed, so they are not really necessary any more. However, they may be used in old object files, so those symbols are still included for now.
The error could occur because fseek calls fflush followed by ftell. fflush would reset the file position as if the characters in the putback buffer were removed, but ftell would still see them and try to adjust for them (in the case of a read-only file). This could result in trying to seek before the beginning of the file, producing an error.
Here is a program that was affected:
#include <stdio.h>
int main(void) {
FILE *f = fopen("somefile","r");
if (!f) return 0;
fgetc(f);
ungetc('X', f);
fseek(f, 0, SEEK_CUR);
if (ferror(f)) puts("error encountered");
}
This maintains the invariant that these flags stay set to reflect the setting of the stream as read-only or write-only, allowing code elsewhere to behave appropriately based on that.
Stephen Heumann