I really don't want to go that far. I already had to deal with the
bool to int conversion in exactly this way. And changing it all over
the code, was a mess. As the simple explicit cast is enough to keep
happy the VC compiler, I propose we stick with it. It's less
intrusive, impose less [un
> I see... so the right way to right this is really:
err... "right way to WRITE this"
- R.
> How about (u)int32_t? When I was an Ada programmer, subtypes with the
> approriate range were always encouraged (i.e.: define the semantical
> range and let the compiler/runtime library warn you on range
> violations (the well-known "CONSTRAINT_ERROR"))
It's OK to use a type with a fixed siz
> The main problem came from the fact that if we want to use our
> modular approach on Windows (DLL loaded at runtime) we have to
> compile in C++ mode. The C++ compiler consider the types int and long
> as being different (even if they have the same number of bytes). No
> implicit cast is all
On Wed, Apr 18, 2007 at 01:16:54PM -0400, George Bosilca wrote:
> That's right, long and int have the same size on Windows 32 and 64
> bits (always 32 bits). However, they are considered as being
> different types (!!!).
How about (u)int32_t? When I was an Ada programmer, subtypes with the
ap
That's right, long and int have the same size on Windows 32 and 64
bits (always 32 bits). However, they are considered as being
different types (!!!).
The main problem came from the fact that if we want to use our
modular approach on Windows (DLL loaded at runtime) we have to
compile in C
> So, either we add the explicit cast from the beginning or I will have
> to add it next time I compile on Windows ...
I thought the problem with Windows was that long was always 32 bits
(the same size as int) even on 64-bit platforms?
- R.
Roland Dreier wrote:
> Because the target variable is an (int).
If I were writing the code, I would leave the cast out. By assigning
the value to an int variable, you get the same effect anyway, so the
cast is redundant. And if you ever change the variable to a long, now
you have to remember
> > Because the target variable is an (int).
>
> If I were writing the code, I would leave the cast out. By assigning
> the value to an int variable, you get the same effect anyway, so the
> cast is redundant. And if you ever change the variable to a long, now
> you have to remember to delete th
It's not only a style issue. There are at least 2 valid reasons to
keep the cast explicit.
1. If [somehow] something goes wrong it's a lot simpler to bash a
fellow developer than send a request for support to one of the
compiler development team.
2. Some compilers don't like the implicit
> I.e., it returns a long. Although some compilers might do the right
> thing, conversions should be explicitly shown.
Isn't the behavior guaranteed by the C standard? And I can't even
imagine a way for a compiler to get
intvar = strtol(foo);
wrong, and it seems even more implausib
> Because the target variable is an (int).
If I were writing the code, I would leave the cast out. By assigning
the value to an int variable, you get the same effect anyway, so the
cast is redundant. And if you ever change the variable to a long, now
you have to remember to delete the cast too.
And the man page (on OS X) has this prototype for strol():
long
strtol(const char * restrict nptr, char ** restrict endptr, int
base);
I.e., it returns a long. Although some compilers might do the right
thing, conversions should be explicitly shown.
On Apr 18, 2007, at 11:38
Because the target variable is an (int). Plus, the man pages on OSX
and Linux both say that atoi() is the exact equivalent of
(int)strtol(nptr, (char **)NULL, 10);
and that atoi() is deprecated (which I didn't know).
On Apr 18, 2007, at 11:32 AM, Roland Dreier wrote:
With the (int) ca
> With the (int) cast, I'm ok with it now. :-)
What's the point of the cast to int?
- R.
The patch is so that you can pass in hex in addition to decimal, right? I
think that makes sense. But since we're switching to strtol, it might
also make sense to add some error detection while we're at it. Not a huge
deal, but it would be nice :).
Brian
> Hi,
>
> I want to add a patch to opa
On Apr 18, 2007, at 7:55 AM, Sharon Melamed wrote:
I want to add a patch to opal mca.
This patch replaces an ‘atoi’ call with a ‘strtol’ call.
If it’s O.K with everyone I’ll submit this patch by the end of the
week.
With the (int) cast, I'm ok with it now. :-)
The man pages on Linux, OSX
Hi,
I want to add a patch to opal mca.
This patch replaces an 'atoi' call with a 'strtol' call.
If it's O.K with everyone I'll submit this patch by the end of the week.
Index: opal/mca/base/mca_base_param.c
===
--- opal/mca/ba
18 matches
Mail list logo
