[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: supporting strings > 2 GB
From: |
Bruno Haible |
Subject: |
Re: supporting strings > 2 GB |
Date: |
Sun, 13 Oct 2019 21:50:19 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-165-generic; KDE/5.18.0; x86_64; ; ) |
Hi Paul,
Probably I didn't explain it well. Let me try again.
> Gnulib may need something like printf_len_t, PRIdPRINTF etc., but I don't
> quite
> see why POSIX and/or the C standard would need them.
The code will consist of two layers:
1) A layer that defines functions.
Example:
ptrdiff_t lprintf (const char *format, ...)
_GL_ATTRIBUTE_FORMAT_PRINTF (1, 2);
2) A layer that may redefine functions and types through aliases.
Example:
#if _PRINTF_LARGE
#undef printf
#define printf lprintf
#define printf_len_t ptrdiff_t
#else
#define printf_len_t int
#endif
This is similar to how the large file support was implemented
in two layers:
1) A function
off64_t lseek64(int fd, off64_t offset, int whence);
2) A layer that redefines functions and types:
#if _FILE_OFFSET_BITS == 64
#define lseek lseek64
#define off_t off64_t
#endif
The C or POSIX standards deal only with layer 1). However, layer 2) is
essential for programs, to make the use of the new APIs easy.
Bruno