現在、サードパーティの請負業者から購入したコードを扱っています。1 つの構造体には unsigned char フィールドがありますが、そのフィールドを渡す関数には signed char が必要です。コンパイラは、それらを不一致の型と見なすため、これを好みません。ただし、明らかにその請負業者向けにコンパイルされます。一部のグーグルは、「[i] char オブジェクトが負の値を保持できるかどうかは実装によって定義される」と言っています。請負業者のコンパイラは、基本的に符号付き/符号なしの型を無視して、同じように扱うことができますか? または、それらを同じように扱うコンパイラフラグはありますか?
C は私の最強の言語ではありません。ユーザー ページのタグを見てください。
実はchar、signed charとunsigned charは 3 つの異なるタイプです。標準 (ISO/IEC 9899:1990) から:
6.1.2.5 タイプ
...
char、signed char、 unsigned charの 3 種類をまとめて文字型と呼びます。
(そして、たとえば C++ では、char 引数がある場合、それらの 3 つのバリアントを使用してオーバーライド関数を作成する必要があります (または少なくとも作成する必要があります)。
プレーン char は、コンパイラによって符号付きまたは符号なしで処理される可能性がありますが、標準では次のように述べられています (6.1.2.5 でも):
char型として宣言されたオブジェクトは、基本実行文字セットの任意のメンバーを格納するのに十分な大きさです。5.2.1 で必要なソース文字セットのメンバーが charオブジェクトに格納されている場合、その値は正であることが保証されます。他の数量がcharオブジェクトに格納されている場合、動作は実装定義です。値は符号付きまたは非負の整数として扱われます。
と
signed char 型として宣言されたオブジェクトは、''プレーンな'' charオブジェクトと同じ量のストレージを占有します。
5.2.1 で言及されている文字は、A ～ Z、az、0 ～ 9、スペース、タブ、改行、および次の 29 のグラフィック文字です。
! " # % & ' ( ) * + , - . / :
; < = > ? [ \ ] ^ _ { | } ~
基本的に、128 未満の値を持つ ASCII 文字は正であることが保証されていることを意味すると解釈します。したがって、格納された値が常に 128 未満であれば、(値を保持するという観点から) 安全であるはずですが、あまり良い方法ではありません。
これはコンパイラに依存します。たとえば、VC++ には、コンパイラ オプションと、対応する _CHAR_UNSIGNED マクロが定義されています (そのオプションがデフォルトで unsigned char を使用するように指示する場合)。
signed charタイプとのフィールドについて話していると思いますunsigned charので、それらは明らかに間違っています。それらの1つが単に だった場合char、請負業者が使用しているどのコンパイラでも一致する可能性があります（IIRC、それがまたはであるかどうかは実装定義ですchar）が、あなたのものでは一致しません。その場合は、コマンド ライン オプションまたは何かを変更することで問題を解決できる場合があります。signedunsigned
あるいは、請負業者は、エラーや警告を無視してコンパイルできるコンパイラまたはコンパイラ オプションを使用している可能性があります。彼がどのようなコンパイル環境を持っているか知っていますか?
いずれにせよ、これは適切な C ではありません。型の 1 つがただの場合char、実装定義の動作に依存するため、移植性がありません。そうでなければ、それは完全に間違っています。私はこれを請負業者に取り上げます。