Eric Blake <e...@byu.net> writes: > Simon Josefsson <simon <at> 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 but I recall some reports about SIZE_MAX problem anyway, but it may because of config.h or size_max.m4 issues. My patch appears to be the right thing, so unless anyone finds a problem with it, I'd like to move ahead with that and sort out any problems that are reported later on. > Fix these nits, then I think it's ready to apply... I want to hear from Bruno first though. > >> >> +2009-10-06 size_max The header file "size_max.h" has been removed, >> + use <stdint.h> from the stdint.h module instead. > > s/stdint.h module/stdint module/ Fixed. >> Files: >> -m4/size_max.m4 >> lib/size_max.h > > Oops - you meant to stop distributing lib/size_max.h but keep m4/size_max.m4 > since gl_SIZE_MAX is still a valid configure macro. Heh, definitely. Fixed. >> Depends-on: > > I debated whether we need to add stdint here. But I'm guessing not, so that > the xsize module will continue to work without dragging in the stdint > replacement header. So the NEWS is sufficient to tell the majority of > clients > to use the correct module in the first place. I think so too. Also, any application that includes stdint.h and assumes it provides SIZE_MAX should pull in the stdint module directly. I don't think it is the size_max's modules job. > Then, are you also willing to prepare the followup patch to kill the > self- definition of SIZE_MAX throughout the various modules willing to > depend on the stdint module? I'll work on it when we've heard from Bruno -- I recall that this was discussed earlier, and I have paged out most of that context so there could be reasons to not do this. /Simon
