In Emacs, I saw the following warning:
In file included from /usr/lib/gcc/x86_64-redhat-linux/14/include/stdint.h:9,
from file-has-acl.c:53:
/usr/include/stdint.h:216:11: warning: "SIZE_MAX" redefined
216 | # define SIZE_MAX (184467440737
* lib/xsize.h (xsum): Port to oddball platforms where SIZE_MAX <=
INT_MAX. Although no such platform is a current Gnulib porting
problems, it’s easy enough to port to them.
---
ChangeLog | 5 +
lib/xsize.h | 18 ++
2 files changed, 19 insertions(+), 4 deletions(-)
d
* lib/xalloc-oversized.h (xalloc_count_t): Remove; no longer
needed and was evidently error-prone anyway.
(xalloc_oversized): Omit some over-optimization that caused
SIZE_MAX to not be treated as too large (the Gnulib convention) on
unusual platforms where PTRDIFF_MAX == SIZE_MAX. This change
> +2020-02-02 Pádraig Brady
> +
> + read-file: reduce max size from SIZE_MAX to PTRDIFF_MAX
Looks good as well.
Bruno
-file.c: s/SIZE_MAX/PTRDIFF_MAX/
---
ChangeLog | 11 +++
lib/read-file.c | 10 +-
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 1e5f94d3c..86f8626d6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2020-02-02 Pád
* tests/test-stddef.c: Include , for INT_MAX.
Do not assume that INT_MAX < SIZE_MAX.
---
ChangeLog | 6 ++
tests/test-stddef.c | 6 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLog
index eec777f..3052549 100644
--- a/ChangeLog
++
* lib/glob.c (glob): Prefer SIZE_MAX to ~((size_t) 0), as the
latter is not portable to (probably theoretical) hosts where
SIZE_MAX <= INT_MAX.
---
ChangeLog | 7 +++
lib/glob.c | 6 +++---
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index a8ba
re we should start
the ball rolling on getting papers.
diff --git a/ChangeLog b/ChangeLog
index 4e1984c..2f847e6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2014-03-04 Kevin Cernekee
+
+ stdint, read-file: fix missing SIZE_MAX on Android (tiny change)
+ This is basically one o
On Wed, Mar 5, 2014 at 2:42 PM, Paul Eggert wrote:
> Thanks for the bug report and patch. A couple of things. First, the
> commentary is big enough so that we'd need a copyright assignment for this
> -- if you and your employer are OK with that please let me know and I'll
> start the ball rollin
Thanks for the bug report and patch. A couple of things. First, the
commentary is big enough so that we'd need a copyright assignment for
this -- if you and your employer are OK with that please let me know and
I'll start the ball rolling on the paperwork. If this is an issue we
can rederive
e.o read-file.c
> read-file.c: In function 'fread_file':
> read-file.c:62:17: error: 'SIZE_MAX' undeclared (first use in this
> function)
> read-file.c:62:17: note: each undeclared identifier is reported only once
> for each function it appears in
&g
le.c:62:17: error: 'SIZE_MAX' undeclared (first use in this function)
read-file.c:62:17: note: each undeclared identifier is reported only once
for each function it appears in
make[4]: *** [read-file.o] Error 1
Bionic puts SIZE_MAX in , but gnulib tries to make it available
from ou
On 01/15/2013 08:16 AM, Andoni Morales wrote:
> Hi,
>
> Attached patch to fix the build with the Android NDK for x86. This was
> triggered building libtasn1 with the following error:
>
> read-file.c: In function 'fread_file':
> read-file.c:62:17: error: 'SIZ
-o
.libs/read-file.o
read-file.c: In function 'fread_file':
read-file.c:62:17: error: 'SIZE_MAX' undeclared (first use in this function)
read-file.c:62:17: note: each undeclared identifier is reported only
once for each function it appears in
Cheers,
Andoni
0001-read-
* lib/regex_internal.h (SIZE_MAX): Remove; stdint.h supplies this now.
---
ChangeLog|5 +
lib/regex_internal.h |5 -
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 9171da1..932a396 100644
--- a/ChangeLog
+++ b/ChangeLog
>
> * lib/size_max.h: Remove file.
> * modules/size_max (Files): Remove lib/size_max.h.
> (Makefile.am): Don't add size_max.h to lib_SOURCES.
> (Include): Remove size_max.h. Add its essential contents instead.
> * lib/xsize.h: Add comments, original
Bruno Haible writes:
> I explained why the size_max module is needed. But I have no problems with
> discouraging its use:
I think that will help -- I believe I pulled in the size_max module into
one of my projects by mistake, where I should have used stdint instead.
I think better documen
Eric Blake wrote:
> > Hello? You propose to remove a file that is in use by other files in gnulib,
> > without explaining what to do with the other files. ?!
>
> No. Reread the proposal. The size_max module stays, and the used file
> m4/size_max.m4 remains available for
Simon Josefsson wrote:
> I recall some reports about SIZE_MAX problem anyway, but it may
> because of config.h or size_max.m4 issues.
You reported a problem in this area, and it was fixed immediately:
<http://lists.gnu.org/archive/html/bug-gnulib/2009-05/msg00224.html>.
> Also,
Bruno Haible clisp.org> writes:
> > +2009-10-06 Simon Josefsson josefsson.org>
> > +
> > + * lib/size_max.h: Remove file.
> > + * modules/size_max: Drop size_max.h.
> > + * NEWS: Explain.
>
> Hello? You propose to remove a file that is
Jim Meyering wrote:
> AFAICS, gettext and xsize are the only gnulib modules that use it,
> so deprecating size_max sounds like a good idea, assuming
> Bruno doesn't mind adjusting those two modules.
In <http://lists.gnu.org/archive/html/bug-gnulib/2009-05/msg00224.html>
why
Simon Josefsson wrote:
> > I suppose these should include stdint.h also?
> >
> > areadlink.c:# define SIZE_MAX ((size_t) -1)
> > areadlink-with-size.c:# define SIZE_MAX ((size_t) -1)
> > backupfile.c:# define SIZE_MAX ((size_t) -1)
> > fnmatch.c:# define S
Eric Blake writes:
> Simon Josefsson josefsson.org> writes:
>
>> So how about this patch?
>>
>> Of course, stdint.h has to define SIZE_MAX on these systems to make sure
>> it will still work. But I suppose we'll notice if it doesn't already.
>
Simon Josefsson josefsson.org> writes:
> So how about this patch?
>
> Of course, stdint.h has to define SIZE_MAX on these systems to make sure
> it will still work. But I suppose we'll notice if it doesn't already.
stdint.in.h already takes care of SIZE_MAX.
>
Jim Meyering writes:
>> However given that SIZE_MAX should be in stdint.h according to POSIX,
>> maybe it makes more sense to make sure gnulib's stdint.h replacement is
>> enabled when SIZE_MAX is not provided by the system's stdint.h? And
>> then depre
Bruno Haible writes:
>> How about clarifying the intentions behind the size_max module a bit
>> better? It seems most applications will want to include stdint.h and
>> depend on the stdint gnulib module, rather than using the gnulib
>> size_max module.
>
> Exactly,
of intl/.
> > vasnprintf.c, which
> > depends on xsize.h, which needs a definition of SIZE_MAX. For this reason,
> > xsize.h arranges to get a correct SIZE_MAX in the cheapest possible way.
>
> Ok, that makes sense. I note that xsize.h does not include size_max.h.
> Should i
Bruno Haible writes:
> Simon Josefsson wrote:
>> Bruno, what do you think about simply deprecating the size_max module?
>
> This would cause problems in libintl. The intl/ directory, when shipped
> as part of a package that used gettextize, should not create its own copy
> o
Bruno Haible writes:
> Simon Josefsson wrote:
>> Bruno, what do you think about simply deprecating the size_max module?
>
> This would cause problems in libintl. The intl/ directory, when shipped
> as part of a package that used gettextize, should not create its own copy
>
Bruno Haible writes:
>> I got a report about SIZE_MAX problems:
>>
>> In file included from ../gnutls_int.h:29,
>> from opencdk.h:30,
>> from kbnode.c:31:
>> ../config.h:357:1: warning: "SIZE_MAX" redefine
Bruno Haible writes:
> Simon Josefsson wrote:
>> The getdelim module already implicitly depends on stdint
>
> I don't think it did. 'realloc-posix' depends on stdlib, not stdint.
> So what you added is a new dependency.
The stdlib module depends on stdint.
> Some people, like Sam Steingold, wan
Ben Pfaff cs.stanford.edu> writes:
> > +[/* Define as the maximum value of type 'size_t', if the system doesn't
define
> > + it. */
> > +#ifndef SIZE_MAX
> > +# undef SIZE_MAX
> > +#endif])
> > ])
>
> This logic looks wrong.
Ta
Bruno Haible writes:
> +[/* Define as the maximum value of type 'size_t', if the system doesn't
> define
> + it. */
> +#ifndef SIZE_MAX
> +# undef SIZE_MAX
> +#endif])
> ])
This logic looks wrong.
--
"Premature optimization is the root of all evil
Simon Josefsson wrote:
> Bruno, what do you think about simply deprecating the size_max module?
This would cause problems in libintl. The intl/ directory, when shipped
as part of a package that used gettextize, should not create its own copy
of stdint.h. But the intl/ directory conta
Simon Josefsson wrote:
> The getdelim module already implicitly depends on stdint
I don't think it did. 'realloc-posix' depends on stdlib, not stdint.
So what you added is a new dependency.
Some people, like Sam Steingold, want to minimize dependencies in gnulib.
Especially towards module 'stdint
TCH] getdelim: Use SIZE_MAX from stdint.h.
---
ChangeLog|6 ++
lib/getdelim.c |8 +++-
modules/getdelim |1 +
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index a153fa9..2c13295 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1
I got a report about SIZE_MAX problems:
In file included from ../gnutls_int.h:29,
from opencdk.h:30,
from kbnode.c:31:
../config.h:357:1: warning: "SIZE_MAX" redefined
In file included from ./../gl/stdlib.h:52,
from kbnode.c:28:
./../g
her modules, we can switch to immediately.
2006-09-28 Bruno Haible <[EMAIL PROTECTED]>
* modules/avltreehash-list (Depends-on): Add stdint, remove size_max.
* modules/linkedhash-list (Depends-on): Likewise.
* modules/rbtreehash-list (Depends-on): Likewi
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> 21 checking for SIZE_MAX... yes
>
> as the top gnulib candidates. The SIZE_MAX test is cheap on systems
> that have it
There's no reason to have a separate SIZE_MAX module any more, except
for inertia, as the stdint mo
of (size_t) <= sizeof (unsigned int)], fits_in_uint,
! [#include ], result=?)
! if test "$fits_in_uint" = 1; then
! dnl Even though SIZE_MAX fits in an unsigned int, it must be of type
! dnl 'unsigned long' if the type 'size_t' is the same as 'unsign
Paul Eggert wrote:
> The basic idea seems fine, but isn't that off by a factor of 2? It defines
> size_t_bits_minus_2 = sizeof (size_t) * CHAR_BIT - 2
> and then defines SIZE_MAX to (((1U << $size_t_bits_minus_2) - 1) * 2 + 1).
> Unless I'm missing something, on
The basic idea seems fine, but isn't that off by a factor of 2? It defines
size_t_bits_minus_2 = sizeof (size_t) * CHAR_BIT - 2
and then defines SIZE_MAX to (((1U << $size_t_bits_minus_2) - 1) * 2 + 1).
Unless I'm missing something, on a 32-bit host, that will set SIZE_MAX
to 21
Hi,
The size_max macro has a bug: it assumes that 'expr' can deal with numbers as
large as SIZE_MAX/10. Which is not true when cross-compiling from a 32-bit
platform to a 64-bit platform.
Here is a fix, that takes care that SIZE_MAX is valid in preprocessor
expressions (i.e. contain
"Derek R. Price" <[EMAIL PROTECTED]> writes:
> It sounds reasonable to leave size_max in for those who want it, but is
> it really necessary to make stdint depend on it? All that extra work by
> configure sounds like overkill too, when stdint_.h has already included
&
Paul Eggert wrote:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>> 2) I use the size_max module inside gettext's libintl, and a full-blown
>> feels like overkill in this case, when we just need one macro.
>
> I'd been assuming that the stdint module w
Bruno Haible <[EMAIL PROTECTED]> writes:
> 2) I use the size_max module inside gettext's libintl, and a full-blown
> feels like overkill in this case, when we just need one macro.
I'd been assuming that the stdint module would be modified to depend
on size_max, to ca
.m4 magic shouldn't be merged
> into the stdint module?
1) Is the 'stdint' module tested as much (on as many platforms) as other
gnulib modules? gettext doesn't use it so far. coreutils uses it for
3 months only. clisp uses it but is not tested on so many platforms.
2)
Simon Josefsson wrote:
> There is size_max, which does:
>
> # include
This is needed to avoid a "macro redefined" warning e.g. on Solaris 7.
> # if HAVE_STDINT_H
> # include
> # endif
This is needed to avoid a "macro redefined" warning e.g. on glibc sy
Simon Josefsson <[EMAIL PROTECTED]> writes:
> Still, is there a reason the size_max.m4 magic shouldn't be merged
> into the stdint module?
Yes, that'd be a logical way to do it. (This was part of my stdint
review that I haven't done yet. :-)
Simon Josefsson <[EMAIL PROTECTED]> writes:
> There is size_max, which does:
>
> # include
> # if HAVE_STDINT_H
> # include
> # endif
>
> that doesn't seem compatible with the stdint.h module (I'm assuming
> that the stdint module doesn't defi
There is size_max, which does:
# include
# if HAVE_STDINT_H
# include
# endif
that doesn't seem compatible with the stdint.h module (I'm assuming
that the stdint module doesn't define HAVE_STDINT_H). So if there is
no stdint.h, and limits.h doesn't define SIZE_MAX, this
Derek Price <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>
>>Derek Price <[EMAIL PROTECTED]> writes:
>>
>>
>>>may not be defined. I've installed the attached patch, ripped verbatim
>>>from serveral other modules.
&g
Derek Price <[EMAIL PROTECTED]> writes:
> I think the size_max module is only important if you want to use
> SIZE_MAX as part of a preprocessor conditional
Yes, that's my recollection as well.
___
bug-gnulib mailing list
bug-gn
Simon Josefsson wrote:
>Derek Price <[EMAIL PROTECTED]> writes:
>
>
>>may not be defined. I've installed the attached patch, ripped verbatim
>>from serveral other modules.
>>
>>
>
>Shouldn't we use the size_max module instead?
>
&
AX): New macro, if not already defined.
> (getdelim): Fix buffer overrun on 64-bit hosts with lines longer
> than 2 GiB.
>
> The problem is that the new SSIZE_MAX macro depends on SIZE_MAX, which
> may not be defined. I've installed the attached patch, ripped ver
4-bit hosts with lines longer
than 2 GiB.
The problem is that the new SSIZE_MAX macro depends on SIZE_MAX, which
may not be defined. I've installed the attached patch, ripped verbatim
from serveral other modules.
2005-10-05 Derek Price <[EMAIL PROTECTED]>
* getdelim.c (SI
Martin Lambers <[EMAIL PROTECTED]> writes:
> Hi!
>
> I think the size_max module misses the Makefile.am entry
> "lib_SOURCES += size_max.h":
>
> $ ./gnulib-tool --create-testdir --dir=/tmp/t size_max
> $ cd /tmp/t
> $ ./configure
> $ make dist
>
>
Hi!
I think the size_max module misses the Makefile.am entry
"lib_SOURCES += size_max.h":
$ ./gnulib-tool --create-testdir --dir=/tmp/t size_max
$ cd /tmp/t
$ ./configure
$ make dist
The resulting tarball does not contain size_max.h.
The following patch fixes this:
--- modules/siz
lains.
>>
>> > 2004-12-28 Simon Josefsson <[EMAIL PROTECTED]>
>> >
>> > * modules/size_max: New file.
>> >
>> >* modules/xsize: Depend on size_max module for size_max.m4.
>> >
>> > 2005-01-21 Simon Josefsson &l
ED]>
> >
> > * modules/size_max: New file.
> >
> > * modules/xsize: Depend on size_max module for size_max.m4.
> >
> > 2005-01-21 Simon Josefsson <[EMAIL PROTECTED]>
> >
> > * size_max.h: New file.
Fine with me. Please install
Paul Eggert wrote:
> Also, while we're on the subject of size_max.m4, I have a pedantic
> point: its use of ~(size_t)0 isn't portable in general. For example,
> if size_t is narrower than int, then ~(size_t)0 might evaluate to -1,
> which isn't correct.
Ah, right. I'm changing it to (size_t)~(siz
Paul Eggert <[EMAIL PROTECTED]> writes:
>> In this case, I think naming me and Bruno as maintainer would be the
>> right thing. Ok?
>
> It's fine with me, though I'd like to hear Bruno's opinion.
Yup, I'll wait for Bruno's response.
&
a aren't formal, but basically it's the person who makes
sure that the code is fixed and/or improved when needed.
> In this case, I think naming me and Bruno as maintainer would be the
> right thing. Ok?
It's fine with me, though I'd like to hear Bruno's opinion.
&
Bruno as maintainer would be the
right thing. Ok?
+Maintainer:
+Simon Josefsson
+Bruno Haible
Another complication:
Should we start replacing
/* Get SIZE_MAX. */
#include
#if HAVE_STDINT_H
# include
#endif
and/or
#ifndef SIZE_MAX
# define SIZE_MAX ((size_t) -1)
#endif
with
/* Get SIZE_MAX
Simon Josefsson <[EMAIL PROTECTED]> writes:
> How about this? The patch was discussed and revised a few times some
> months ago. Nobody complained after the last patch was posted. I'll
> install this on Sunday, unless someone complains.
It seems a bit odd for you to list Bruno as the maintaine
;[EMAIL PROTECTED]>
>
> * modules/size_max: New file.
>
> * modules/xsize: Depend on size_max module for size_max.m4.
>
> 2005-01-21 Simon Josefsson <[EMAIL PROTECTED]>
>
> * size_max.h: New file.
Index: lib/size_max.h
===
66 matches
Mail list logo
