This form contains a series of questions that need to be answered. As you go about answering the questions, please keep the following things in mind:While it is not required that each question be answered at this time, all questions must have answers before the response is submitted to The Open Group for review and publication.Press the "Save" button at any time to save work in progress. Once the work has been saved, there is the option to continue editing if required.Many questions have instructions to assist in development of answers. They are marked with the indicator. Please look at the instructions carefully.Although HTML markup can be included in answers, this is not recommended apart from basic tags such as <p> and <br>, since incorrect markup could effect the format of other items in the document.Questions on this system should be addressed to the Conformance Statement manager at The Open Group.
Enter the name of the Organization that produced the implementation and the name of the author of the Conformance Statement.
A product may be registered in all members of a binary-compatible family of products on the basis of a single test report.
Answer the questions for each binary-compatible family. Alternately, provide the answers in the Appendix at the end of this document.
Question 1: Which of the following Feature Groups are supported by the implementation?
Response
The POSIX.2 C-language Binding, Shared Memory, Enhanced Internationalisation and X/Open UNIX Extension Feature Groups are mandatory for Internationalised System Calls and Libraries Extended conformance.
Support for a Feature Group can only be claimed if all interfaces in that group behave according to the relevant descriptions in System Interfaces and Headers, Issue 4, Version 2.
The interfaces in the Encryption Feature Group must exist, whether or not the Feature Group is supported, and each interface must either behave according to the description in System Interfaces and Headers, Issue 4, Version 2, or indicate an error, with errno set to [ENOSYS].
Rationale
System Interfaces and Headers, Issue 4, Version 2 states that the system may provide one or more of the Feature Groups listed. XPG4 Components, version 2 states that the POSIX.2 C-language Binding, Shared Memory, Enhanced Internationalisation and X/Open UNIX Extension Feature Groups are mandatory for compliance to the Internationalised System Calls and Libraries Extended component.
Reference
CAE Specification, System Interfaces and Headers, Issue 4, Version 2, Section 1.2, Conformance and Section 1.3, Feature Groups.
Internationalised System Calls and Libraries Extended Product Standard Definition.
Question 2: Which of the following options, specified in the <unistd.h> header file, are available on the system?
Where indicated in the following table, select one of the options given (either "Yes" or "Variable"). Select "Variable" if there are system dependent or file_system dependent configuration procedures that can remove or modify any or all of these features.
For a conformant implementation, all of these POSIX features must be provided. In some cases the feature need not be provided for all files or devices supported by the implementation.
CAE Specification, System Interfaces and Headers, Issue 4, Version 2, Chapter 4, Headers, <unistd.h>.
Question 3: What are the values associated with the following constants specified in the <float.h> header file?
This set of constants provides useful information regarding the underlying architecture of the implementation.
CAE Specification, System Interfaces and Headers, Issue 4, Version 2, Chapter 4, Headers, <float.h>.
Question 4: What are the values associated with the following constants (optionally specified in the <limits.h> header file)?
Each of these limits can vary within bounds set by System Interfaces and Headers, Issue 4, Version 2. The minimum permitted value is specified in Chapter 4, <limits.h>.
CAE Specification, System Interfaces and Headers, Issue 4, Version 2, Chapter 4, Headers, <limits.h>.
Question 5: What are the values associated with the following constants specified in the <limits.h> header file?
For each line in the table below, add the minimum and maximum values for your implementation. These values may be stated to be "Unlimited" if your implementation does not impose a limit. The minimum should be the smallest value that is returned from sysconf(), pathconf(), or fpathconf(), or as defined in <limits.h>. The maximum value should be the largest value that is returned from sysconf(), pathconf(), or fpathconf(). Macro NameMeaningMinimumMaximum BC_BASE_MAX Maximum ibase and obase values allowed by the bc utility. BC_DIM_MAX Maximum number of elements permitted in an array by the bc utility. BC_SCALE_MAX Maximum scale value allowed by the bc utility. BC_STRING_MAX Maximum length of a string constant accepted by the bc utility. COLL_WEIGHTS_MAX Maximum number of weights that can be assigned to an entry of the LC_COLLATE order keyword in the locale definition file. EXPR_NEST_MAX Maximum number of expressions that can be nested within parentheses by the expr utility. LINE_MAX Maximum length in bytes including the trailing newline of a utility's input line when the utility is described as processing text files. NGROUPS_MAX Maximum number of simultaneous supplementary group IDs per process. RE_DUP_MAX Maximum number of repeated occurrences of a regular expression permitted when using interval notation.
Each of these limits can vary within bounds set by System Interfaces and Headers, Issue 4, Version 2. The minimum value that a limit can take on any conforming system is given in the corresponding _POSIX_ or _POSIX2_ value. A specific conforming implementation may provide a higher minimum value than this and the maximum value that it provides can differ from the minimum. Some conforming implementations may provide a potentially infinite value as the maximum, in which case the value is considered to be indeterminate. The minimum value must always be definitive since the _POSIX_ or _POSIX2_ value provides a known lower bound for the range of possible values.
Question 6: What are the values associated with the following numerical constants specified in the <limits.h> header file?
Question 7: What are the values associated with the following numerical constants specified in the <stdio.h> header file?
This set of constants provide useful information about the implementation.
CAE Specification, System Interfaces and Headers, Issue 4, Version 2, Chapter 4, Headers, <stdio.h>.
Question 8: Which of the following option errors listed in System Interfaces and Headers, Issue 4, Version 2 are detected in the circumstances specified?
Each of the above error conditions is marked as optional in System Interfaces and Headers, Issue 4, Version 2 and an implementation may return this error in the circumstances specified or may not provide the error indication.
CAE Specification, System Interfaces and Headers, Issue 4, Version 2, Section 2.3, Error Numbers.
Question 9: What format of floating-point numbers is supported by this implementation?
Either use the default answer or provide a description of the floating point format used by your implementation.
Most implementations support IEEE floating point format either in hardware or software. Some implementations support other formats with different exponent and mantissa accuracy. These differences need to be defined.
CAE Specification, System Interfaces and Headers, Issue 4, Version 2, Section 1.6, Relationship to Formal Standards.
Question 10: Are the optional data encryption interfaces provided?
Mark each of the following table entries appropriately. If your implementation is effected by any export restrictions imposed by the US Government, indicate these restrictions in the following area.
Export Restrictions:
Normally, an implementation will either provide all three of these routines or will provide none of them at all. If the routines are not provided, then the implementation must provide a dummy interface which always raises an ENOSYS error condition.
It is also possible that the implementation of the encrypt() function may be affected by export restrictions, in which case, the restrictions should be documented here.
For example, historical implementations have supplied all three of these routines outside the U.S.A., but due to export restrictions on the decoding algorithm, a dummy version of encrypt() is provided that does encoding but no decoding.
CAE Specification, System Interfaces and Headers, Issue 4, Version 2, Section 1.2, Conformance.
Question 11: Which file types (regular, directory, FIFO, special, and so on) are considered to be executable?
Enter the file types that are executable on your implementation in the area below.
The [EACCES] error associated with exec functions occurs in circumstances when the implementation does not support execution of files of the type specified. A list of these file types needs to be provided.
CAE Specification, System Interfaces and Headers, Issue 4, Version 2, Chapter 3, System Interfaces, exec.
Question 12: What file access control mechanisms does the implementation provide?
Either indicate that "Standard access control is provided.", that the reader should "Refer to the POSIX.1 Conformance Document, Section 2.4", or provide a detailed description of the access control and/or additional or alternate access mechanisms on your implementation.
System Interfaces and Headers, Issue 4, Version 2 notes that implementations may provide additional or alternate file access control mechanisms, or both.
CAE Specification, System Interface Definitions, Issue 4, Version 2, Chapter 2, Glossary, file access permissions.
Question 13: Are any additional or alternate file access control mechanisms implemented that could cause fstat() or stat() to fail?
Yes No
System Interfaces and Headers, Issue 4, Version 2 notes that there could be an interaction between additional and alternate access controls and the success of fstat() and stat(). This would suggest that an implementation can allow access to a file but not allow the process to gain information about the status of the file.
CAE Specification, System Interfaces and Headers, Issue 4, Version 2, Chapter 3, System Interfaces, fstat() and stat().
Question 14: Does the printf() function produce character string representations for Infinity and NaN to represent the respective values?
This behaviour is often provided on systems with mathematical functions that produce these results.
CAE Specification, System Interfaces and Headers, Issue 4, Version 2, Chapter 3, System Interfaces, fprintf().
Question 15: What coded character sets are supported by the implementation?
System Interface Definitions, Issue 4, Version 2 states that conforming implementations support one or more coded character sets, and that each of these includes the portable character set.
CAE Specification, System Interface Definitions, Issue 4, Version 2, Chapter 4, Character Set.
Question 16: What is the implementation's underlying internal codeset?
If the implementation does not use ISO 8859-1:1987, provide the name or description of the underlying codeset.
It is useful to be aware of the underlying codeset of the implementation.
Question 17: What networking services or other character-based I/O device types are implemented using STREAMS?
Enter the device types that are streams-based on this implementation. If your implementation does not support streams, state None.
System Interfaces and Headers, Issue 4, Version 2, defines that STREAMS provide a uniform mechanism for implementing networking services and other character-based I/O. However, the specification does not mandate which device or file types should be STREAMS-based. Although applications are discouraged from making assumptions in this area, it may be that certain applications are sensitive to whether interfaces such as getmsg() and putmsg(), for example, are supported on specific device or file types.
CAE Specification, System Interfaces and Headers, Issue 4, Version 2, Section 2.5, STREAMS.
Question 18: Does closing the master side of a pseudo-terminal flush all queued input and output?
The behaviour of a conforming implementation in this area is not mandated in the specification and needs to be defined.
CAE Specification, System Interfaces and Headers, Issue 4, Version 2, Chapter 3, System Interfaces, close().
Question 19: Does closing the slave side of a pseudo-terminal cause a zero-length message to be sent to the master?
Question 20: What naming conventions are associated with the master side of pseudo-terminal devices?
This information is not specified in System and Interfaces, Issue 4, Version 2, and needs to be be defined.
CAE Specification, System Interfaces and Headers, Issue 4, Version 2, Chapter 3, System Interfaces, open().
Question 21: What types of file can be polled?
Update the following list with any additional implementation-specific file types that can be polled.
Conformance requires that the poll() function supports regular files, terminals, pseudo-terminals, STREAMS, sockets, FIFOs and pipes. The behaviour of poll() with regards to other file types needs to be defined.
CAE Specification, System Interfaces and Headers, Issue 4, Version 2, Chapter 3, System Interfaces, poll().
Question 22: What allocation routine(s) is provided for creating alternate stack areas?
Conformance requires that an implementation supports alternate signal stacks. The APPLICATION USAGE section of the sigaltstack() entry describes one method using malloc() to perform this function. However, the specification does not guarantee that malloc'ed space can be used in this way, nor does it define a specific alternate stack allocation routine.
CAE Specification, System Interfaces and Headers, Issue 4, Version 2, Chapter 3, System Interfaces, sigaltstack().
Question 23: Which of the following si_code values may be generated?
An Internationalised System Calls and Libraries Extended conformant system may contain limitations that prevent some of the above values from being generated.
CAE Specification, System Interfaces and Headers, Issue 4, Version 2, Chapter 4, Headers, <signal.h>.
Question 24: Does the setpgrp() function create a new session?
It is unspecified whether or not a successful call to the setpgrp() function will cause a new session to be created.
CAE Specification, System Interfaces and Headers, Issue 4, Version 2, Chapter 3, System Interfaces, setpgrp().
Question 25: Does the implementation provide a signal, when delivered to a process, that generates a core file?
Implementation-dependent abnormal termination actions, such as creation of a core file, may occur.
Copyright © All rights reserved.