Devin Reade writes:
> I'm going to have to take a step back for a moment: Currently the only
> thing that I have that is using libdbi is one legacy application. I'm
> not saying that I won't use it in future projects, just that I have no
> active projects at the moment depending on it. There
Markus Hoenicka wrote:
> I've had a look at libdbi-driver's current ato*() usage. As far as I
> can see it is used only to turn raw row data into integers by
> functions which do not return values, i.e. without an easy way to
> indicate conversion errors. I haven't checked all drivers yet, but I
Devin Reade writes:
> In the particular case of this use in libdbi, I've not looked at the
> code to see to what extent it is an *actual* problem; however as a
> generalization, I would advise against using ato*() functions and instead
> use strto*() functions because the latter provides input
Devin Reade writes:
> They should at least be as portable as the ato* functions, unless
> perhaps someone is still using a K&R C compiler somewhere, which
> I doubt. If there's any portability issue, I would expect it to
> rear its head more for the 'long long' versions of both rather than
>
Markus Hoenicka wrote:
> What about the portability of the strto* functions?
They should at least be as portable as the ato* functions, unless
perhaps someone is still using a K&R C compiler somewhere, which
I doubt. If there's any portability issue, I would expect it to
rear its head more for
Devin Reade writes:
> The ato* are indeed often implemented in terms of strto*. The problem
> is that the ato* signature just doesn't lend itself to error
> checks, so even if they wrap strto*, error information gets lost in
> the wrapper layer.
What about the portability of the strto* functi
Markus Hoenicka wrote:
> I guess I have incorrectly generalized
> from FreeBSD that ato*() are wrappers around the corresponding
> strto*() functions. If they are indeed separately implemented in other
> OSes, [snip]
The ato* are indeed often implemented in terms of strto*. The problem
is
Devin Reade was heard to say:
> Markus Hoenicka wrote:
>
>> To better deal with your shock: Could you please elaborate what's
>> wrong with atoll()?
>
> In the particular case of this use in libdbi, I've not looked at the
> code to see to what extent it is an *actual* problem; however as a
> gen
Markus Hoenicka wrote:
> To better deal with your shock: Could you please elaborate what's
> wrong with atoll()?
In the particular case of this use in libdbi, I've not looked at the
code to see to what extent it is an *actual* problem; however as a
generalization, I would advise against using
Quoting Vikram Noel Ambrose :
> I was pretty shocked to see an atoll call in libdbi. But there is no
> point on going on about that.
>
To better deal with your shock: Could you please elaborate what's
wrong with atoll()? I recall from my home platform (FreeBSD) that
atoll() is merely a wrappe
Vikram Noel Ambrose wrote:
> I can't seem to read back BIGINT UNSIGNED (8bytes) from a mysql database.
>
> For example:
> A value of "10988581603938712255" = 0x987F48BFB028BABF
> is returned as "9223372036854775807" = 0x7FFF
>
> Something somewhere is capping off my BIGINT UNSIGNED
I can't seem to read back BIGINT UNSIGNED (8bytes) from a mysql database.
For example:
A value of "10988581603938712255" = 0x987F48BFB028BABF
is returned as "9223372036854775807" = 0x7FFF
Something somewhere is capping off my BIGINT UNSIGNED to the maximum of
a signed 8byte numb
12 matches
Mail list logo
