Re: size_max

Bruno Haible writes: > I now have no objection against removing just size_max.h, if it's > reasonably documented how to use the m4/size_max.m4 macros. That > essentially means to copy its contents to the 'Include' section of the > module description. Proposed changed patch (plus the NEWS paragrap

Re: SIZE_MAX

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 documentation

Re: size_max

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 use. The unused file li

Re: size_max

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: . > Also, any application

Re: size_max

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 in use by other files in gnulib, > without explaini

Re: size_max

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 why it is important for vas

Re: SIZE_MAX

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 SIZE_MAX ((size_t) -1) > > quotearg.c:# defi

Re: size_max

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. > > stdint.in.h already takes care of SIZE_MAX. Yes

Re: size_max

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. > +2009-10-06 Simon Josefsson j

Re: SIZE_MAX

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, right. The size_max.h file is

Re: SIZE_MAX

Hi Simon, > > 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. > > Btw, why not? It seems it could create it under, say, intl/gl/ It could, certainly. But packages that include

Re: SIZE_MAX

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 > of stdint.h. Btw, why

Re: SIZE_MAX

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 > of stdint.h. But the in

Re: SIZE_MAX

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" redefined >> In file included from ./../gl/stdlib.h:52, >>

Re: SIZE_MAX

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. Taken out of context, yes, it looks wrong. Which is why Bruno als

Re: SIZE_MAX

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." --D. E. Knuth, "Structured Programming wi

Re: SIZE_MAX

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 contains vasnprintf

Re: size_max: remove it?

"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 > and so the current code fro

Re: size_max: remove it?

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 would be modified to depend > on size_max,

Re: size_max: remove it?

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 cater to people who need SIZ

Re: size_max: remove it?

Simon Josefsson wrote: > Sorry, I didn't read size_max.m4 which seem to be doing some > interesting things. This means it's time to put some comments. I also had a hard time remembering why and were used and no others. How about this? > Still, is there a reason the size_max.m4 magic shouldn't b

Re: size_max: remove it?

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 systems. > that doesn't seem compatible wi

Re: size_max: remove it?

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

Re: size_max: remove it?

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 define HAVE_STDINT_H). So if there is > no stdint.h, an

Re: size_max module: missing Makefile.am entry

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 > > The resulting tarball does not contain size_max.h.

Re: size_max

Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> 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. >> >> > 2004-12-28 Simon Josefss

Re: size_max

Simon Josefsson wrote: > 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. > > > 2004-12-28 Simon Josefsson <[EMAIL PROTECTED]> > > > > * modules/siz

Re: [bug-gnulib] Re: size_max

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

Re: size_max

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. >> Should we start replacing >> >> /* Get SIZE_MAX. */ >> #in

Re: size_max

Simon Josefsson <[EMAIL PROTECTED]> writes: > What is the criteria for being listed as maintainer of a gnulib > module? Wrote the code? Interested in supporting the code? > Modularized the code? Wrote the module file? Gnulib developer? Yes to all the above. :-) The criteria aren't formal, b

Re: size_max

Paul Eggert <[EMAIL PROTECTED]> writes: > 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 seem

Re: 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

Re: size_max

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. Simon Josefsson <[EMAIL PROTECTED]> writes: > 2004-12-28 Simon Josefsson <[EMAIL PROTECTED]> > > *