public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug manual/5461] New: LONG_LONG_MAX vs LLONG_MAX in range-of-type section of manual
@ 2007-12-09 7:26 virdiq at gmail dot com
2009-10-22 18:39 ` [Bug manual/5461] " eerott at gmail dot com
0 siblings, 1 reply; 2+ messages in thread
From: virdiq at gmail dot com @ 2007-12-09 7:26 UTC (permalink / raw)
To: glibc-bugs
It appears that the current online manual refers to LONG_LONG_MAX and
ULONG_LONG_MAX at:
http://www.gnu.org/software/libc/manual/html_node/Range-of-Type.html#Range-of-Type
Instead of LLONG_MAX and ULLONG_MAX as defined in limits.h (checked against
2.6.1 and 2.7).
LONG_LONG_MAX/ULONG_LONG_MAX aren't defined in limits.h as the manual seems to
indicate.
--
Summary: LONG_LONG_MAX vs LLONG_MAX in range-of-type section of
manual
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: manual
AssignedTo: roland at gnu dot org
ReportedBy: virdiq at gmail dot com
CC: glibc-bugs at sources dot redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=5461
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug manual/5461] LONG_LONG_MAX vs LLONG_MAX in range-of-type section of manual
2007-12-09 7:26 [Bug manual/5461] New: LONG_LONG_MAX vs LLONG_MAX in range-of-type section of manual virdiq at gmail dot com
@ 2009-10-22 18:39 ` eerott at gmail dot com
0 siblings, 0 replies; 2+ messages in thread
From: eerott at gmail dot com @ 2009-10-22 18:39 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From eerott at gmail dot com 2009-10-22 18:39 -------
LONG_LONG_* defines are from the time before C99 standardized to LLONG_*
defines. I.e. the current manual seems about 10 years obsolete, I think it's
time to refresh it...
These obsolete defines are used also elsewhere in the manual, for example here:
http://www.gnu.org/s/libc/manual/html_node/Parsing-of-Integers.html
Should be trivial to fix with 's/LONG_LONG_/LLONG_/g' on the whole manual.
I think this should be pretty safe to do as when I grepped the glibc header
files for LONG_LONG_, I got only this:
/usr/include/endian.h:# define __LONG_LONG_PAIR(HI, LO) LO, HI
/usr/include/endian.h:# define __LONG_LONG_PAIR(HI, LO) HI, LO
/usr/include/limits.h:# define LLONG_MAX __LONG_LONG_MAX__
so I don't think there to be any valid instances of LONG_LONG_ in the manual,
except maybe in the history section, if it has such...
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |eerott at gmail dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=5461
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-10-22 18:39 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-12-09 7:26 [Bug manual/5461] New: LONG_LONG_MAX vs LLONG_MAX in range-of-type section of manual virdiq at gmail dot com
2009-10-22 18:39 ` [Bug manual/5461] " eerott at gmail dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).