On 12/13/19 6:35 PM, Bruno Haible wrote:
> "Prefer intptr_t for internal representations of pointers"
>
> I disagree with this advice. uintptr_t ought to be used for representing the
> address of a pointer.
It depends on the application. For example, with two char * pointers P and Q
into an arr
Paul Eggert wrote:
> https://www.gnu.org/software/emacs/manual/html_node/elisp/C-Integer-Types.html
Quoting it:
"Prefer intptr_t for internal representations of pointers"
I disagree with this advice. uintptr_t ought to be used for representing the
address of a pointer.
Why? Because when signed
On Fri, 2019 Dec 13 07:58-05:00, Bruno Haible wrote:
>
> You're asking good questions. However, I would like to suggest to
> start simple and get the more complex things done afterwards. By
> that, I mean:
>
> - Put the xlc-wrap logic into the 'compile' script. We should not
> have two diff
Hi Bruno,
On Fri, 2019 Dec 13 07:43-05:00, Bruno Haible wrote:
>
> > I don't see "PTHREAD_RWLOCK_INITIALIZER_NP" anywhere in a clean Gnulib
> > tree, so I'm not sure how this could already be addressed...
>
> The gnulib module 'pthread-rwlock' fixes this issue in a platform-independent
> way (by
On Fri, 2019 Dec 13 05:32-05:00, Bruno Haible wrote:
>
> This should fix it. Thanks for the feedback.
Arrrgh, not quite there yet >_<
Tested Git 83710ffa. test-locale now builds, but test-duplocale still
does not, failing in the same place. HAVE_WORKING_DUPLOCALE appears to
be 1 (true).
Isn't
I see that Paul has made the change to the API over my objections.
I made the change while responding to Bruno's objections, but before
seeing yours. Ooops. Sorry about that. However, I hope the followup
emails have addressed your comments, at least to some extent.
Paul, can you point to a
On Fri, Dec 13, 2019 at 4:08 AM wrote:
> arn...@skeeve.com write:
>
> > But I really don't want ptrdiff_t in the API.
>
> I see that Paul has made the change to the API over my objections.
>
> Jim --- do you have an opinion on this?
Hi Aharon,
I used to feel the way you do. However, given the wa
Hi Daniel,
> > Do you have a set of configure settings that you would recommend on z/OS?
> > So that we can add this info to the Gnow-How wiki [1]...
>
> There are quite a few, unfortunately. Before getting into them, however,
> there is something I am not clear on:
>
> How should platform-speci
Hi Daniel,
> > Tell the package maintainers to import the gnulib module 'pthread-
> > rwlock'. It will deal with the missing PTHREAD_RWLOCK_INITIALIZER;
> > this issue occurs also on some older Solaris versions.
>
> If I omit that fragment, I get this build error:
>
> source='/tmp/testdir/gl
arn...@skeeve.com wrote:
> But I really don't want ptrdiff_t in the API.
I see that Paul has made the change to the API over my objections.
Jim --- do you have an opinion on this?
Thanks,
Arnold
[Re-adding bug-gnulib to the CC. Please keep the conversation in public.]
Gisle Vanem wrote:
> > But the autoconfiguration no longer sets REPLACE_STRUCT_LCONV=1 on MSVC.
>
> But for MinGW it does? Well, my MinGW-TDM does not have
> 'int_p_cs_precedes' either. So why is MSVC treated so special?
T
Daniel Richard G. wrote:
> I can now get past the library build, but then get errors compiling
> test-duplocale.c and test-locale.c. The former fails at line 26:
>
> SIGNATURE_CHECK (duplocale, locale_t, (locale_t));
>
> The latter fails at line 49:
>
> locale_t b = LC_GLOBAL_LOCALE;
>
Hi,
Gisle Vanem wrote:
> In https://lists.gnu.org/archive/html/bug-gnulib/2019-12/msg00050.html
> Bruno Haible did this:
> ...
>
> But with a 'REPLACE_STRUCT_LCONV=1', I get an error for
> locale.h since there are now double up for all of these:
>locale.h(162): error C2020: 'p_cs_precedes': '
Hi Paul.
Paul Eggert wrote:
> On 12/11/19 11:31 PM, arn...@skeeve.com wrote:
>
> > 1,$s/ptrdiff_t/ssize_t/g
>
> ssize_t can be narrower than ptrdiff_t, so it's not a good type to use
> for this notion. Its original motivation was "the type that 'read'
> returns", and on systems where 'read
14 matches
Mail list logo
