Em dom., 14 de fev. de 2021 às 22:28, Michael Paquier
escreveu:
> On Sun, Feb 14, 2021 at 11:39:47AM -0300, Ranier Vilela wrote:
> > What do you think?
>
> That's not a good idea for two reasons:
> 1) There is CRC32 to worry about, which relies on a different logic.
> 2) It would become easier to
On Sun, Feb 14, 2021 at 11:39:47AM -0300, Ranier Vilela wrote:
> What do you think?
That's not a good idea for two reasons:
1) There is CRC32 to worry about, which relies on a different logic.
2) It would become easier to miss the new option as compilation would
not warn anymore if a new checksum
Em dom., 14 de fev. de 2021 às 08:22, Michael Paquier
escreveu:
> On Sat, Feb 13, 2021 at 09:33:48PM -0300, Ranier Vilela wrote:
> > Em sáb., 13 de fev. de 2021 às 20:32, Michael Paquier <
> mich...@paquier.xyz>
> > escreveu:
> >
> >> You are missing the point here. What you are proposing here w
On Sat, Feb 13, 2021 at 09:33:48PM -0300, Ranier Vilela wrote:
> Em sáb., 13 de fev. de 2021 às 20:32, Michael Paquier
> escreveu:
>
>> You are missing the point here. What you are proposing here would not
>> be backpatched. However, reusing the same words as upthread, this has
>> a cost in ter
Em sáb., 13 de fev. de 2021 às 20:32, Michael Paquier
escreveu:
> On Sat, Feb 13, 2021 at 05:37:32PM -0300, Ranier Vilela wrote:
> > IMO there is no necessity in back-patching.
>
> You are missing the point here. What you are proposing here would not
> be backpatched. However, reusing the same
On Sat, Feb 13, 2021 at 05:37:32PM -0300, Ranier Vilela wrote:
> IMO there is no necessity in back-patching.
You are missing the point here. What you are proposing here would not
be backpatched. However, reusing the same words as upthread, this has
a cost in terms of *future* maintenance. In sh
Em sex., 12 de fev. de 2021 às 22:47, Michael Paquier
escreveu:
> On Fri, Feb 12, 2021 at 03:21:40PM +0900, Kyotaro Horiguchi wrote:
> > The v3 drops the changes of the uuid_ossp contrib. I'm not sure the
> > change of scram_HMAC_final is needed.
>
> Meaning that v3 would fail to compile uuid-os
On Fri, Feb 12, 2021 at 03:21:40PM +0900, Kyotaro Horiguchi wrote:
> The v3 drops the changes of the uuid_ossp contrib. I'm not sure the
> change of scram_HMAC_final is needed.
Meaning that v3 would fail to compile uuid-ossp. v3 also produces
compilation warnings in auth-scram.c.
> In v2, int_m
At Thu, 11 Feb 2021 19:55:45 -0300, Ranier Vilela wrote
in
> Em qui., 11 de fev. de 2021 às 09:47, Michael Paquier
> escreveu:
>
> > On Wed, Feb 10, 2021 at 09:14:46AM -0300, Ranier Vilela wrote:
> > > It is necessary to correct the interfaces. To caller, inform the size of
> > > the buffer it
Em qui., 11 de fev. de 2021 às 09:47, Michael Paquier
escreveu:
> On Wed, Feb 10, 2021 at 09:14:46AM -0300, Ranier Vilela wrote:
> > It is necessary to correct the interfaces. To caller, inform the size of
> > the buffer it created.
>
> Now, the patch you sent has no need to be that complicated,
Em qui., 11 de fev. de 2021 às 09:47, Michael Paquier
escreveu:
> On Wed, Feb 10, 2021 at 09:14:46AM -0300, Ranier Vilela wrote:
> > It is necessary to correct the interfaces. To caller, inform the size of
> > the buffer it created.
>
> Well, Coverity likes nannyism, so each one of its reports is
On Wed, Feb 10, 2021 at 09:14:46AM -0300, Ranier Vilela wrote:
> It is necessary to correct the interfaces. To caller, inform the size of
> the buffer it created.
Well, Coverity likes nannyism, so each one of its reports is to take
with a pinch of salt, so there is no point to change something tha
Em qua., 10 de fev. de 2021 às 01:44, Kyotaro Horiguchi <
horikyota@gmail.com> escreveu:
> At Tue, 9 Feb 2021 22:01:45 -0300, Ranier Vilela
> wrote in
> > Hi Hackers,
> >
> > Per Coverity.
> >
> > Coverity complaints about pg_cryptohash_final function.
> > And I agree with Coverity, it's a ba
On Wed, Feb 10, 2021 at 01:44:12PM +0900, Kyotaro Horiguchi wrote:
> It seems to me that the above just means the caller must provide a
> digest buffer that fits the use. In the above example digest just must
> be 64 byte. If Coverity complains so, what should do for the
> complaint is to fix the
At Tue, 9 Feb 2021 22:01:45 -0300, Ranier Vilela wrote in
> Hi Hackers,
>
> Per Coverity.
>
> Coverity complaints about pg_cryptohash_final function.
> And I agree with Coverity, it's a bad design.
> Its allows this:
>
> #define MY_RESULT_LENGTH 32
>
> function pgtest(char * buffer, char * te
At Wed, 10 Feb 2021 12:13:44 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Tue, 9 Feb 2021 22:01:45 -0300, Ranier Vilela wrote
> in
> > Hi Hackers,
> >
> > Per Coverity.
> >
> > Coverity complaints about pg_cryptohash_final function.
> > And I agree with Coverity, it's a bad design.
> > Its
At Tue, 9 Feb 2021 22:01:45 -0300, Ranier Vilela wrote in
> Hi Hackers,
>
> Per Coverity.
>
> Coverity complaints about pg_cryptohash_final function.
> And I agree with Coverity, it's a bad design.
> Its allows this:
>
> #define MY_RESULT_LENGTH 32
>
> function pgtest(char * buffer, char * te
Hi Hackers,
Per Coverity.
Coverity complaints about pg_cryptohash_final function.
And I agree with Coverity, it's a bad design.
Its allows this:
#define MY_RESULT_LENGTH 32
function pgtest(char * buffer, char * text) {
pg_cryptohash_ctx *ctx;
uint8 digest[MY_RESULT_LENGTH];
ctx = pg_cryptohash
18 matches
Mail list logo
