返回结构的函数的可移植性问题 [英] portability problem with a function returning a struct
问题描述
在Linux（gcc）下，这可行，但在Windows下（lcc-win32）
p.Blue始终为零。
在函数本身内，结果。蓝色是正确的（0,255，
或分配给它的表达式的模数为256，根据n的符号，b / b为
）。但是当返回到main（）时，它神奇地将
变为零。 （以下代码完全复制并粘贴。）
平均值是多少？有任何想法吗？ sizeof（struct Pixel）是3，
如果这对任何事情都很重要（但所以它与gcc一样）。
#define DEBUG
#include< stdio.h>
#include< limits.h>
#include< math.h>
struct Pixel {
unsigned char Red;
unsigned char Green;
unsigned char Blue;
} colormap（int n，int max）;
#ifdef DEBUG
int main（无效）
{
int n，max;
while（scanf（"％d％d"，& n，& max）1）{
struct Pixel p = colormap（n，max）;
printf（"％d％d％d \ n"，（int）p.Red，（int）p.Green，
（int）p.Blue）;
if（！p.Blue）
puts（" p.Blue is * really *零。;
}
返回0;
}
#else
/ *真实节目* /
#endif
struct Pixel colormap（int n，int max）
{
struct Pixel结果;
if（n< 1）{/ *黑色如果为负，白色如果为零* /
result.Red = n？ 0：UCHAR_MAX;
result.Green = n？ 0：UCHAR_MAX;
result.Blue = n？ 0：UCHAR_MAX;
}其他{
const double pi = 4 * atan（1）;
double val = UCHAR_MAX *（1 - log（n）/ log（max））
+ log（n）/ log（max）;
double hue = 2 * pi * log（n）/ log （2.0）;
result.Red = val *（1 + cos（hue））/ 2;
result.Green = val *（1 + cos（hue - 2 * pi / 3））/ 2;
#ifdef DEBUG
printf（"％g\t"，val *（1 + cos（hue - 4） * pi / 3））/ 2）;
#endif
result.Blue = val *（1 + cos（hue - 4 * pi / 3））/ 2 ;
}
#ifdef DEBUG
printf（" result.Blue is％d \ n"，（int）result.Blue ）;
#endif
返回结果;
}
使用gcc的行为：
army1987 @ army1987-笔记本电脑：〜$。/ a.out
-1 255
result.Blue is 0
0 0 0
p.Blue是*真的*零。
0 255
result.Blue是255
255 255 255
1 255
63.75结果。蓝色是63
255 63 63
42 255
35.4608 result.Blue是35
9 80 35
23 32767
144.707结果。蓝色是144
0 121 144
ok谢谢
army1987 @ army1987-笔记本电脑：〜$
使用lcc-win32的行为：
C：\ csc\projects\lcc>测试
-1 255
result.Blue是0
0 0 0
p.Blue是*真的*零。
0 255
result.Blue是255
255 255 0
p.Blue是*真的*零。
1 255
63.75 results.Blue is 63
255 63 0
p.Blue is * really * zero。
42 255
35.4608 result.Blue是35
9 80 0
p.Blue是*真的*零。
23 32767
144.707 result.Blue is 144
0 121 0
p.Blue is * really * zero。
自己去吧
C：\ lcc\projects\lcc>
./ a.out的
-1 255
result.Blue is 0
0 0 0
p.Blue is * really *零。
0 255
result.Blue是255
255 255 255
1 255
63.75结果。蓝色是63
255 63 63
42 255
35.4608 result.Blue is 35
9 80 35
23 32767
144.707结果。蓝色是144
0 121 144
ok谢谢
army1987 @ army1987-laptop：〜
lcc-win32的行为：
C：\ clc \ project] \ clc>测试
-1 255
result.Blue为0
0 0 0
p.Blue是*真的*零。
0 255
result.Blue是255
255 255 0
p.Blue is * really * zero。
1 255
63.75 result.Blue is 63
255 63 0
p.Blue is * really * zero。
42 255
35.4608 result.Blue is 35
9 80 0
p.Blue is * really *零。
23 32767
144.707结果。蓝色是144
0 121 0
p.Blue is *真的*零。
自己去吧
C：\lcc\projects\lcc>
Army1987说：
在Linux（gcc）下，这可行，但在Windows下（lcc-win32）
p.Blue始终为零。
我看不到任何明显的代码问题。我建议您尝试
找到表现出同样问题的最简单的程序，
并重新发布。例如，如果你抛弃所有的trig，并且只是直接在colormap（）中设置值，那么问题是否仍然存在？
但这样做看起来像是实现中的一个bug。毫无疑问，
考虑到维护者对一致性和便携性的态度。
-
Richard Heathfield
Usenet是一个奇怪的地方 - dmr 29/7/1999
http://www.cpax.org.uk
电子邮件：rjh在上述域名中， - www。
Under Linux (gcc) this works OK, but under Windows (lcc-win32)
p.Blue always is zero.
Within the function itself, result.Blue is correct (either 0, 255,
or the floor of the expression assigned to it modulo 256, according
to the sign of n). But when returned to main(), it magically turns
to zero. (The code below is entirely copied and pasted.)
What the deuce is happening? Any ideas? sizeof(struct Pixel) is 3,
if that can matter to anything (but so it is with gcc).
#define DEBUG
#include <stdio.h>
#include <limits.h>
#include <math.h>
struct Pixel {
unsigned char Red;
unsigned char Green;
unsigned char Blue;
} colormap(int n, int max);
#ifdef DEBUG
int main(void)
{
int n, max;
while (scanf("%d%d",&n, &max) 1) {
struct Pixel p = colormap(n, max);
printf("%d %d %d\n", (int)p.Red, (int)p.Green,
(int)p.Blue);
if (!p.Blue)
puts("p.Blue is *really* zero.");
}
return 0;
}
#else
/*real program*/
#endif
struct Pixel colormap(int n, int max)
{
struct Pixel result;
if (n < 1) { /* black if negative, white if zero */
result.Red = n ? 0 : UCHAR_MAX;
result.Green = n ? 0 : UCHAR_MAX;
result.Blue = n ? 0 : UCHAR_MAX;
} else {
const double pi = 4 * atan(1);
double val = UCHAR_MAX*(1 - log(n)/log(max))
+ log(n)/log(max);
double hue = 2 * pi * log(n) / log(2.0);
result.Red = val * (1 + cos(hue))/2;
result.Green = val * (1 + cos(hue - 2*pi/3))/2;
#ifdef DEBUG
printf("%g\t", val * (1 + cos(hue - 4*pi/3))/2);
#endif
result.Blue = val * (1 + cos(hue - 4*pi/3))/2;
}
#ifdef DEBUG
printf("result.Blue is %d\n", (int)result.Blue);
#endif
return result;
}
Behaviour with gcc:
army1987@army1987-laptop:~$ ./a.out
-1 255
result.Blue is 0
0 0 0
p.Blue is *really* zero.
0 255
result.Blue is 255
255 255 255
1 255
63.75 result.Blue is 63
255 63 63
42 255
35.4608 result.Blue is 35
9 80 35
23 32767
144.707 result.Blue is 144
0 121 144
ok thanks
army1987@army1987-laptop:~$
Behaviour with lcc-win32:
C:\lcc\projects\lcc>test
-1 255
result.Blue is 0
0 0 0
p.Blue is *really* zero.
0 255
result.Blue is 255
255 255 0
p.Blue is *really* zero.
1 255
63.75 result.Blue is 63
255 63 0
p.Blue is *really* zero.
42 255
35.4608 result.Blue is 35
9 80 0
p.Blue is *really* zero.
23 32767
144.707 result.Blue is 144
0 121 0
p.Blue is *really* zero.
go f*** yourself
C:\lcc\projects\lcc>
./a.out
-1 255
result.Blue is 0
0 0 0
p.Blue is *really* zero.
0 255
result.Blue is 255
255 255 255
1 255
63.75 result.Blue is 63
255 63 63
42 255
35.4608 result.Blue is 35
9 80 35
23 32767
144.707 result.Blue is 144
0 121 144
ok thanks
army1987@army1987-laptop:~
Behaviour with lcc-win32:
C:\lcc\projects\lcc>test
-1 255
result.Blue is 0
0 0 0
p.Blue is *really* zero.
0 255
result.Blue is 255
255 255 0
p.Blue is *really* zero.
1 255
63.75 result.Blue is 63
255 63 0
p.Blue is *really* zero.
42 255
35.4608 result.Blue is 35
9 80 0
p.Blue is *really* zero.
23 32767
144.707 result.Blue is 144
0 121 0
p.Blue is *really* zero.
go f*** yourself
C:\lcc\projects\lcc>
Army1987 said:
Under Linux (gcc) this works OK, but under Windows (lcc-win32)
p.Blue always is zero.I can''t see any obvious issues with the code. I recommend that you try
to find the simplest possible program that exhibits the same problem,
and re-post it. For example, if you throw out all the trig, and just
set the values directly within colormap(), does the problem remain?
But this does look like a bug in the implementation. No surprise there,
given the maintainer''s attitude to conformance and portability.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
这篇关于返回结构的函数的可移植性问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
