Hi,
On Mon, Apr 21, 2025 at 05:25:48PM +0200, Quentin Rameau wrote:
> > > > I noticied today that the libc man pages are basically the
> > > > sections of the daft C99 standard. Giving that it is allowed to
> > > > redistibute the draft or any part of it (checked with a member of
> > > > the WG14) we should remove them from the repository.
> > >
> > > Why should we?
> > > Isn't it handy to provide those?
> >
> > The problem is that the C99 specs *cannot* be re distributed
> > (important typo in the original mail). In theory, we could
> > be taken to court because we are distributing them. The problem
> > is that Naveem almost copied verbatim the specs. In order to
> > have them we would have to rephrase all the man pages.
>
> Ah yeah, I missed the following email correcting the wording :D
>
> Buuut, while this kind of make sense, this is *everywhere*
> in the ecosystem.
>
> Like it's in POSIX that copies almost verbatim the C* standard,
> in turn it's also in the “POSIX man-pages” for example.
>
> I'm not sure about the GNU libc man-pages, but I assume it's
> pretty well the same. Maybe they changed a word here and there.
Let me put some examples:
- ISO/IEC 9899:1999 Section 7.13.1.1 Paragraph 1,2,3
- ISO/IEC 9899:1999 Section 7.13.2.1 Paragraph 1,2,3,4
The setjmp macro saves its calling environment in its jmp_buf
argument for later use by the longjmp function.
The longjmp function restores the environment saved by the most
recent invocation of the setjmp macro in the same invocation of the
program with the corresponding jmp_buf argument. If there has been
no such invocation, or if the function containing the invocation
of the setjmp macro has terminated execution217) in the interim,
or if the invocation of the setjmp macro was within the scope of
an identifier with variably modified type and execution has left
that scope in the interim, the behavior is undefined.
All accessible objects have values, and all other components of the
abstract machine218) have state, as of the time the longjmp function
was called, except that the values of objects of automatic storage
duration that are local to the function containing the invocation
of the corresponding setjmp macro that do not have volatile-qualified
type and have been changed between the setjmp invocation and longjmp
call are indeterminate.
Returns:
If the return is from a direct invocation, the setjmp macro returns
the value zero. If the return is from a call to the longjmp function,
the setjmp macro returns a nonzero value.
After longjmp is completed, program execution continues as if the
corresponding invocation of the setjmp macro had just returned the
value specified by val. The longjmp function cannot cause the setjmp
macro to return the value 0; if val is 0, the setjmp macro returns
the value 1.
- scc man page
The setjmp() function saves it calling environment in its argument env
for later use by the longjmp.
The longjmp() function restores the environment saved by the most re‐
cent invocation of setjmp in the same invocation of the program with
the corresponding env as argument.
If there has been no such invocation, or if the function containing the
invocation of setjmp has terminated execution, or if the invocation of
setjmp was within the scope of an identifier with variably modified
type and execution has left that scope in interim, the behavior is un‐
defined.
RETURN VALUE
If the return is from a direct invocation, setjmp shall return the
value zero. If the return is from a call to longjmp, setjmp shall re‐
turn a nonzero value.
After the function longjmp is called, program execution continues as if
the corresponding invocation of setjmp has just returned the value
specified by val. The function longjmp shall not cause the function
setjmp to return the value 0. If val is set to 0, setjmp shall return
the value 1.
- glibc man page
The functions described on this page are used for performing "nonlocal
gotos": transferring execution from one function to a predetermined
location in another function. The setjmp() function dynamically
establishes the target to which control will later be transferred, and
longjmp() performs the transfer of execution.
The setjmp() function saves various information about the calling
environment (typically, the stack pointer, the instruction pointer,
possibly the values of other registers and the signal mask) in the
buffer env for later use by longjmp(). In this case, setjmp() returns
0.
The longjmp() function uses the information saved in env to transfer
control back to the point where setjmp() was called and to restore
("rewind") the stack to its state at the time of the setjmp() call. In
addition, and depending on the implementation (see NOTES), the values
of some other registers and the process signal mask may be restored to
their state at the time of the setjmp() call.
Following a successful longjmp(), execution continues as if setjmp()
had returned for a second time. This "fake" return can be
distinguished from a true setjmp() call because the "fake" return
returns the value provided in val. If the programmer mistakenly passes
the value 0 in val, the "fake" return will instead return 1.
RETURN VALUE
setjmp() and sigsetjmp() return 0 when called directly; on the "fake"
return that occurs after longjmp() or siglongjmp(), the nonzero value
specified in val is returned.
The longjmp() or siglongjmp() functions do not return.
- openbsd man page
The sigsetjmp(), setjmp(), and _setjmp() functions save their calling
environment in env. Each of these functions returns 0.
The corresponding longjmp() functions restore the environment saved by
the most recent invocation of the respective setjmp() function. They
then return so that program execution continues as if the corresponding
invocation of the setjmp() call had just returned the value specified by
val, instead of 0. The value specified by val must be non-zero; a 0
value is treated as 1 to allow the programmer to differentiate between a
direct invocation of setjmp() and a return via longjmp().
Pairs of calls may be intermixed; i.e., both sigsetjmp() and siglongjmp()
as well as setjmp() and longjmp() combinations may be used in the same
program. However, individual calls may not — e.g., the env argument to
setjmp() may not be passed to siglongjmp().
The longjmp() routines may not be called after the routine which called
the setjmp() routines returns.
All accessible objects have values as of the time the longjmp() routine
was called, except that the values of objects of automatic storage
invocation duration that do not have the volatile type and have been
changed between the setjmp() invocation and longjmp() call are
indeterminate.
-----------
As you can see, all the man pages reworded the descriptions to avoid
being a verbatim copy. In our case thye changes are minimal.
Regards,
--
To unsubscribe send a mail to scc-dev+unsubscribe_at_simple-cc.org
Received on Mon 21 Apr 2025 - 18:03:33 CEST