From: Sergey Vlasov <vsu@altlinux.ru>
To: sisyphus@lists.altlinux.org
Subject: Re: [sisyphus] liblensfun vs g++
Date: Wed, 19 Aug 2009 12:27:44 +0400
Message-ID: <20090819082744.GA8548@atlas.home> (raw)
In-Reply-To: <20090819004107.GB12237@wo.int.altlinux.org>
[-- Attachment #1: Type: text/plain, Size: 2288 bytes --]
On Wed, Aug 19, 2009 at 04:41:07AM +0400, Dmitry V. Levin wrote:
> Поведение g++ изменилось между 4.3 и 4.4; если это не regression, то, видимо,
> надо патчить liblensfun (см. патч).
Testcase попроще:
-----------------------------------------------------------------------
#include <stdio.h>
enum TestEnum
{
TEST_0,
TEST_1
};
#ifndef __cplusplus
typedef enum TestEnum TestEnum;
#endif
#ifdef __cplusplus
extern "C"
#endif
void print_value(TestEnum x)
{
switch (x) {
case TEST_0:
printf("TEST_0\n");
return;
case TEST_1:
printf("TEST_1\n");
return;
}
printf("BAD\n");
}
int main(int argc, char *argv[])
{
(void)argc; (void)argv;
print_value(TEST_0);
print_value(TEST_1);
print_value((TestEnum)2);
return 0;
}
-----------------------------------------------------------------------
При компиляции этого кода как C он работает ожидаемым образом:
$ gcc -g -O2 -Wall -W -o enum_test enum_test.c
$ ./enum_test
TEST_0
TEST_1
BAD
А вот при компиляции как C++ происходит странное:
$ g++ -g -O2 -Wall -W -o enum_test enum_test.c
$ ./enum_test
TEST_0
TEST_1
TEST_0
(и даже с -O0 этот результат не меняется).
Формально стандартом C++98 подобное поведение не запрещено - результат
преобразования целочисленного значения в enum-тип не определён в
случае, когда значение не входит в диапазон значений этого enum:
5.2.9/7:
A value of integral type can be explicitly converted to an
enumeration type. The value is unchanged if the integral value is
within the range of the enumeration values (7.2). Otherwise, the
resulting enumeration value is unspecified.
(причём для "unspecified behavior" не обязательно даже документировать
поведение в таких случаях).
С точки зрения C++98 ошибочный код в данном случае - (TestEnum)2;
в комбинации ufraw+liblensfun ситуация усугубляется тем, что
преобразование в enum выполняется в коде на C, для которого enum
практически не отличается от целочисленного типа.
Что интересно - такое поведение компилятора наблюдается только для
enum с двумя константами; при добавлении третьей константы проверки на
недопустимое для enum значение не исчезают.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2009-08-19 8:27 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-05 17:08 [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64 Roman Savochenko
2009-08-05 21:34 ` Alexey Rusakov
2009-08-06 7:17 ` Roman Savochenko
2009-08-06 7:59 ` Alexey Rusakov
2009-08-06 16:21 ` Michael Shigorin
2009-08-06 21:10 ` Michael Shigorin
2009-08-06 18:12 ` Kirill A. Shutemov
2009-08-07 5:49 ` Roman Savochenko
2009-08-07 6:28 ` Yuriy Kashirin
2009-08-07 6:31 ` Kirill A. Shutemov
2009-08-07 7:14 ` Roman Savochenko
2009-08-07 7:35 ` Kirill A. Shutemov
2009-08-07 8:14 ` Roman Savochenko
2009-08-07 8:54 ` Kirill A. Shutemov
2009-08-07 8:57 ` Roman Savochenko
2009-08-07 9:14 ` Kirill A. Shutemov
2009-08-07 8:58 ` Alexey Rusakov
2009-08-07 9:02 ` Roman Savochenko
2009-08-07 9:17 ` Alexey Rusakov
2009-08-07 12:59 ` Serge Ryabchun
2009-08-07 13:15 ` Alexey Rusakov
2009-08-07 15:43 ` Kirill A. Shutemov
2009-08-13 16:04 ` Kirill A. Shutemov
2009-08-17 22:39 ` [sisyphus] liblensfun Dmitry V. Levin
2009-08-18 23:18 ` Dmitry V. Levin
2009-08-17 15:48 ` [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64 Alexander Bokovoy
2009-08-17 20:47 ` [sisyphus] ufraw/liblensfun/etc vs gcc Dmitry V. Levin
2009-08-17 21:25 ` Dmitry V. Levin
2009-08-18 8:40 ` Anton V. Boyarshinov
2009-08-19 0:41 ` [sisyphus] liblensfun vs g++ Dmitry V. Levin
2009-08-19 8:27 ` Sergey Vlasov [this message]
2009-08-19 8:33 ` Damir
2009-08-19 23:10 ` Dmitry V. Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090819082744.GA8548@atlas.home \
--to=vsu@altlinux.ru \
--cc=sisyphus@lists.altlinux.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
ALT Linux Sisyphus discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/sisyphus/0 sisyphus/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 sisyphus sisyphus/ http://lore.altlinux.org/sisyphus \
sisyphus@altlinux.ru sisyphus@altlinux.org sisyphus@lists.altlinux.org sisyphus@lists.altlinux.ru sisyphus@lists.altlinux.com sisyphus@linuxteam.iplabs.ru sisyphus@list.linux-os.ru
public-inbox-index sisyphus
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.sisyphus
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git