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).