Annotation of /sml/releases/release-110.40/ckit/BUGS

Parent Directory | Revision Log

---

Revision 1217 - (view) (download)

1 :	dbm	597	ckit Bug List
2 :			=============
3 :			[Last updated: 3/31/00]
4 :
5 :			----------------------------------------------------------------------
6 :			NUMBER: 11
7 :			SUBMITTER: Kathleen Fisher <kfisher@research.att.com>
8 :			DATE: 12/10/99
9 :			TEST:
10 :			STATUS: request for more complete example
11 :			DESCRIPTION:
12 :
13 :			The code:
14 :			void write_myArray (char *f, char *space, int size)
15 :			{
16 :			Sfio_t *fp;
17 :			int *temp_space = (int *) space;
18 :			int i;
19 :
20 :			fp = openfile (f,"w");
21 :			for (i = 0; i<2; i++)
22 :			sfprintf (fp,"%d",&(*temp_space)[i]);
23 :			}
24 :
25 :			passes through the ckit compiler, but cc reports:
26 :
27 :			"directory008.c", line 866: error(1138): expression must have
28 :			pointer-to-object type
29 :			sfprintf (fp,"%d",&(*temp_space)[i]);
30 :
31 :			COMMENT: Could not compile example (it is incomplete);
32 :			Kathleen indicates she can't reproduce this behaviour.
33 :
34 :	dbm	649
35 :			----------------------------------------------------------------------
36 :			NUMBER: 15
37 :			SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
38 :			DATE: 4/17/00
39 :			TEST:
40 :			STATUS: open
41 :			DESCRIPTION: union bitfields
42 :
43 :			According to Harbison and Steele (top of p.141), bitfields in unions are
44 :			allowed in ISO C, but not "traditional" C. Neither "gcc -ansi -pedantic",
45 :			nor cc complains.
46 :
47 :			input: union { int u16:12; } u;
48 :
49 :			output: "test.c":1.2-3.4: error: union member has size spec
50 :
51 :			union t1 { int u16; };
52 :			union t1 u;
53 :
54 :
55 :			----------------------------------------------------------------------
56 :			NUMBER: 16
57 :			SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
58 :			DATE: 4/17/00
59 :			TEST:
60 :			STATUS: open
61 :			DESCRIPTION: struct bitfields
62 :
63 :			This is not a big deal, since ckit implements a superset of ANSI C,
64 :			but I thought I'd mention it anyway. Ckit allows the following:
65 :
66 :			struct S {
67 :			char a:4; /* <-- Illegal field for ANSI C, but not "traditional" C */
68 :			float f:4; /* <-- Illegal field */
69 :			};
70 :
71 :
72 :			----------------------------------------------------------------------
73 :			NUMBER: 17
74 :			SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
75 :			DATE: 4/14/00
76 :			TEST:
77 :			STATUS: open
78 :			DESCRIPTION: large initializer value
79 :
80 :			Input:
81 :			------
82 :			long i = 0xf8000000;
83 :			unsigned long i = 0xf8000000ul;
84 :
85 :			Output:
86 :			-------
87 :			"test.c":1.11-21: error: large int const
88 :			"test.c":2.19-31: error: large int const
89 :			"???": warning: additional errors suppressed.
90 :			"???": warning: additional warnings suppressed.
91 :
92 :			long i=0;
93 :			unsigned long i=0;
94 :
95 :			Note:
96 :			-----
97 :			gcc -Wall -ansi -pedantic: no complaint
98 :			cc: warning: initializer does not fit or is out of range: 0xf8000000
99 :
100 :			COMMENT:
101 :			The problem seems to be due to the fact that LargeInt (i.e. Int32 -
102 :			signed integer type) is used for storing the value, and LargeInt
103 :			raises exception Overflow (in c.lex) in the above cases. IntInf does
104 :			not overflow on such numbers, and so may be the right thing to use,
105 :			however that requires changing the code to use IntInf for IntConst.
106 :
107 :			Ironically, LargeInt parses hexadecimal strings fine but IntInf does
108 :			not handle the 0x prefix for some reason:
109 :
110 :			- let val v = valOf(StringCvt.scanString(LargeInt.scan StringCvt.HEX) "0xff")
111 :			= in print ((LargeInt.toString v)^"\n") end;
112 :			255
113 :			val it = () : unit
114 :			- let val v = valOf(StringCvt.scanString(IntInf.scan StringCvt.HEX) "0xff")
115 :			= in print ((IntInf.toString v)^"\n") end;
116 :			0
117 :			val it = () : unit
118 :			- let val v = valOf(StringCvt.scanString(IntInf.scan StringCvt.HEX) "ff")
119 :			= in print ((IntInf.toString v)^"\n") end;
120 :			255
121 :
122 :
123 :			----------------------------------------------------------------------
124 :			NUMBER: 18
125 :			SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
126 :			DATE: 4/14/00
127 :			TEST:
128 :			STATUS: open
129 :			DESCRIPTION: old style varargs (INCONVENIENCE)
130 :
131 :			This is something we have an easy workaround for (i.e. using cc -E
132 :			instead of gcc -E to preprocess) but we mention it in case you think
133 :			other people might care about this. When varargs.h is included by
134 :			gcc -E, old style parameter passing is transformed to this:
135 :
136 :			int foo(a)
137 :			a;...
138 :			{ }
139 :
140 :			This is not accepted by ckit.
141 :			Remark: non-ANSI (gcc gives warning)
142 :			Solution: use cc -E.
143 :
144 :
145 :			----------------------------------------------------------------------
146 :			NUMBER: 19
147 :			SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
148 :			DATE: 4/20/00
149 :			TEST:
150 :	dbm	654	STATUS: fixed, DBM, 6/8/00
151 :			Return fixed-up id at the same time as the fixed type (fun processDecr
152 :			in ast/build-ast.sml)
153 :	dbm	649	DESCRIPTION: incomplete types
154 :
155 :			A change to build-ast.sml since ckit 1.0b3 is annotating types of ids
156 :			with incomplete types at times. Our problem is that we use the ast in
157 :			a separate pass, so we don't see the local symbol tables (unless we
158 :			redo the work of their construction). We collect types of declared
159 :			variables, which we then use in instrumentation. Incomplete types
160 :			give us compilation errors.
161 :
162 :			The fixed up type is inserted into the symbol table under line 911,
163 :			however, the type in the id of the declaration is still the incomplete
164 :			type. Subsequent uses of the id will by typed correctly but not the
165 :			declaration. The id created on line 916 should be used instead of the
166 :			original id.
167 :
168 :			Input:
169 :
170 :			int ia[] = {1,2,3};
171 :
172 :			int main() {
173 :			int ib[] = {1,2,3,4,5};
174 :			}
175 :
176 :			Types I see in ids for ia and ib in the declarations above are both
177 :			int[]. :-)
178 :
179 :
180 :			----------------------------------------------------------------------
181 :			NUMBER: 20
182 :			SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
183 :			DATE: 5/24/00
184 :			TEST:
185 :			STATUS: open
186 :			DESCRIPTION: long long
187 :
188 :			1. Ckit doesn't really handle long long (it just recognizes the type, but
189 :			does not handle literals of "long long" size: seems to be due
190 :			to using LargeInt. See "unsigned long" bug above.
191 :
192 :			2. Should keep around "L", "LL", "UL" suffix to int literals:
193 :			input: 1LL<<40
194 :			output: 1<<40 /* compiler complains */
195 :
196 :			3. Tilde and negative:
197 :			input: 2e-5
198 :			output: 2E~05
199 :
200 :			Negative numbers are represented with ~ in SML, so that Real.toString
201 :			called in ppReal prints the ~ in the exponent.
202 :
203 :
204 :			----------------------------------------------------------------------
205 :			NUMBER: 21
206 :			SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
207 :			DATE: 5/25/00
208 :			TEST:
209 :			STATUS: open
210 :			DESCRIPTION: spurious error messages
211 :
212 :			Input:
213 :			struct S {
214 :			float j;
215 :			int:24;
216 :			char * k;
217 :			} s = {1.2,"3"};
218 :
219 :			Spurious Error Messages:
220 :			"stst.c":1.2-5.16: error: type of initializer is incompatible with type of lval
221 :			"stst.c":1.2-5.16: error: badly formed struct initializer: not enough initializers
222 :
223 :			FIX:
224 :			skip over unnamed members, as per C specs: diff of build-ast.sml (<new,>old) follows:
225 :			623c623
226 :			< let fun f ((fieldType, _, _) :: l, expr :: exprs) =
227 :			---
228 :			> let fun f ((fieldType, SOME mem, _) :: l, expr :: exprs) =
229 :			625a626,627
230 :			> | f ((fieldType, NONE, _) :: l, exprs) =
231 :			> f (l, exprs)
232 :
233 :
234 :			----------------------------------------------------------------------
235 :	dbm	650	NUMBER: 22
236 :	dbm	649	SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
237 :			DATE: 5/25/00
238 :			TEST:
239 :			STATUS: open
240 :			DESCRIPTION: const char */char * incompatibility (INCONVENIENCE)
241 :
242 :			input: char c[100]; const char * d = &c[5];
243 :			c - d;
244 :			output: error: Type Error: Unacceptable operands of "-" or "--".
245 :
246 :			general: in general, the error occurs with incompatible pointer types.
247 :			the key is to not treat "const" as incompatible.

---

root@smlnj-gforge.cs.uchicago.edu	ViewVC Help
Powered by ViewVC 1.0.0