http://sources.redhat.com/bugzilla/show_bug.cgi?id=5200
just ask.
Since Ulrich does not deign to give any rationale, perhaps anyone who
wishes to pursue it could write the steering committee at
[EMAIL PROTECTED] (Although Paul is on the steering committee!)
karl
Paul Eggert wrote:
This casting business is a relatively minor point; I'm more worried
about the old-style function definitions. I wish I knew why glibc
does it that way.
http://sources.redhat.com/bugzilla/show_bug.cgi?id=5200
just ask.
Sam Steingold <[EMAIL PROTECTED]> writes:
> this is the standard way to handle calloc/malloc/alloca.
It's one standard way, but there are others. In C, generally it's
better to avoid the casts, since casts can suppress useful
diagnostics. So, in C, it's usually better to not cast the results of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Blake wrote:
>
> You do realize that your patch is a fork from glibc.
I do now.
> Why not push upstream on the glibc people, then?
http://sources.redhat.com/bugzilla/show_bug.cgi?id=5200
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Sam Steingold on 10/19/2007 7:53 AM:
>> The diffs may require updates every few months, when the copy in gnulib
>> changes. (gnulib-tool gives an error when a .diff is stored in gnulib-local
>> but it does not apply cleanly any more.)
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruno Haible wrote:
> Sam Steingold wrote:
>> why not just apply the patch?
>
> You can also have your patch automatically applied by gnulib-tool.
> To achieve this:
> - create a directory, say, gnulib-local,
> - store your regcomp.diff in gnulib-
Sam Steingold wrote:
> why not just apply the patch?
You can also have your patch automatically applied by gnulib-tool.
To achieve this:
- create a directory, say, gnulib-local,
- store your regcomp.diff in gnulib-local/lib/regcomp.c.diff
andregexec.diff in gnulib-local/lib/regexec
Paul Eggert wrote:
That problem arises because for some reason glibc prefers old-style
function definitions when defining external functions meant to be
called from C code. Does anyone know why that is? I assume it's some
API thing.
Sounds highly improbable.
I thought that the function defini
That problem arises because for some reason glibc prefers old-style
function definitions when defining external functions meant to be
called from C code. Does anyone know why that is? I assume it's some
API thing.
As for changes like this:
- dfa->state_table = calloc (sizeof (struct re_state_t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
patches attached
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHF9JnPp1Qsf2qnMcRAsTDAKCq8T4zZjQa4GK1ryygPrq3BLm1QACcCh8q
3amH5P4qSQ9+fMW/aL4BsN8=
=JO3v
-END PG
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
looks like regex still does not support g++:
g++ -DHAVE_CONFIG_H -I. -I../../src/gllib -I.. -MT regex.lo -MD -MP -MF
.deps/regex.Tpo -c ../../src/gllib/regex.c -fPIC -DPIC -o .libs/regex.o
../../src/gllib/regcomp.c:260: error: 'reg_syntax_t re_set_s
11 matches
Mail list logo