I hate to say it, but the simplest thing is
to use long long int for all this junk. In practice
that is what it is on most systems, or at
least that covers their useful range.
The unfortunate answer is that C/C++ is just
plain ill considered. The argument that you
should just use cout is
Hi,
We use stat all over the places for checking
the presence of the file or directory.
I propose we use access(path, R_OK [| W_OK]) instead,
since the check is done with the real user id.
Comments?
Regards
--
^TM
On 05/19/2010 08:25 AM, John Plevyak wrote:
I hate to say it, but the simplest thing is
to use long long int for all this junk. In practice
that is what it is on most systems, or at
least that covers their useful range.
Agreed.
Think that Leif is working on 64-bit file API, and
forcing that
+1
-George
On 5/19/10 3:09 AM, Mladen Turk wrote:
Hi,
We use stat all over the places for checking
the presence of the file or directory.
I propose we use access(path, R_OK [| W_OK]) instead,
since the check is done with the real user id.
Comments?
Regards
On 05/19/2010 04:17 AM, Mladen Turk wrote:
On 05/19/2010 08:25 AM, John Plevyak wrote:
I hate to say it, but the simplest thing is
to use long long int for all this junk. In practice
that is what it is on most systems, or at
least that covers their useful range.
Agreed.
Think that Leif is
I propose that we change
ink64 - int64
inku64 - uint64
ink32 - int32
inku32 - uint32
ink16 - int16
inku16 - uint16
ink8 - int8
inku8 - uint8
because
1) we decided to move from ink - ts
2) tsu64 doesn't scan like an integer
3) int64_t is long on linux which is incompatible with %lld the
On 05/19/2010 08:23 AM, John Plevyak wrote:
I propose that we change
ink64 - int64
inku64 - uint64
ink32 - int32
inku32 - uint32
ink16 - int16
inku16 - uint16
ink8 - int8
inku8 - uint8
because
1) we decided to move from ink - ts
2) tsu64 doesn't scan like an integer
3) int64_t is
Yes we will change INXXX_MAX etc.
Unfortunately int64 is not standard. So we have a couple alternatives.
1) use nonstandard types where
typedef long long int int64;
typedef int int32;
typedef short int16;
typedef char int8;
etc.
which work on every system and which permit seamless
On 05/19/2010 09:14 AM, John Plevyak wrote:
Yes we will change INXXX_MAX etc.
Unfortunately int64 is not standard. So we have a couple alternatives.
1) use nonstandard types where
typedef long long int int64;
typedef int int32;
typedef short int16;
typedef char int8;
etc.
On 05/19/2010 10:31 AM, Bryan Call wrote:
On 05/19/2010 09:14 AM, John Plevyak wrote:
Yes we will change INXXX_MAX etc.
Unfortunately int64 is not standard. So we have a couple alternatives.
1) use nonstandard types where
typedef long long int int64;
typedef int int32;
typedef
+1, against type casting for this
On Wed, May 19, 2010 at 12:31 PM, Bryan Call bc...@yahoo-inc.com wrote:
On 05/19/2010 09:14 AM, John Plevyak wrote:
Yes we will change INXXX_MAX etc.
Unfortunately int64 is not standard. So we have a couple alternatives.
1) use nonstandard types where
+1
Wednesday, May 19, 2010, 11:31:50 AM, you wrote:
On 05/19/2010 09:14 AM, John Plevyak wrote:
Yes we will change INXXX_MAX etc.
Unfortunately int64 is not standard. So we have a couple alternatives.
1) use nonstandard types where
typedef long long int int64;
typedef int int32;
Late but
+1
-George
On 5/19/10 9:57 AM, Leif Hedstrom wrote:
On 05/19/2010 10:31 AM, Bryan Call wrote:
On 05/19/2010 09:14 AM, John Plevyak wrote:
Yes we will change INXXX_MAX etc.
Unfortunately int64 is not standard. So we have a couple alternatives.
1) use nonstandard types where
I am trying to run regression tests (traffic_server -R 1) but it segfaults in
Cache_part. According to TS-74
for the 'Cache_part' regression test to pass a cache storage has to be
allocated 128MB.
I checked there is a cache.db file that is 144M. Does this really mean a cache
storage
14 matches
Mail list logo
